How DNS Works - A View From 50,000 feet

[knightfoo]

This is just a quick rundown of the general concept and function of DNS (Domain Name Service). I know this will seem very basic to a lot of people, but I think there are a lot of misconceptions and lack of understanding of some aspects of DNS. DNS is something that most people never see or deal with, so it is easy to take for granted. I see a lot of people trying to brute-force DNS into working the way they think it should work, with very little success .. the rules are simple, but they must be followed.

All DNS delegation starts with the 13 DNS root servers (a-m.root-servers.net). These nameservers know about every recognized TLD (top level domain) and know which nameservers maintain the information for domains registered in each TLD. For .com and .net domains, the GTLD servers (a-m.gtld-servers.net) know about every registered domain in the .com and .net TLDs and know which nameservers maintain the information for those domains.

How does this information get into the GTLD servers? Whenever you register a domain, the domain registrar submits the information to the GTLD servers. The GTLD servers store the NS records for each nameserver you registered for that domain. When you register nameservers, the registrar also instructs the GTLD servers to store the A records for each nameserver. These A records are called "glue records" .. without glue records, no one would be able to find your nameserver. This is why you *must* register your nameservers before you can actually use them.

Now for an example. When someone attempts to resolve www.serverbeach.com, this is what happens:

$ host -v-t ns com. a.root-servers.net
com NS A.GTLD-SERVERS.NET
Additional information:
A.GTLD-SERVERS.NET 172800 IN A 192.5.6.30
(this is the glue record for a.gtld-servers.net)

$ host -v -t ns serverbeach.com a.gtld-servers.net
serverbeach.com NS ns1.serverbeach.com
serverbeach.com NS ns2.serverbeach.com
Additional information:
ns1.serverbeach.com 172800 IN A 66.139.72.5
ns2.serverbeach.com 172800 IN A 66.139.72.21
(these are the glue records for our nameservers)

$ host -t a www.serverbeach.com ns1.serverbeach.com
www.serverbeach.com A 66.139.72.12

If you drew a picture of the overall DNS structure of the Internet, it would look like an upside down tree, starting with the "." zone at the top, then a branch for "com", "net", "org", etc, then a branch from each one of those for each domain registered in those TLDs. The lookups always start at the very top (at the root servers) and work their way down.

The only exception to my previous statement is when nameservers cache DNS lookups. Caching is very important, especially when there are hundreds of thousands of domains and millions of Internet users doing DNS queries all the time. The root servers (and every other authoritative DNS server) would be swamped in no time. The DNS records are cached for the amount of time specific by the TTL (time to live) in your DNS zones. This is why it takes a while for changes to DNS data to propagate across the Internet .. you need to wait for all of the nameservers to expire their cache and go looking for new information.

This should be enough information to get you into just enough trouble to have to ask someone for help. A really good book for learning about DNS is "DNS and Bind" by O'Reilly .. it has all you would ever want to know about DNS, short of how to write your own DNS server. So far I haven't been bored enough or annoyed enough with named and start writing my own DNS server though .. yet.

-knightfoo

[QT]

Kind of looks like the view from 5 feet 6 inches too! :p

[knightfoo]

You just said that to get 500 posts, didn't you? :p

-knightfoo

[QT]

Originally posted by knightfoo
You just said that to get 500 posts, didn't you? :p

-knightfoo

No...really...I have the same view from down here! ;)

and I have 500...err 501 posts too!

:D


On a more serious note, thanks for the view .. err..the informative post. :)

[Shade]

Thanks for the crash course, as it were - I get it now.

-Shade

[dhigbee]

Thanks knightfoo for the high level view. My nose is bleeding from the altitude.

But seriously, there really is a whole lot more to DNS. Another good source and explantion about DNS, down the nity grity, is Linux Red Hat (7, 8, or 9) Server by Kabir (Wiley Press). In fact this book has some very good information on how to run a Linux server. This book focuses on the server and not the Linux Gui as most Linux books do.

Just thought I would share.

Don

[knightfoo]

Originally posted by dhigbee
Thanks knightfoo for the high level view. My nose is bleeding from the altitude.

But seriously, there really is a whole lot more to DNS. Another good source and explantion about DNS, down the nity grity, is Linux Red Hat (7, 8, or 9) Server by Kabir (Wiley Press). In fact this book has some very good information on how to run a Linux server. This book focuses on the server and not the Linux Gui as most Linux books do.

Just thought I would share.

Don

Yeah, there is a lot more to DNS, but people normally start looking at me funny when I describe how the daemon reads the packets as they come in. ;) This should be enough for the average hoster to at least get their domains registered and resolving properly .. I'll leave the complex stuff for another day.

-knightfoo