In a recent post, we outlined the pitfalls of self-hosted authoritative DNS from the perspective of a start-up or mid-size company piecing together a DIY system using BIND DNS or other open source tools. The main idea was that every company gets to a point where they outgrow their self-hosted, home-grown authoritative DNS systems. For whatever reason - functionality, cost, reliability, resourcing - most companies naturally come around to the need for a managed DNS solution delivered by a third party.
Yet there is a certain class of large enterprises where self-hosted authoritative DNS operates under a different kind of logic. We’re talking about the true behemoths of the corporate world here – companies with a global footprint and enough scale to solve even complex technical projects in-house. These are the companies that default to building solutions instead of buying another company’s product.
The pros of self-hosting for large enterprises
There are several reasons that a large enterprise like that would want to build and host an authoritative DNS solution on its own:
Specific functional requirements: Large enterprises often want to deliver their applications, services, and content in a customized way. This can be anything from hyper-specific routing of DNS queries to system-level support for unique application architectures to compliance requirements.
Leveraging existing resources: When companies have servers and technical resources deployed at scale around the globe already, using that footprint to deliver authoritative DNS often seems like a logical next step.
Control: Some companies simply don’t want to be beholden to a vendor, particularly for something as business-critical as authoritative DNS. Other companies have a “build it” culture that sees value in developing in-house solutions that nurture technical skills.
Theory vs reality
These are all valid reasons to self-host your DNS at scale - at least in theory. What we’ve found from talking to large enterprises in a variety of industries is that the perceived advantages of self-hosted authoritative DNS often go unrealized. The logic behind self-hosting looks good on a powerpoint, but doesn’t deliver actual business value.
Here are some areas where the reality of self-hosted authoritative DNS doesn’t match up to the theory:
Resilience: Any large business is probably important enough that any down time would have a devastating impact on the bottom line. That’s why most authoritative DNS administrators insist on a secondary or failover option in case disaster strikes. Self-hosted authoritative DNS almost never includes this - it’s usually too resource intensive to build and maintain a secondary system just as a form of insurance.
Brittle architectures: Most authoritative DNS infrastructures are built on BIND, which usually requires a Rube Goldberg machine of scripts to operate. Over time, the complexity of those scripts can become difficult to maintain as you account for new functionality and operating requirements. One false move - one single coding error - could easily bring down your entire authoritative DNS infrastructure and take your customer-facing sites offline. For a large, complex enterprise, brittle BIND architectures and scripts can be especially perilous.
Technical debt: When you run your own authoritative DNS, it’s easy to rack up a significant backlog of feature requests. This is especially true if you have a DevOps, NetOps, or CloudOps team working against a deadline. Let’s face it: most of those DNS features are going to be delivered on a much longer timeline than any application development team requires.
Cost: A self-hosted large enterprise may have done the math and concluded that building, deploying, and maintaining an authoritative DNS system is worth the investment. The reality, however, is that these decisions usually happen without a deliberate cost/benefit analysis. In the long term, the outlay cost and the hidden opportunity costs of self-hosted authoritative DNS tend to outweigh any perceived financial benefit.
Staff turnover: DIY architectures only work for as long as the person (or the team) who built them stays with the company. If that person leaves the company for whatever reason, their institutional knowledge about how DIY architectures were built leaves with them. Some companies get to the point where they’re afraid to change anything because it could very easily result in a downtime incident that’s difficult to recover from.
Automation: BIND doesn’t have an API, and wasn’t built to support any form of automation. DIY architectures usually aren’t built to support standard automation platforms like Ansible or Terraform. It’s near-impossible to orchestrate DIY architectures using third party tools. If you’ve got a DIY authoritative DNS, you’re probably stuck with manual changes which slow down application development efforts to a crawl.
Managed DNS just makes sense
As a provider of managed DNS solutions, we’re certainly biased. Yet from our perspective the cons of self-hosted authoritative DNS clearly outweigh the benefits, even (or especially) for large enterprises that usually default to building their own systems. When you weigh the long-term cost of maintaining an authoritative DNS system - both the CapEx hardware and the OpEx personnel - a managed DNS solution simply makes economic sense.
Managed DNS solutions also help IT teams do more with less. When you consider the admin hours required to operate an authoritative DNS network at scale, there’s far more value in directing those resources to other strategic priorities. Having operated authoritative DNS on behalf of a good portion of the internet for 10 years ourselves, we know just how costly and arduous a task it can be!
Dealing with DNS migration risk
We get it. It’s difficult to change. Even when large enterprises are ready to move on from their self-hosted authoritative DNS architectures, they often balk at the significant risks that come with migration to a managed DNS service. When existing DNS tools become ingrained in a company’s technical DNA, it can be hard to even think about the complex web of dependencies that would need to change.
This is where secondary DNS offers a lifeline. Any managed DNS service (like NS1) can operate alongside a self-hosted authoritative DNS system - either as a completely independent platform or as a failover option. With a secondary DNS layer in place, administrators can migrate application workloads over time, testing out the functionality of the managed system and gradually unwinding complex connections to internal systems.
Operating a secondary DNS as a test environment also builds up confidence in the advanced functionality that a managed DNS solution offers - things like traffic steering, APIs, DNS data analysis, and other elements that deliver clear value but aren’t available in most self-hosted solutions.
Ready to move on from self-hosted authoritative DNS? Check out everything you can do with NS1’s Managed DNS offering.
