DNS Primer

The purpose of DNS (Domain Name System) is to function as a lookup service mapping readable domain names such as solidosystems.com to IP addresses such as 91.102.90.14. DNS is one of the earliest technologies of the internet, dating back to 1983. Unlike the SMTP protocol we looked at in the previous blog post, DNS is in no way a readable protocol that can be manipulated by hand. All examples in this little DNS tutorial will thus use an application to interface with the DNS system. We will use dig which is part of most UNIX systems today, but you can use any tool available on your platform.

Lets start out by looking up the domain for this web site solidosystems.com. Using dig, we do this simply by executing "dig solidosystems.com". The following is what this looked like on my machine. Depending on the version of dig installed on your system, you might get a slightly different output, but the primary information should be the same.

> dig solidosystems.com

; <<>> DiG 9.4.1-P1 <<>> solidosystems.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16964
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;solidosystems.com.     IN  A

;; ANSWER SECTION:
solidosystems.com.  13888   IN  A   91.102.90.14

;; AUTHORITY SECTION:
solidosystems.com.  10552   IN  NS  ns001.dnspilot.com.
solidosystems.com.  10552   IN  NS  ns002.dnspilot.com.

;; ADDITIONAL SECTION:
ns001.dnspilot.com. 167941  IN  A   217.116.236.67
ns002.dnspilot.com. 153410  IN  A   217.116.236.68

;; Query time: 125 msec
;; SERVER: 194.239.134.83#53(194.239.134.83)
;; WHEN: Mon Jan  7 10:26:48 2008
;; MSG SIZE  rcvd: 132

If this is the first time you see the output of dig, it might look slightly overwhelming, but once you know what you are looking for, it's actually pretty simple. First of all, all lines starting with a semicolon are comments (depending on your version of dig, they might start with a hash instead). Next, the part you really want to look at, is the single line after the comment ";; ANSWER SECTION:". That's the actually answer to our query. Let's have a closer look at that.

solidosystems.com.  13888   IN  A   91.102.90.14

The first part is pretty obvious. That's the domain we wanted the IP for. The next part is a number. It is the TTL (time to live) of the response we got. That is, the number of seconds we are allowed to remember this answer for before we have to look it up again. Some times, the TTL will be delivered in a format such as 2d, meaning two days. The next part "IN" tells us the class of the record (don't worry about this, IN is basically the value you will see every time). The next part "A" tells us that the record we looked up is an A record. This is the most basic type of record which always points from a hostname such as solidosystems.com to an IP address such as 91.102.90.14. There are many other record types. We will look at the most commonly used later in this post.

So how exactly did this lookup work? Typically, your machine will have one or more DNS servers configured, which it will contact for all queries. So all dig really does, is contacting your server and asking it for the result of the query. In the output above, you can see the server that was contacted in my query "194.239.134.83". This server will be the one that does the actual work.

The first thing it will do is to contact the root DNS server to ask which DNS server it can contact to ask questions about .com. Then it will ask that server which server it can contact to ask questions about solidosystems. Finally it will ask that server the actual question. Each of these questions will be formed as a regular DNS query, just like our solidosystems.com query. It might seem like a lot of work to do every single time, but in reality, the root servers responsible for the top level domains, such as .com, .net and .org change very seldom. The response our DNS server got for the question about who to ask for .com questions will thus have a very long TTL. This means that in reality, all it had to do was ask that server which DNS server is responsible for solidosystems.com. That answer was actually part of the result we got back, under the section titled ";; AUTHORITY SECTION:".

;; AUTHORITY SECTION:
solidosystems.com.  10552   IN  NS  ns001.dnspilot.com.
solidosystems.com.  10552   IN  NS  ns002.dnspilot.com.

We could actually contact one of these servers directly for the answer to our query by issuing the following command "dig @ns001.dnspilot.com solidosystems.com". However, the whole idea behind the recursive nature of the DNS architecture is that you don't need to know which server to ask to get an answer for your query. All you need is the root server.

I mentioned previously that there are several different types of records. The most commonly used are A, CNAME, MX and NS. Each of these will be discussed separately in the following subsections.

NS Records

These are the records that make it all possible. Have a look at the authority section in the previous example. The NS records are the ones who tells us which name servers we can contact for queries about a given domain. That is in fact what NS stands for - Name Server. You don't really need to know much more about NS records unless you need to configure domains for yourself by writing zone files (more about this in a later post).

A Records

As mentioned in our example, an A record is a record that points from a hostname to an IP. A stands for Address. A domain can have more than one A record with the same hostname pointing to different IP's as well as more than one hostname pointing to the same IP.

CNAME Records

CNAME records are an alias from one record to another. Let's have a quick look at another query for a CNAME record. In this example, we will look up www.solidosystems.com.

> dig www.solidosystems.com

; <<>> DiG 9.4.1-P1 <<>> www.solidosystems.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5103
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.solidosystems.com.     IN  A

;; ANSWER SECTION:
www.solidosystems.com.  14400   IN  CNAME   solidosystems.com.
solidosystems.com.  10841   IN  A   91.102.90.14

;; AUTHORITY SECTION:
solidosystems.com.  7505    IN  NS  ns002.dnspilot.com.
solidosystems.com.  7505    IN  NS  ns001.dnspilot.com.

;; ADDITIONAL SECTION:
ns001.dnspilot.com. 164894  IN  A   217.116.236.67
ns002.dnspilot.com. 150363  IN  A   217.116.236.68

;; Query time: 77 msec
;; SERVER: 194.239.134.83#53(194.239.134.83)
;; WHEN: Mon Jan  7 11:17:34 2008
;; MSG SIZE  rcvd: 150

Just as in the previous query, the result we are looking for will be in the answer section. In this case, we got two records as part of our result. The first tells us that www.solidosystems.com is a CNAME record that points to the record solidosystems.com. The second part of the answer, is simply the result of looking up the solidosystems.com record.

A CNAME record may also point to another CNAME record, or even to a record on a different domain.

MX Records

The MX record type is a newer addition to the DNS system than the other records we have looked at. MX stands for mail exchange. These records are used to specify which servers you should try when delivering email to a domain. Lets have a look at an example, once again looking up records for solidosystems.com. To do this with dig, we simply specify the record type mx after the domain name.

> dig solidosystems.com mx
; <<>> DiG 9.4.1-P1 <<>> solidosystems.com mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29755
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 6

;; QUESTION SECTION:
;solidosystems.com.     IN  MX

;; ANSWER SECTION:
solidosystems.com.  14400   IN  MX  20 frontend02.mailsafe.dk.
solidosystems.com.  14400   IN  MX  10 frontend01.mailsafe.dk.

;; AUTHORITY SECTION:
solidosystems.com.  8986    IN  NS  ns002.dnspilot.com.
solidosystems.com.  8986    IN  NS  ns001.dnspilot.com.

;; ADDITIONAL SECTION:
frontend02.mailsafe.dk. 888 IN  A   217.116.236.14
frontend02.mailsafe.dk. 888 IN  A   217.116.236.188
frontend01.mailsafe.dk. 93  IN  A   217.116.236.12
frontend01.mailsafe.dk. 93  IN  A   217.116.236.189
ns001.dnspilot.com. 146062  IN  A   217.116.236.67
ns002.dnspilot.com. 146062  IN  A   217.116.236.68

;; Query time: 72 msec
;; SERVER: 194.239.134.83#53(194.239.134.83)
;; WHEN: Mon Jan  7 11:29:39 2008
;; MSG SIZE  rcvd: 245

As usual, we need to look in the answer section for the result of our query. This time, we got two records on another domain. Notice how each of them has an additional piece of numeric data... 20 and 10. These are the priorities of the MX records. A domain can have any number of MX records. It can even have more than one with the same priority.

When you wish to deliver email for a specific domain, you look up all the mx records for the domain and sort them by priority. Then you attempt to contact the servers starting at the lowest priority. If two records have the same priority you try one of them at random. The reason for this added complexity is to allow for an easy configuration of mail server redundancy.

That's about it for now... it might seem a bit daunting if you haven't read anything about DNS before, but at least you should now know what the primary record types are and how to look them up manually using dig.