So you want to run your own domain name server inside your own network. What could possibly go wrong? Me, I’ve setup enough flavors of DNS enough times on enough distros of Linux to already feel the fight-or-flight reflex starting. But really, it’s not that bad. Honest! Let’s walk through the 762,346,754,358,660,834,587 simple steps to setting up a shiny new DNS server.
Let’s assume that you’re not alone in DevOps, but you’ve got a team. Great! (Teams are awesome because you get to delegate the icky bits, like configuring DNS!)
First, you’ve got to choose the DNS server software. The main problem with this is that it’s a lot like asking your friends which beer they think is best—if you ask five sysadmins what the best open source DNS server is, you’ll get six different answers. And you’ve got to watch out for the rabid proponents of some solutions; you know, the guys who’ll chase you with pitchforks and torches while screaming something unintelligible about Dan Bernstein.
Next, you’ve got to install the server. Then you get to go figure out where in %#$@! it put its configuration files. Once you find them, you get to edit them. But wait! You’re not the only person who’s going to edit them. Better check them into a versioning system.
Put DNS on hold for a moment, and go create a GitHub repo. Check the repo out, copy all the config files into it, and commit ‘n push them. Awesome sauce. Now hop back on the server, and wait a minute…how are you going to get the latest repo changes into your DNS server?
cron to the rescue! Whip up a job that pulls your GitHub repo every minute in the appropriate place, throw down some symlinks, and you’re all set!
But wait, there’s more! The DNS daemon needs to be told to reload when a zone changes. Of course, you could just throw another cron job in the mix that reloads the daemon every minute. But that’s beyond awful. Or you could whip up a script that figures out if a file has changed since it last ran, and if it has, reloads the process. Or you could dump the entire thing into your configuration management system, like Puppet or Chef. Or you could totally ninja a post-commit hook in git that reloads DNS. Or you could hire a junior sysadmin to run
ls every minute in the appropriate directory. I once wrote a tiny Perl script for a client that was run on boot, called
fork() like a good AT&T System V daemon, and then endlessly looped, watching the modification timestamp of
/var/named and when it changed, reloaded
But regardless of the solution, let’s say you’ve got your DNS service automagically reloading when a zone file is changed. Next up is actually doing something with this spectacular system, i.e., actually editing the zone files and adding records. And syntax matters everywhere, since stuff has a way of just quietly dying if you leave even a single ; out of the right place. And that means you better monitor the whole thing, because with multiple people making multiple edits in a repo that is automatically pulled and a DNS server that is automatically reloaded, something is bound to explode into flame, sooner rather than later.
I once had a client for whom easily more than half of my support calls were in response to someone trying to make a simple zone record change. It got to where I seriously considered adding
tail /var/log/named.log to my
.bashrc. Seriously. For something so seemingly simple, operating your own DNS servers is terrifyingly complex and fraught with difficulty.
But don’t despair, there’s another option!
Have NSONE deploy Private DNS in your network. You give us a box, and we give you a powerful API, a dazzling UI, full audit logging, and the fastest and most resilient DNS network in the world. And five minutes later, you’re relaxing in a cafe, sipping an espresso and luxuriating in the knowledge that you’ve got a rock-solid DNS implementation in your infrastructure — on premise, in the cloud, wherever you need it.
It’s actually that easy. Just delegate DNS to NSONE!