DNS – One Server (Does Not) Fit All

Hi!  If you’ve been reading about DNS on my blog, you probably understand the importance of having DNS services, you have some idea about why you might want to run your own DNS server, and you realize that protecting your online brand means protecting your domain registration.  What I’d like to talk about this time is how many DNS servers you should plan to operate.

BIND, which stands for Berkley Internet Name Daemon, is a DNS server that’s been designed to be able to provide every kind of DNS service you might need.  It is the most commonly and widely used DNS server in the market, and it’s also open source and free.  Technically speaking, you could theoretically run a single BIND server that hosts your internal domain, and provides your users and customers with a DNS resolver.  A lot of organizations with limited resources start out this way.  But even if you’re forced to start out with a setup like this, it’s not a good idea to keep it like this.

The problem with a one-server-fits-all approach is that if anything happens to degrade your DNS server’s performance, you can impact all of your DNS services.  The DNS protocol is designed to run a distributed service with multiple servers sharing the load and making the DNS services very resilient.  By splitting the service up among several servers, you insure that a problem with one server does not impact your entire DNS infrastructure.

Every domain that you own needs to have a Master DNS server.  This server holds the master copy of every domain, also called a zone.  Every time you need to add, remove, or change a DNS record, you need to modify this master copy.  For this reason, the Master DNS server should be well-secured so that unauthorized persons can’t make changes they aren’t supposed to make.  If you have a lot of domains, you can split them up between multiple Masters.  You can also hide the Master from the public internet to keep them safer.  

The DNS protocol also provides for the ability to send duplicate copies of your domain records to Slave DNS servers.  Using Slave servers allows you to be able to continue operating your domains even when one server goes down, since the copies are available from multiple locations.  A good thing about a Slave server is that the domain copies it holds are basically fixed and can’t be changed without changing either the master copy on the Master server or modifying the configuration so that it becomes a Master.  If you lose your Master server, it’s possible to promote one of the Slaves to take its’ place.

Master and Slave DNS servers are also called Authoritative servers, since they are the authority about what DNS records are actually in your domain.  According to the domain registration rules, you must have two authoritative servers for any public domain you own, but you may have more.  If you’re running your own private, internal, non-registered domain, you could get by with just one Master server but having at least one Slave is still good ‘insurance’.

For security reasons, you don’t want your Authoritative servers doing anything but answering DNS queries for the domains that you own (or manage).  You don’t want them going out to the public Internet to get the answer for a domain they’re not authoritative for.  This is where Cache servers come in.

A Cache server’s only job is to go get DNS information from DNS servers outside your organization.  It’s called a Cache server because once it gets an answer it keeps it for a period of time so that it doesn’t have to look it up all over every single time.  This makes it more efficient.  It’s also called a recursive nameserver because it repeats each query more than once as it talks to different DNS servers to fetch the complete answer.  Having more than one cache server allows your DNS infrastructure to handle more requests with fewer timeouts and bottlenecks, and it allows you to place them on the edges of your network closer to where your users and customers are.  This means faster responses and it also means that if one cache server goes down it doesn’t have to affect all of your users.

In my mind, a good, robust DNS architecture means having at least one Master server, at least one or two Slave servers, and two or more Cache servers.  Having this many DNS servers means that your DNS service is much less likely to go down.


Leave a comment

Filed under DNS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s