When to replace BIND DNS

BIND (Berkeley Internet Name Domain) is an open source solution for DNS which is still commonly used to manage network infrastructure on enterprises around the world.  Administrators often turn to BIND DNS services when standing up new networks because it’s simple and free.  (Well, not exactly free, but we’ll cover that below.)

BIND is pretty basic – there are no bells and whistles to speak of.  That being said, many administrators like the open nature of BIND because it allows them to build their own custom tools to address specific use cases and operational requirements.  This is an advantage of BIND over Microsoft DNS, the main alternative for small, uncomplicated networks.

As with Microsoft DNS, there is a certain threshold where BIND becomes more trouble than it’s worth.  Most organizations creep up on this threshold so slowly that they hardly realize that it’s on the horizon.  As network outages become more frequent, time spent managing service tickets starts to get out of hand, and compliance requirements go by the wayside, Domain Name System (DNS) is often the last place administrators think to look. 

Even so, the impact of a dysfunctional DNS has ripple effects throughout the enterprise.  When your BIND DNS becomes too complex, it has an impact on your cloud strategy, your DevOps teams, your security posture, and everything else that your network needs to function efficiently.

Here are some indicators that your BIND infrastructure might be reaching the boundaries of its useful life:

Decentralized, unmanageable DDI

BIND only manages DNS, which means that if you’re using BIND then by definition your DHCP and IPAM have to be managed separately.  More often than not, this leads to an organizational gap between the DNS teams and their counterparts who manage DHCP and IPAM.  It also means a proliferation of single-use tools for DHCP and IPAM which have to integrate with the BIND infrastructure somehow.

Since the operations of DNS, DHCP, and IPAM (DDI) are closely interrelated, this separation can have disastrous consequences in the long term.  Lack of communication between teams and operational tools will often lead to lack of communication between parts of the network – a sure fire recipe for network outages. 

The structure of BIND also doesn’t allow for a single source of truth for all DNS zone data or a system to push out changes to the network architecture.  Each DNS server operates as its own island, making BIND configurations a time-intensive and difficult process.  Compiling logs of DNS records like zone files, reverse zone files, and zone transfers is a mind-numbing manual process and many of the error messages are cryptic, which almost ensures that it is rarely done.

DNS data errors

BIND has no GUI or user-friendly portal – it is essentially a series of glorified text files.  This means that the margin for error in BIND is perilously thin.  Each file has to be coded exactly right, or DNS queries won’t resolve correctly.

Take this sample BIND file for example.  There are so many things that could go wrong here. 

Maybe you “fat finger” the IP address and bring down the network by sending DNS queries to a previously occupied address.  Maybe you accidentally send that NS record to a mail server.  See those semicolons and periods?  If any one of those are wrong or left out, the file won’t operate as intended – or at all.

Unlike Microsoft DNS or any purpose-built DDI solution, BIND has no failsafe devices to protect you from yourself.  There is no back-end error checking, no code verification tool, no warning box asking, “are you sure you want to do this?”  In practice, this means that BIND makes it very easy to bring down the network, and very hard to trace the source of a problem.  In addition, these errors may not show up for days, further compounding the difficulty of diagnosing the problem.

Compounding complexity

BIND files often refer to other BIND files, creating a tree of interlocking instructions for DNS queries.  When networks are simple and straightforward, this usually isn’t a problem.

Yet when the volume of references grows, and when references form more baroque chains of dependency, things can get dangerous quickly.  All of a sudden, a simple change to one BIND file can cascade across the entire network, moving from the authoritative name server out to secondary DNS layers. More to the point, a single error in one BIND file can cause the entire network to stop processing DNS queries. 

Traceability becomes nearly impossible when BIND files get too complicated.  Errors will bring down the network more often, and the downtime associated with each incident becomes longer, as finding the root cause of those errors is far more difficult.

Needless to say, this compounding complexity gets even worse when you add the cloud, SD-WAN, and other strategic initiatives into the mix.

DNSSEC problems

BIND supports DNSSEC, but implementation is a real challenge.  First, you have to really know what you’re doing – a command line interface is the only way to make it work, and even then it takes a real expert to do it right.

Second (and far worse), there are operational risks associated with the way DNSSEC works in BIND.  Specifically, there is no built-in renewal notification.  If your DNSSEC keys expire, this could quickly result in a situation where you’re basically DOS-ing yourself. 

When other BIND servers configured to use DNSSEC find expired or wrong keys, they may not return an answer to their clients.  This can result in a very perplexing situation where “it works with one part of the enterprise but not another – must be the other guys’ problem”.  If you aren’t watching your BIND error logs, this problem can surface pretty easily.

Since BIND has no GUI or notification system, it can be very difficult to determine that a failed DNSSEC renewal is the root cause – you basically have to find it in the logs, and even then you have to really know what you’re looking for.

DNS becomes a drain on resources

Administrators and developers like BIND because it’s customizable.  If you know Perl, Python, or Shell, the sky’s basically the limit – any tool you might need can be built.  Any functional requirement can be met with an exact solution which fits your network alone.

The downside of all this customization is that it has to be maintained.  As operational needs change, the tools and custom fixes will also need to be changed.  Then there’s the challenge of keeping with BIND itself.  The underlying code base of BIND itself is constantly shifting, which means that anything built on top of that foundation will need to be updated to a new version of BIND whenever it comes out.

As the number of custom patches, configuration files, and fixes starts to grow, the bill for that maintenance can get pretty steep.  Suddenly, your IT shop is spending more time keeping DNS up and running than it is on more important strategic initiatives.  At a certain point, the resources devoted to customization (or more likely the business cost of mistakes) will inevitably become more than the cost of most purpose-built DDI solutions.

Then there’s the problem of the person we like to call “Mister DNS” – the one person in the organization who actually knows how your BIND DNS actually works.  If that person retires, or decides to leave the organization, your custom-built BIND infrastructure will be basically impossible to maintain.  Unravelling and making sense of all that code is a huge task, and there are fewer people out there these days who can even make sense of the old-school coding involved in most BIND scripts.

(Are you Mister DNS?  Then you’ve got to watch our hilarious video on why your infrastructure could be better.)

The cost of free

BIND has clear advantages for simple networks, but it simply doesn’t scale well.  BIND is free, but in many cases it ends up costing far more than a purpose-built DDI solution.  BIND can do a lot if you invest time and resources into it, but for most organizations it ultimately fails to deliver the functionality and reliability most modern networks require.

If you’re spending all your time managing patches and trying to configure DNS, attempting to discover why the network is down, or triangulating between DNS, DHCP, and IPAM, then it’s probably time to think about whether your network has reached the threshold where BIND can no longer meet your needs.

BlueCat specializes in seamless migrations from decentralized, highly customized BIND architectures to a unified platform for DDI management.  In over twenty years of working with enterprises of all sizes, our DNS experts have seen every wacky BIND architecture you can think of.  Learn more about the robust features of BlueCat’s DDI platform and why we think your “free” DDI is costing you too much.