ntang (ntang) wrote,

DNS basics

I wrote this up after a coworker asked some questions about DNS. Some of the geekier people out there might find it interesting. Probably not, but who knows? :)

And hey, feel free to make comments about it. At some point I'm going to touch it up and put it on our internal doc site and maybe on my website too, if I like it enough on a second look, so any comments about improvements would be appreciated.

The Magic of DNS

There are two types of DNS servers: authoritative, and (recursive) caching (or probably more correctly, authoritative and non-authoritative).

An authoritative server has authoritative information for a domain - basically, it has the information internally and is an authority for that domain, it "owns" it. It will only respond for domains that it is authoritative for.

A caching dns server isn't authoritative for any domain; it will return responses for any domain on the internet, and makes no claim as to their validity - it is simply doing recursive lookups through the servers on the internet and returning the results it finds.

(Technically you could call forwarding dns servers a third type; they act like proxy servers and merely forward the requests on to other servers and forward the responses back to the clients; they don't attempt to lookup the requests directly.)

The tricky thing about the ISC BIND name server is that it combines all of that functionality into one monolithic piece, and is part of the reason so many people get confused about DNS.

So... when you're setting up a BIND server, you define zones in the named.conf file. (I'm talking all BIND 8 here; we don't use BIND 4 or 9 anywhere in here as far as I know.) Those zones are set up as master or slave zones. When you set up a zone in named.conf, you're creating an -authoritative- zone. In other words, that server "owns" the zone and will not contact any other servers to get information on it - if it doesn't know it, the query will fail.

The difference between a master and a slave server is purely a BINDism - they're really just authoritative servers, plain and simple. Generally, rather than update config files on every authoritative server you have (and we have several), you just want to update it on one, and then sync the changes out. The machine that has the actual zone files is known as the master; when it sends out copies of those zone files to the other servers (the slaves), that's known as a zone transfer. As far as any client can tell, however, they are ALL THE SAME. That's an important note to remember, the whole difference between master/slave is internal to BIND and is not part of the DNS protocol.

Any zone that the BIND server isn't authoritative for it will act as a recursive caching name server for - in other words, it will query the Root nameservers for information on them, and then contact the authoritative servers for that domain to make the actual query. It then generally caches the information for next time, which is why it's called a caching name server.

There's also the third case of the forwarding name server, in which case all non-authoritative queries are simply forwarded on to the forwarders, and the replies are sent back to the client, and the server doesn't really do much other than proxy the requests back and forth.

As I mentioned, BIND gets complex to run and hard to understand sometimes, because it can do all of the above. Technically they are all separate functions, but it does them all at once so you have to take that into account.

So, when someone here makes a request for foo.internal.communityconnect.com, it will hit our local dns server. That dns server will see that it isn't authoritative for internal.communityconnect.com, and will then forward the request on to the forwarders. If it wasn't set up to forward, it would make an NS request for internal.communityconnect.com to the root nameservers, and then make the request directly to one of the servers that was returned.

Here's how a master zone looks in BIND:

zone "foo.com" in {
type master;
file "master/foo.com";

All that you need to tell it is the actual domain (foo.com) and the file to look up the entries in (master/foo.com).

Here's how a slave zone looks:

zone "bar.com" in {
type slave;
masters {;; };
file "slave/bar.com";

This is similar, but instead of making requests to a file, it will do a zone transfer from one of the master servers for the domain, and then save a local copy in a file cache (slave/bar.com).

This is a recursive caching set up:

zone "." in {
type hint;
file "named.cache";

That basically says "for all domains I don't know, act as a caching server, and pull the root servers from the file named.cache".

  • Where I am nowadays

    I haven't updated this in a million years... in case you're wondering why, it's because I've mostly moved on to other places. You can find my…

  • DSL

    I've been a loyal Megapath customer for years. (Something like 8 or 10, crazy, in that range...) They've had great service (and a great service -…

  • MySQL failover

    So we're running some MySQL at work, which is a little unusual for us, but is probably long overdue. (Specifically, it's for some Wordpress…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded