DNS Primer and other Info

Information

Tools

DeListing

Listing

General

General

Listing & Delisting

FAQs and Info

Introduction

This is a simple primer aimed at correcting some common mistakes when people run their own DNS servers. The document describes formats that relate directly to BIND format zone files, however the parameters relate directly to other nameservers and if you do not understand the format of your nameserver you should really ask some one to help you.

The BIND format is used because the most common tools used for viewing the end result will report in the native BIND format.

The SOA record.

The SOA record seems to be the biggest cause of issues with people managing their own nameservers, this could be because a few documents exist which explain the last parameter of the SOA in contradicting ways.

The SOA record has seven distinct fields in two main parts. The first part being outside of the parentheses, the second within.

The first part of the SOA record is very simple and in our example below resolves to the following information:

ns0.sorbs.net <--- the server that holds the master zone files.
dnsadmin.sorbs.net <--- the email address of the DNS administrator.

The second part of the SOA record is where the most confusion occurs and it consists of five fields. These fields are described below in the normal order of the record:

2005082810 <--- Serial Number for the zone - this needs to be increased each time a change is made.
7200 <--- Refresh time - the time in seconds between when the secondary nameservers will attempt to contact the master to check for a new zone files.
3600 <--- Retry time - the time in seconds between when the secondary nameserver will attempt reconnection with the master server following an error.
2418200 <--- Expire Time - how long any secondary nameserver will serve queries as valid before returning SERVFAIL (2) because of lack of contact with the master nameserver.
3600 <--- Minimum Cache Time (negative cache TTL) - How long the caching nameserver will remember negative lookups - for example where there is no entry (NXDOMAIN(3))

The last field is the usual one that causes confusion. The original plan was to use the field as the "default TTL", however this was deprecated with the replacement plan the entry is used as the negative cache TTL.

Example Entry:

                           IN      SOA     ns0.sorbs.net. dnsadmin.sorbs.net. ( 
                                                                               2005082810 ; serial
                                                                               7200       ; refresh
                                                                               3600       ; retry
                                                                               2418200    ; expire
                                                                               3600       ; negative cache
                                                                             )

Note: The user part of the email address cannot have a "." in it. This means "dnsadmin@sorbs.net" is valid where "dns.admin@sorbs.net" must not be used in the SOA record. This is because the first period is replaced with the @ symbol.

The $TTL parameter

For setting the TTL on each/all entries the $TTL parameter is used, this parameter can be used multiple times and will change the default value each time it is encountered. For example:

$TTL 3600 <--- will set all entries subsequent to this line as having a 1 hour TTL.
$TTL 86400 <--- will set all entries subsequent to this line as having a 1 day TTL.

A Records

A Records are used to specify IP addresses for hosts. They can also be used to create a single name for a group of hosts. For example you might have 3 web servers in a cluster. A records can also be used to specify an IP address for a domain name, however there are some important considerations to look at when this is implemented. An example of an A records follows:

                           www               IN   A     127.0.0.1
                           www.sorbs.net.    IN   A     127.0.0.1

You'll note that the second line ends in a "." (period) and this is to indicate that the defined domain is not to be appended to the hostname. The first line does not have the period and therefore the zone name will be appended to the hostname. You should not use the definition with the trailing period unless you are sure you know what you are doing.

The following example shows how to specify multiple IP addresses for the same hostname.

                           www               IN   A     127.0.0.1
                           www               IN   A     127.0.0.2
                           www               IN   A     127.0.0.3

MX Records

MX Records are used to specify the mail servers and their priority that receive the mail for this domain. You must not put IP addresses or IP literals in an MX record. An example MX record is as follows:

                           @                 IN   MX 5  mail.sorbs.net.
                           @                 IN   MX 10 scorpion

The first line in this example shows a fully qualified hostname specified (Note the trailing period). The second line specifies just a hostname to which the zone domain name will be appended. Mail should always be delivered to mail.sorbs.net and only be delivered to scorpion.sorbs.net when mail.sorbs.net is not contactable.

Note: MX records should not reference CNAME records as this causes unnecessary recursion.

CNAME Records

The CNAME record is a little different to the other resource records in that there must not be any other records referring to the hostname specified. For this reason you must not specify a CNAME record for a domain name. Example CNAME records follow:

                           www               IN   CNAME sorbs.net.
                           ftp               IN   CNAME www

As with A and MX records you can specify fully qualified hostnames by adding the trailing period.

NS Records

NS Records are probably the biggest cause of misconfigurations for a domain, and yet they are extremely simple when used in the most common configurations. NS records specify the nameservers that are authoritive for a particular domain or sub domain. As with MX records NS records must specify hostnames and not IP addresses. The requirement to specify hostnames and not IP addresses is the part that causes the most issues and misconfigurations with nameservers though.

The chicken and egg problem (otherwise known as "glue" records):

Consider creating the zone for "example.com"... You create two nameservers in the example.com domain called ns0.example.com and ns1.example.com. Following the rules you specify NS records for the domain as follows:

                           @                 IN   NS     ns0.example.com.
                           @                 IN   NS     ns1.example.com.

So now you want to lookup "www.example.com" the problem begins when you ask for the nameservers that are authoritive for example.com... The root nameservers will have the IP address of your nameserver and you will be directed to look the domain up on that server. You then lookup www.example.com record at the nameserver and the server returns the A record that you request... All simple so far?

Ok lets make it complicated we'll add a sub domain ("friend.example.com") to example.com and give that to a friend. The friend then creates his own nameservers called ns0.friend.example.com and ns1.friend.example.com and I create the following entries in my example.com zone file:

                           friend            IN   NS     ns0.friend.example.com.
                           friend            IN   NS     ns1.friend.example.com.

We reload our zones and then test the configuration, and find nothing gets to any address in the sub domain friend.example.com. The reason for the failure is the lack of "glue". The explanation is that the lookup for www.friend.example.com will go to the example.com nameserver and ask for the NS record for friend.example.com to which the server will reply "ns0.friend.example.com" and "ns1.friend.example.com". Your nameserver will then attempt to resolve ns0.friend.example.com to make the final query on www.friend.example.com... so it will lookup example.com and ask the example.com nameservers for the location of the friend.example.com nameservers to which it will return the NS records "ns0.friend.example.com" and "ns1.friend.example.com"... The process then repeats, and repeats and repeats... To solve this issue you need to add "Glue" records these records are simple A records in the parent domain that match the hostname of the nameservers. In our example this would make mean adding the following records:

                           friend            IN   NS     ns0.friend.example.com.
                           friend            IN   NS     ns1.friend.example.com.
                           ns0.friend        IN   A      127.0.0.2
                           ns1.friend        IN   A      127.0.0.3

Using in the real world you would use the $ORIGIN definition, the following example is the 'proper' way:

                           $ORIGIN example.com.
                           @                 IN   NS     ns0.example.com.
                                             IN   NS     ns1.example.com.
                           ns0               IN   A      127.0.0.1
                           ns1               IN   A      127.0.0.2
                           $ORIGIN friend.example.com.
                           @                 IN   NS     ns0.friend.example.com.
                                             IN   NS     ns1.friend.example.com.
                           ns0               IN   A      127.0.0.3
                           ns1               IN   A      127.0.0.4