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

The post Why DDI solutions aren’t always ideal for authoritative DNS appeared first on IBM Blog.