Linux BIND DNS - Part 2: Configuring db.domain Zone Data File

It's time to start creating our zone files. We'll follow the standard format, which is given in the DNS RFCs, in order to keep everything neat and less confusing.

First step is to decide on the domain we're using and we've decided on the popular firewall.cx. This means that the first zone file will be db.firewall.cx. Note that this file is to be placed on the Master DNS server for our domain.

We will progressively build our database by populating it step by step and explaining each step we take. At the end of the step-by-step example, we'll grab each step's data and put it all together so we can see how the final version of our file will look. We strongly beleive, this is the best method of explaining how to create a zone file without confusing the hell out of everyone!

Constructing db.firewall.cx - db.domain

It is important at this point to make it clear that we are setting up a primary DNS server. For a simple DNS caching or secondary name server, the setup is a lot simpler and covered on the articles to come.

The first entry for our file is the Default TTL - Time To Live. This is defined using the $TTL control statement. $TTL specifies the time to live for all records in the file that follow the statement and don't have an explicit TTL. We are going to set ours to 24 hours - 86400 seconds.

The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Newer DNS methods that are part of a DR (Disaster Recovery) system may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are "per record" and setting this value on specific records is normally honored automatically by all standard DNS systems world-wide.   Dynamic DNS (DDNS) usually have the TTL value set to 5 minutes, or 300 seconds.

Next up is the SOA Record. The SOA (Start Of Authority) resource record indicates that this name server is the best source of information for the data within this zone (this record is required in each db.DOMAIN and db.ADDR file), which is the same as saying this name server is Authoritative for this zone. There can be only one SOA record in every data zone file (db.DOMAIN).

Let's explain the above code:

firewall.cx. is the domain name and must always be stated in the first column of our line, be sure you include the trailing dot "." after the domain name, we'll explain later on why this is needed.

The IN stands for Internet. This is one class of data and while other classes exist, you won't see them at all because they are not used :)

The SOA is an important resource record. What follows is the actual primary name server for firewall.cx. In our example, this is the server named "voyager" and its Fully Qualified Domain Name (FQDN) is voyager.firewall.cx. Notice the trailing "." is present here as well.

Next up is the entry admin.voyager.firewall.cx. which is the email address of the person responsible for this domain. Take the dot "." after the admin entry and replace it with a "@" and you have a valid email address: This email address is being protected from spambots. You need JavaScript enabled to view it.. Most times you will see root, postmaster or hostmaster instead of "admin".

The "(" parentheses allow the SOA record to span more than one line, while in most cases the fields that follow are used by the secondary name servers and any other name server requesting information about the domain.

The serial number "1 ; Serial Number" entry is used by the secondary name server to keep track of changes that might have occured in the master's zone file. When the secondary name server contacts the primary name server, it will check to see if this value is the same. If the secondary's name server is lower than the primary's, then its data is out of date and, when equal, it means the data is up to date. This means when you make any modifications to the primary's zone file, you must increment the serial number at least by one.

Note that anything after the semicolon (;) is considered a remark and not taken into consideration by the DNS BIND Service. This allows us to create easy-to-understand comments for future reference.

The refresh "3h ; Refresh after 3 hours" tells the secondary name server how often to check the primary's server's data, to ensure its copy for this zone is up to date.

If the secondary name server tries to contact the primary and fails, the retry "1 h ; Retry after 1 hour" is used to tell the secondary name server how long to wait until it tries to contact the primary again.

If the secondary name server fails to contact the primary for longer than the time specified in the fourth entry "1 w ; Expire after 1 week", then the zone data on the secondary name server is considered too old and will expire.

The last line "1 h ) ; Negative caching TTL of 1 day" is how long a name server will send negative responses about the zone. These negative responses say that a particular domain or type of data sought for a particular domain name doesn't exist. Notice the SOA section finishes with the ")" parentheses.

Next up in the file are the name server (NS) records:

These entries define the two name servers (voyager and gateway) for our domain firewall.cx. These entries will be also in the db.ADDR file for this domain as we will see later on.

It's time to enter our MX records. These records define the mail exchange servers for our domain, and this is how any client, host or email server is able to find a domain's email server:

Let's explain what exactly these entries mean. The first line specifies that voyager.firewall.cx is a mail exchanger for firewall.cx, just as the second line (...IN MX 20 gateway...) specifies that gateway.firewall.cx is also a mail exchanger for the domain. The MX record indicates that the following hosts are mail exchanger servers for the domain and the numbers 10 and 20 indicate the priority level. The smaller the number, the higher the priority.

This means that voyager.firewall.cx is a higher priority mail server than gateway.firewall.cx.  If another server trying to send email to firewall.cx fails to contact the highest priority mail server (voyager.firewall.cx), it will then fall back to the secondary, in which our case is gateway.firewall.cx.

These entries were introduced to prevent mail loops. When another email server (unlikely for a private domain like mine, but the same rule applies for the Internet) wants to send mail to firewall.cx, it will try to contact first the mail exchanger with the smallest number, which in our case is voyager.firewall.cx. The smaller the number, the higher the priority if there are more than one mail servers.

In our example, if we replaced:

firewall.cx. IN MX 10 voyager.firewall.cx.

firewall.cx. IN MX 20 gateway.firewall.cx.

with

firewall.cx. IN MX 50 voyager.firewall.cx.

firewall.cx. IN MX 100 gateway.firewall.cx.

the result in matter of server priority, would be the same.

Let's now have a look our next part of our zone file: Host IP Addresses and Alias records:

Most fields in this section are easy to understand. We start by defining our localhost (local loopback) "localhost.firewall.cx. IN A 127.0.0.1" and continue with the servers on our private network, these include voyager, enterprise, gateway and admin. The "A" record stands for IP Address. So "voyager.firewall.cx. IN A 192.168.0.15" translates to a host called voyager located in the firewall.cx domain with an INternet ip Address of 192.168.0.15. See the pattern? :)

The second block has the aliases table, where we created a Canonical Name (CNAME) record. A CNAME record simply maps an alias to its canonical name; in our example, www is the alias and voyager.firewall.cx is the canonical name.

When a name server looks up a name and finds CNAME records, it replaces the name (alias - www) with its canonical name (voyager.firewall.cx) and looks up the canonical name (voyager.firewall.cx).

For example, when a name server looks up www.firewall.cx, it will replace the 'www' with 'voyager' and lookup the IP Address for voyager.firewall.cx.

This also explains the existance of "www" in all URLs - it's nothing more than an alias which, ultimately, is replaced with the CNAME record defined.

The Complete db.domain Configuration File

That completes a simple domain setup! We have now created a working zone file that looks like this:

A quick glance at this file tells you a lot about our lab domain firewall.cx, and this is probably the best time to explain why we should not omit the trailing dot at the end of the domain name:

If we took gateway.firewall.cx as an example and omitted the dot "." at the end of our entries, the system would translate it like this: gateway.firewall.cx.firewall.cx - definately not  what we want!

As you see, the 'firewall.cx' is appended to the end of our Fully Qualified Domain Name for the particular resource record (gateway). This is why it's so important to never forget that extra dot "." at the end!

Our next article will cover the db.ADDR file, which will take the name db.192.168.0. for our example.