This paper should provide the reader with a basic understanding of the DNS system as it applies to the Internet.
This paper was written after much discussion on the Fuitadnet forums about DNS, with people raising questions as to what exactly it was, and how it worked. So, I'd like to thank those people for inspiring me to write this. Additional thanks go out to:
MiquelFire for pointing out that I forgot CNAME.
TodPunk for yelling at me about not having good information on zones.
2004-01-14
Rewrote the information on zones.
Added more information the SOA record.
Added information on redundency.
2004-01-08
Added information for various records regarding what happens when multiple records exist.
Added information on zones.
2004-01-07
Started initial draft
If you detect any sort of error, be it factual, spelling, or grammar, or if you wish to see some information added, please contact me at <peter@entropicaccess.net>.
This work is licensed under the Creative Commons Attribution-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
DNS, at it's core, is a system that allows a client to map one piece of data to another. Because of this it is very extensible, capable of providing information on just about anything. However, the use it was designed for, and it's most common use today, is providing a mapping from human readable fully qualified domain names to machine readable IP addresses, as well as auxiliary mappings needed to do this in the most efficient manner.
In order for DNS to be as distributed as it is, it must use a system by which control of various parts of the structure are delegated to different servers. At the absolute top of this hierarchy are the root DNS servers. This set of 13 machines[1] are run by a variety of organizations for the public good of the Internet. These machines in turn redirect queries to the appropriate TLD[2] servers. In turn the TLD server redirects the query to the nameservers specified for that domain. This chain can continue for some time, depending on domain name. The final server than returns the IP address is said to be authoritative for that address.
Let's use the domain debian.lcs.mit.edu. to illustrate this process. It needs to be noted that '.' is the commonly used designation for the root servers.
. is queried and asked about edu, . tells you where to get information on edu.
edu is queried about mit, edu tells you where to get information on mit.
mit is queried for information on lcs, mit tells you where to get information on lcs.
lcs is queried for information debian, lcs knows debian's ip address and tells you.
In reality, this is a slight oversimplification, as we'll cover in the section on the NS record.
A zone is the basic subdivision of the DNS structure. The zone is comprised of all the portions below the first level of the zone, until another server takes over.
While every single query could start at the root servers and work it's way down that would be quite inefficient. Instead, DNS employs a caching mechanism to help reduce burdens on the structure. Every time a DNS server asks for a piece of information it receives, in addition to the information, a TTL[3] for the information. Until this time has expired, it will count the information it received as correct and use it to respond without having to query any other server.
The process used for querying is much the reverse of the layout of the DNS infrastructure described in section 7. Again, we'll use debian.lcs.mit.edu as our target domain.
Your machine, at boot, receives the IP addresses of your local DNS servers. Generally these are run by your ISP.
Your machine requests, from these servers, the IP address of debian.lcs.mit.edu.
If the local DNS knows it (ie, it has it cached) it will return the address.
If it is not known, the local DNS moves up the rung one and sees if it knows about lcs.mit.edu.
If it does, it will use that cached information to query lcs.mit.edu. about debian.lcs.mit.edu.
If it does not, it then proceeds up again, looking for information on mit.edu.
This continues until the local server reaches . -- the root servers --. At this point it knows where to go, as all DNS servers are programmed, by default, with the IP addresses of the thirteen root servers.
Every response that the DNS server makes calls upon a record that machine stores. While there can be any number of record types, there are a set of more commonly used ones. It is quite possible to have more than one record of each type, and the behavior of the client in this case depends on the record type.
The A record is the most basic of the record types, and the most important. It denotes the IP address of the queried host name. Again going with our example of debian.lcs.mit.edu., it's A record is 18.24.10.100.
If a host has more than one record, the client will recieve both. Both addresses are passed on to the program that asked for the lookup to be performed (eg a browser) and it is left to the program to determine how to proceed.
The NS record specifies the host names of the nameservers that can be used to gain more information on any subdomains. So, going back to section 7, when we say that mit or lcs is queried, we don't mean the machine with that A record, but rather the machines in the NS record for those hosts. Thus a modified version of that example would be:
3) The machine(s) specified in mit.edu.'s NS record would tell where to find information on lcs.
4) The machine(s) specified in lcs.mit.edu's NS record would tell the A record of debian.lcs.mit.edu.
If there are multiple NS records, the resolver will, using logic that varies by implementation, pick one of the specified servers and use it. If it fails to respond, another is choosen.
A CNAME record is like an A record in that it tells where a host is located, however rather than give the IP address it specifies another hostname. Unlike A records there can only be one CNAME for a domain name. While this can seems counter intuitive at first, it actually makes for simplified administration. If you have one machine that, say, serves both webpages and ftp and you want to call it www.example.com and ftp.example.com, rather than creating A records for both, you can simply create an A record for one and a CNAME for the other. Then if the IP address changes, you only have to change one record.
The MX, or mail eXchanger, record is used to specify a mail server for that domain. This allows a machine with a name other than the domainname to be sent mail for it. It also allows for backup mail servers to be used as you can specify a priority with each MX record.
Again using our standby example, debian.lcs.mit.edu, we see three MX records:
1 debian.lcs.mit.edu
5 tower.lcs.mit.edu
10 mintaka.lcs.mit.edu
This tells us that debian.lcs.mit.edu will accept it's own mail, if it's able. If it is not able to, for whatever reason (down for a kernel upgrade perhaps) then tower will accept the mail in debian's stead. If both debian and tower are down, then mintaka will accept the mail instead. If no MX record were to be specified, most mail servers would then try the A record.
The AAAA record is a fairly new (as these things go) record used to map IPv6 addresses. It is very similar to the A record, with the only real difference being that it provides an IPv6 address, to A's IPv4.
While debian.lcs.mit.edu doesn't have an AAAA record, debian.ipv6.lcs.mit.edu does, two in fact:
2001:470:106:180a:202:e3ff:fe00:4c75
2002:121a:12:180a:202:e3ff:fe00:4c75
Like A records, where more than one AAAA record exists, all the records are passed back to the program that initiated the lookup.
The SOA record defines some basic information about the domain. Basically it defines ownership of the domain, as well as establishing various default values for the domain. It's worth pointing out that, generally, only the highest level will have a SOA record.
Again going with debian.lcs.mit.edu, the domain with the SOA record would be lcs.mit.edu. In this case the SOA record is:
In this case, mintaka.lcs.mit.edu is the master authoritative DNS for the domain, bug-lcs-domain.lcs.mit.edu is the email of the administrator of the domain, with the @ replaced with a '.'. The number 252885175 is the serial number of the domain. This number is arbitrary, by and large, with the only requirement being that the number increase each time the zone is changed. The first 1800 specifies the time between refreshes of slave servers (see Redundancy). The 300 specifies the retry time for a slave server if it has dificulties reaching the master server. The 604800 specifies the amount of time a slave server will continue to give out zone information if it can't contact the master. The final 1800 denotes the TTL of a negative resonse.
There are two ways in which a zone can be rendered redundant. To the outside observer they are by and large identical, but the implementation is different.
With this set up, there are two or more machines set up to be the masters of the zone. This means that they get information on what hosts are in that domain from a local source, generally a set of files on the server. Most commonly this would be used when a large distance and slow link connect the master servers. In this set up it is essential that all servers have the same set of configuration files.
A slave server differs from a master in that it does not get it's configuration from a local source. Rather, it queries the master server and asks for a zone transfer, which it then uses to answer queries. Information on how long it should use this copy, and when it should get a new one is set by the SOA record for the zone.
| [1] | In reality, none of the root servers are actually one single machine, rather they are clusters of servers acting as one machine. For more information you can check out http://root-servers.org/. |
| [2] | Top Level Domains, eg com,net, org, ca, uk. |
| [3] | Time To Live |