January 31, 2024 By Ben Ball 5 min read

The distinction between “internal” and “external” networks has always been somewhat false.

Clients are accustomed to thinking about firewalls as the barrier between network elements we expose to the internet and back-end systems that are only accessible to insiders. Yet as the delivery mechanisms for applications, websites and content become more decentralized, that barrier is becoming more permeable.

The same is true for the people managing those network elements. Quite often, the same team (or the same person!) is responsible for managing internal network pathways and external delivery systems.

In this context, it’s only natural that the DNS, DHCP and IPAM (DDI) systems that used to manage “internal” networks would bleed into management of external, authoritative DNS as well. In small companies, this issue usually means an IT manager spinning up a BIND server to handle network traffic on both sides of the firewall. For medium-sized and larger companies, a commercially available DDI solution is often used for authoritative DNS as well.

Most network admins use DDI solutions for authoritative DNS because it’s one less system to manage. You can manage both sides of the network from a single interface. Combining internal and external network management also means that the team only needs to learn how to operate a single system,thereby eliminating the need to specialize in one side of the network or another.

The downsides of using DDI for authoritative DNS

While simplicity and ease of use often turn DDI into the default solution for authoritative DNS, there are some strong reasons why the two systems should be separate.

Security

When you run authoritative DNS on the same servers and systems as your internal DDI solution, there’s a risk that a DDoS attack could take down both sides of your network. This is not an insignificant risk. The frequency and severity of DDoS attacks continues to rise, which most companies may experience one at some point.

Using the same infrastructure for internal and external operations only heightens the impact of an outage and significantly increases recovery times. It’s bad enough if you can’t connect with end users. It’s far worse when you can’t access internal systems either.

Unfortunately, most companies aren’t going to invest in the server capacity or defensive countermeasures it would take to absorb a significant DDoS attack. Paying for all of that idle capacity (along with the people and resources that needed to maintain it over time) gets expensive really quick.

Separating authoritative DNS from internal DDI systems creates a natural gap that limits exposure in the event of a DDoS-related outage. While it does mean that there are two systems to manage, it also means that those systems won’t go down at the same time.

Scale

Network infrastructure is expensive to purchase and maintain. (Trust us, we know!) Most of the small or medium-sized companies who use DDI solutions for authoritative DNS don’t have the resources to set up more than three or four locations to handle inbound traffic from around the world.

As companies grow, the load on those servers quickly becomes unsustainable. The experience of both customers and internal users starts to suffer in the form of increased latency and poor application performance. It’s either very difficult or impossible to steer traffic based on geography or other factors—DDI solutions simply aren’t built to do that.

In contrast, managed solutions for authoritative DNS instantly provide worldwide coverage with capacity to spare. End users get a consistent experience, which can be optimized to account for geography or many other operational factors. Internal users aren’t drawing from the same resources for their own work. They also get a consistent, predictable user experience.

BIND architecture limitations

DDI solutions are designed primarily (or solely) for internal network management, not with the goal of providing an internet-facing authoritative DNS solution. DDI vendors grudgingly support authoritative DNS use cases because they recognize that a certain percentage of their customers require it. Yet it’s not something that they’re prepared to support over the long term. This reason is why most DDI vendors offer plug-ins and partnerships as a way to outsource authoritative DNS functionality to other providers.

Architecturally, this usually means that the DDI provider acts as a hidden primary, while the authoritative DNS partner is advertised as an “public secondary” system: an awkward workaround that can limit the functionality of your network. The BIND architectures that most DDI vendors use constrain their ability to support common authoritative DNS use cases, particularly when a partner is involved.

Support for ALIAS records at the apex is a good example. This workaround is common on sites with complex back-end configurations, but unfortunately, it’s impossible to implement with BIND-dependent DDI, making name redirection at the zone apex tricky to deal with.

DDI vendors do not usually support traffic steering either, but it’s a table stakes feature for authoritative DNS solutions. It’s an important consideration that even basic traffic steering based on geographic location can significantly improve response times and user experience.

Cost

From an infrastructure perspective, deploying a DDI solution for authoritative DNS is similar to building your own authoritative solution. You need to buy all the servers, deploy them around the world, and maintain them over time. The only difference is who you’re buying those servers from, in this case, a DDI vendor.

As noted above, the significant costs associated with procuring and deploying a solution this way will usually lead companies to minimize the number of servers they purchase. That in turn leads to limited global coverage and diminished performance in comparison to a managed DNS service like NS1. Not only are you paying more, you’re also getting a smaller footprint that leads to a poor user experience.

The cost calculation doesn’t end at the initial deployment, either. Operating and maintaining DDI infrastructure is also a heavy lift, requiring a significant injection of dedicated (and specialized) resources over time. If you’re outsourcing that maintenance to a DDI vendor, be prepared to pay even more for a professional services contract. DDI companies often have notoriously short refresh cycles on their equipment, so “maintenance” will often equate to “replacement” on a 3 – 5 year timeframe.

From a cost perspective, the benefit of a managed DNS service like NS1 over a DDI vendor is crystal clear. Managed DNS services provide expanded global coverage, built-in resilience, and a huge range of functionality at a fraction of what a DDI vendor would charge. Add to that the lack of maintenance and refresh costs, and it’s truly a no-brainer.

It is true that managed DNS providers will charge usage costs, where DDI appliances can handle a huge number of queries. Yet even with that query volume factored in, the pricing of a managed solution is extremely attractive.

A glide path from DDI to managed authoritative DNS

If you’re already using a DDI solution for authoritative DNS, the switch to a managed provider can appear a little daunting at first. There are a lot of operational considerations to think about as part of a cutover, and there’s inherent risk in definitively flipping the switch.

That’s why we recommend starting off with NS1 as a secondary option for authoritative DNS. This allows network teams to test the system with a little bit of production traffic and get used to how it functions. Over time, you can gradually migrate your traffic over, phasing out the DDI system workload by workload and scaling up your managed DNS solution.

Ready to see the benefits of NS1’s Managed DNS solution over DDI? Contact us today and get a proof of concept going.

See the benefits of NS1’s Managed DNS solution
Was this article helpful?
YesNo

More from Security

What you need to know about the CCPA rules on AI and automated decision-making technology

9 min read - In November 2023, the California Privacy Protection Agency (CPPA) released a set of draft regulations on the use of artificial intelligence (AI) and automated decision-making technology (ADMT).  The proposed rules are still in development, but organizations may want to pay close attention to their evolution. Because the state is home to many of the world's biggest technology companies, any AI regulations that California adopts could have an impact far beyond its borders.  Furthermore, a California appeals court recently ruled that…

Data privacy examples

9 min read - An online retailer always gets users' explicit consent before sharing customer data with its partners. A navigation app anonymizes activity data before analyzing it for travel trends. A school asks parents to verify their identities before giving out student information. These are just some examples of how organizations support data privacy, the principle that people should have control of their personal data, including who can see it, who can collect it, and how it can be used. One cannot overstate…

How to prevent prompt injection attacks

8 min read - Large language models (LLMs) may be the biggest technological breakthrough of the decade. They are also vulnerable to prompt injections, a significant security flaw with no apparent fix. As generative AI applications become increasingly ingrained in enterprise IT environments, organizations must find ways to combat this pernicious cyberattack. While researchers have not yet found a way to completely prevent prompt injections, there are ways of mitigating the risk.  What are prompt injection attacks, and why are they a problem? Prompt…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters