In a recent post, we outlined the pitfalls of self-hosted authoritative Domain Name System (DNS) from the perspective of a start-up or midsize 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—be it functionality, cost, reliability or resourcing—most companies naturally come around to the need for a managed DNS service delivered by a third party.
Nonetheless, there is a certain class of large enterprises where self-hosted authoritative DNS operates under a different kind of logic. With global footprints and enough scale to solve even complex technical projects in-house, these types of companies often default to building resolutions instead of buying another company’s product.
There are several reasons why a large enterprise would want to build and host an authoritative DNS service 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 distinctive application architectures to compliance requirements.
Using 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 dependent on 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 approaches that nurture technical skills.
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 various 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 downtime 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 rarely includes this—it’s too resource intensive to build and maintain a secondary system 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 capabilities and operating requirements. One false move, such as 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. However, the reality 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 might easily result in a downtime incident that’s difficult to recover from.
Automation: BIND doesn’t have an Application Programming Interface (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 nearly impossible to orchestrate DIY architectures using third-party tools. If you’ve got a DIY authoritative DNS, you’re probably stuck with manual changes that slow down application development efforts to a crawl.
As a provider of managed DNS solutions, we’re certainly biased. However, 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.
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 an independent platform or as a failover option. With a secondary DNS layer in place, administrators can migrate application workloads over time, testing out the capabilities 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 features that a managed DNS service offers—things like traffic steering, APIs, DNS data analysis and other elements that deliver clear value but aren’t available in most self-hosted services.
Ready to move on from self-hosted authoritative DNS?
7 min read – The future of 5G and the innovations it holds, including in healthcare, smart cities and AI.
5 min read – Today, utilities are meeting these challenges and risks with innovation by leaning on data and AI to prepare for the next event.
7 min read – Powerful AI-driven omnichannel experiences are at the heart of business growth. Explore six ecommerce trends making the greatest impact.
7 min read – Since its rollout in 2019, 5G wireless networks have been growing in both availability and use cases. Apple was one of the first manufacturers to test the appetite for 5G in 2020 by offering its newest iPhone with 5G compatibility. From there, the floodgates opened, and today as much as 62% of smartphones are built with 5G connectivity (link resides outside ibm.com.) The number of networks also continues to grow, with many popular Internet Service Providers (ISPs) like Verizon, Google…
4 min read – Apache Kafka stands as a widely recognized open source event store and stream processing platform. It has evolved into the de facto standard for data streaming, as over 80% of Fortune 500 companies use it. All major cloud providers provide managed data streaming services to meet this growing demand. One key advantage of opting for managed Kafka services is the delegation of responsibility for broker and operational metrics, allowing users to focus solely on metrics specific to applications. In this…
< 1 min read – Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 94 On this episode, we’re covering the IBM X-Force Threat Intelligence Index 2024: IBM X-Force Threat Intelligence Index 2024 landing page Download the report Watch the webinar: “Cybersecurity in 2024: Exploiting the human attack…

More Stories
From Commitments to Practice: Internet Society’s Priorities for WSIS+20 Implementation
Final Results of the 2026 Internet Society Board of Trustees Elections and IETF Selections
Community Snapshot—March