Implementing DNS on Linux - Part II

In my previous post, Implementing DNS on Linux - Part I, I explained the syntax of /etc/named.conf file. In this post, I will explain the rest of the steps needed to implement DNS in Linux using BIND.

Zone Files

Zone files reside in the /var/named/ directory. These files are those named in the /etc/named.conf file with the 'file' directive.

For example, in Part -I of this post, I had created a zone called mysite.com which had a file directive by name "mysite.com.zone". So I move to /var/named/ directory and create a file by the same name here.

# touch mysite.com.zone

Similarly for each zone you have created in /etc/named.conf file, you should have a corresponding file by the same name as that given in the file directive in the /var/named/ directory.

Syntax of Zone File

• Begins with $TTL (Time To Live). This determines the default length of time in seconds which you want resolving servers to cache your zone's data.
• First resource record is zone's Start Of Authority (SOA).
• Zone data in additional resource records.
• Fully qualified domain names (FQDN) in zone file must end with a dot (.) .
  
  BIND assume that the names that don't end with a dot should end with the name of the current domain. Always use a dot at the end of a name that is fully qualified.
• Semi colons ; in database files signify a comment to the end of line.
  

Example :

; FILE : mysite.com.zone
$TTL  86400  ; Time to Live in Seconds

@ IN SOA ns.mysite.com. root.mysite.com. (
20011042501  ; Serial Number.
300  ; refresh.
60  ; retry
1209600 ; expire
43200 ; minimum TTL for negative answers.
)
...

The @ is interpreted as the name of the originating domain - mysite.com in the above example. The @ itself is not mandatory, but the domain must be indicated. The values of fields between the brackets, except for the first, are time periods.

Serial numbers - Are based on ISO dates. Every time the data in the database is changed, the serial number must be increased in order that the slave servers know the zone has changed.

Refresh - Is the delay time that slave name servers should wait between checking the master name server's serial number for changes. A good value is one hour.

Retry - is the delay time that a slave name server should wait to refresh its database after a refresh has failed. One minute is a good value.

Expire - is the upper time limit that a slave name server should use in serving DNS information for lack of a refresh from the master name server. A good value is 7 days.

The minimum time to live for negative answers specifies how long a nameserver should cache a "no such host" response from an authoritative server of the domain. This reduces load on the server.

Note that all times are in seconds by default. However, the following may be used :
W = Weeks
D = Days
H = Hours
M = Minutes

Must use capital letters, no space between the number and the unit is allowed.

The last string in the first line of the SOA record (root.mysite.com. in the above example) specifies the contact person for the domain. Conventionally, the responsible party's email address is used, replacing the @ with a dot.

Types of Records in a Zone File
Name Server NS

There should be an NS record for each master or slave name server serving your zone. NS records point to any slave servers that should be consulted by the client's name server if the master should fail.

; FILE : mysite.com.zone
...
@  IN  NS  ns.mysite.com.
mysite.com.  IN  NS  ns1.mysite.com.
...

NS records designate name servers to use for this domain. It should contain at least one DNS server that is authoritative for the zone. A list of slave servers that can be referenced is commonly included. Fully qualified names must be used for NS resource records. The @ notation allows the domain name to be taken as the originating domain for the zone.

A record - An A resource record maps a hostname - which may or may not be fully qualified - and an IP address.

; FILE : mysite.com.zone
...
mail  IN  A  192.100.100.5
login.mysite.com.  IN  A  192.100.100.6
...

PTR - These are the inverse of A records - they map an IP address to a hostname. For reverse lookups - that is, PTR records - specify the octets of the domain in the reverse order. For example, if the zone was defined as 100.192.in-addr.arpa, then the name server would expand the PTR reference in the slide into 6.100.100.192.in-addr.arpa. A lookup of 192.100.100.6 would find this reference and would return login.mysite.com.

; FILE : mysite.com.zone
...
login.mysite.com.  IN  A  192.100.100.6
6.100  IN  PTR  login.mysite.com.
...

MX - These records are used to define mail handlers (or, exchangers) for a zone. MX records must have a positive integer listed immediately after the MX and before the host name. This integer is used by remote Mail Transport Agents (MTA) to determine which host has delivery priority for the zone.

; FILE : mysite.com.zone
...
mysite.com.  IN  MX 5  mail.mysite.com.
mysite.com.  IN  MX 10 mymail.mysite.com.
...

Precedence is given to the mail exchanger with the lowest priority. If that host is not up, then the next lowest priority mail exchanger will be used. If none of the mail exchangers are up, then the mail will be returned to the forwarding SMTP server to be queued for later delivery.

CNAME - These records map address aliases.

; FILE : mysite.com.zone
...
pop   IN  CNAME mail
ssh   IN  CNAME login.mysite.com.
...

Note: CNAME, A and PTR resource records comprise the bulk of resources seen in the database files. Incorrect setup of these records can cause many problems, so they should always be evaluated carefully before changes are committed.

Round-Robin load sharing through DNS
Load balancing can be achieved through the simple use of multiple A records.

; FILE : mysite.com.zone
...
www  0 IN  A 192.168.1.10
www  0 IN  A 192.168.1.11
www  0 IN  A 192.168.1.12
...

Note: DNS traffic will increase because a TTL of 0 means queries will never be cached.

To be Contd...