A special domain, localhost, will be predefined in most cases.

Here is the corresponding zone file /etc/bind/db.local called from the example named.conf shown earlier in this chapter.

    ;
    ; BIND data file for local loopback interface
    ;
    $TTL    604800
    @   IN  SOA localhost. root.localhost. (
                  1     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
    ;
    @   IN  NS      localhost.
    @   IN  A       127.0.0.1

The @ contains the name of the zone. It is called the current origin. A zone statement in named.conf defines that current origin, as is seen in this part of the named.conf file we saw earlier:

    zone "localhost" {
            type master;
            file "/etc/bind/db.local";
    };

So in this case the zone is called localhost and all current origins in the zone file will become localhost.

Other parts of a zone file will be explained in the section called “Zone files” below.

To each IP range in a zone file, there is a corresponding reverse zone that is described in a reverse zone file. Here is the file /etc/bind/db.127:

    ;
    ; BIND reverse data file for local loopback interface
    ;
    $TTL    604800
    @   IN  SOA localhost. root.localhost. (
                  1     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
    ;
    @       IN  NS      localhost.
    1.0.0   IN  PTR     localhost.

This is the calling part from named.conf:

    zone "127.in-addr.arpa" {
            type master;
            file "/etc/bind/db.127";
    };

As can be seen, the current origin will be 127.in-addr.arpa, so all @'s in the reverse zone file will be replaced by 127.in-addr.arpa.

But there is more: all host names that do not end in a dot get the current origin appended. This is important , so I repeat:

As an example: 1.0.0 will become 1.0.0.127.in-addr.arpa.

Normal IP addresses (e.g. 127.0.0.1) do not get the current origin appended.

Again, details about the reverse zone file will be discussed below.

The localhost and 127.in-addr.arpa zones are for internal use within a system.

In the outside world, zones are hierarchically organized. The root zone (denoted with a dot (.)) is listed in a special hints file. The following zone statement from named.conf reads a root zone file called /etc/bind/db.root

    zone "." {
        type hint;
        file "/etc/bind/db.root";
    };

By the way, note the type: hint! It is a special type for the root zone. Nothing else is stored in this file, and it is not updated dynamically.

Here is a part from the db.root file.

    ; formerly NS.INTERNIC.NET
    ;
    .                        3600000  IN  NS    A.ROOT-SERVERS.NET.
    A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
    ;
    ; formerly NS1.ISI.EDU
    ;
    .                        3600000      NS    B.ROOT-SERVERS.NET.
    B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107          

Note the dot at the left, this is the root zone!

Either your distribution or you personally must keep the root zone file current. You can look at ftp.rs.internic.net for a new version. Or, you could run something like

    dig @a.root-servers.net . ns > roothints

This will create a new file.

You can also run

    dig @a.root-servers.net . SOA

You can do this periodically to see if the SOA version number (see below) has changed.

The root zone knows about all top-level domains directly under it, e.g., the edu and org domains as well as the country-specific domains like uk and nl.

If the example.org domain (used here for illustration purposes) were a real domain, it would not be handled by the root name servers. Instead, the nameservers for the org domain would know all about it. This is called delegation: the root name servers have delegated authority for zones under org to the name servers for the org zone. Doing delegation yourself will be explained later in the section called “Delegating a DNS zone”.

A zone file is read from the named.conf file with a zone statement like

    zone "example.org" IN {
        type master;
        file "/etc/bind/exampleorg.zone";
    };

This is an example zone file for the zone example.org.

    $TTL 86400
    @      IN  SOA lion.example.org. dnsmaster.lion.example.org. (
               2001110700    ; Ser: yyyymmhhee (ee: ser/day start 00)
                    28800    ; Refresh
                     3600    ; Retry
                   604800    ; Expiration
                    86400 )  ; Negative caching
           IN  NS       lion.example.org.
           IN  NS       cat.example.org.

           IN  MX   0   lion.example.org.
           IN  MX  10   cat.example.org.

    lion   IN   A       224.123.240.1
           IN  MX   0   lion.example.org.
           IN  MX  10   cat.example.org.

    doggy  IN   A       224.123.240.2
    cat    IN   A       224.123.240.3

    ; our laptop
    bird   IN   A       224.123.240.4

Let's examine this file in detail.

    $TTL 3h

    $TTL 86400

    @  IN  SOA lion.example.org. dnsmaster.lion.example.org. (
           2001110700    ; Ser: yyyymmhhee (ee: ser/day start 00)
                28800    ; Refresh
                 3600    ; Retry
               604800    ; Expiration
                86400 )  ; Negative caching
          

    lion   IN   A       224.123.240.1

    cat   IN  A     224.123.240.3
    www   IN  CNAME cat.example.org.

    @    IN SOA .....

         IN  NS    lion.example.org.
         IN  NS    cat.example.org.

    lion   IN   A       224.123.240.1
           IN  MX   0   lion.example.org.
           IN  MX  10   cat.example.org.

    ; accept mail for the domain too
    example.org.  IN  MX   0   lion.example.org.
    example.org.  IN  MX  10   cat.example.org.

Each IP range has a reverse zone, that consists of part of the IP numbers in reverse order, plus in-addr.arpa. This system is used amongst others, to check if a hostname belongs to a specified address.

Our example.org domain uses the IP range 224.123.240.x. The corresponding reverse zone is called 240.123.224.in-addr.arpa. In named.conf this could be the corresponding entry:

    zone "240.123.224.in-addr.arpa" IN {
        type master;
        file "/etc/bind/exampleorg.rev";
    };

An example /etc/bind/exampleorg.rev (corresponding to the example.org domain we saw earlier) is:

    $TTL 86400
    @      IN  SOA lion.example.org. dnsmaster.lion.example.org. (
               2001110700    ; Ser: yyyymmhhee (ee: ser/day start 00)
                    28800    ; Refresh
                     3600    ; Retry
                   604800    ; Expiration
                    86400 )  ; Negative caching
           IN  NS       lion.example.org.
           IN  NS       cat.example.org.

    1      IN   PTR     lion.example.org.
    2      IN   PTR     doggy.example.org.
    3      IN   PTR     cat.example.org.
    4      IN   PTR     bird.example.org.

The current origin is 240.123.224.in-addr.arpa, so the entry for bird actually is

    4.240.123.224.in-addr.arpa IN PTR bird.example.org.

A zone definition is defined as master by using the

    type master;

statement inside a zone definition. See, for example, this zone statement (in named.conf)

    zone "example.org" IN {
        type master;
        file "/etc/bind/exampleorg.zone";
    };

defines the example.org master. Of course, The exampleorg.zone file must, of course, be created as discussed earlier.

There can be multiple independent master name servers for the same zone.

A notify statement controls whether or not the master sends DNS NOTIFY messages upon change of a master zone. The notify statement can be put in a zone statement as well as in an options statement. If one is present in both the zone and options statements, the former takes precedence. When a slave receives such a NOTIFY request (and supports it), it initiates a zone transfer to the master immediately to update the zone data. The default is notify yes;. To turn it off (when, e.g., a zone is served by masters only) set notify no;.

How does the master know which slave servers serve the same zone? It inspects the NS records defined for the zone. Extra slave servers can be specified with the also-notify statement (see the named.conf(5) manpage).

A zone definition is defined as slave by using the

type slave;

statement inside a zone definition, accompanied by the IP address(es) of the master(s). Here, for example, is the zone statement (in named.conf), which defines a example.org slave:

    zone "example.org" IN {
        type slave;
        masters { 224.123.240.1; }; // lion
        file "db.example.org";
    };

The file is created by the slave name server itself. The slave has no data for example.org. Instead, a slave receives its data from a master name server and stores it in the specified file.

Note that the filename has no directory component. Hence it will be written in the BIND working directory given by the directory option in named.conf. For instance, /var/cache/bind or /var/named. The name server must have write access to the file.

From the named.conf(5) manpage: A stub zone is like a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone.

A real, independent subdomain can be created by configuring the subdomain as an independent zone (having its own SOA and NS records) and delegating that domain from the parent domain.

A zone will only be authoritative if the parent zone has delegated its authority to the zone. For example, the example.org domain was delegated by the org domain.

Likewise, the example.org domain could delegate authority to an independent scripts.example.org domain. The latter will be independent of the former and have its own SOA and NS records.

Let's look at an example file of the scripts.example.org zone:

    $ORIGIN scripts.example.org.
    ctl  IN  A  224.123.240.16
         IN MX   0 ctl
         IN MX  10 lion.example.org.
    www  IN CNAME ctl
    perl IN  A  224.123.240.17
         IN MX   0 perl
         IN MX  10 ctl
         IN MX  20 lion.example.org.
    bash IN  A  224.123.240.18
         IN MX  0 bash
         IN MX  10 ctl
         IN MX  20 lion.example.org.
    sh   IN CNAME bash

Nothing new, just a complete zone file.

But, to get it authoritative, the parent domain, which is example.org in this case, must delegate its authority to the scripts.example.org zone. This is the way to delegate in the example.org zone file:

    scripts  2d IN NS ctl.scripts.example.org.
             2d IN NS bash.scripts.example.org.
    ctl.scripts.example.org.  2d IN  A 224.123.240.16
    bash.scripts.example.org. 2d IN  A 224.123.240.18

That's all!

The NS records for scripts do the actual delegation. The A records must be present, otherwise the name servers of scripts cannot be located.

The dig command lets you resolve names in a way that is close to the setup of a zone file. For instance, you can do

    dig bird.example.org A

This will do a lookup of the A record of bird.example.org. Part of the output looks like this:

    ;; ANSWER SECTION:
    bird.example.org. 1D IN A 224.123.240.4

    ;; AUTHORITY SECTION:
    example.org.      1D IN NS  lion.example.org.

    ;; ADDITIONAL SECTION:
    lion.example.org.  1D IN A 224.123.240.1

If dig shows a SOA record instead of the requested A record, then the domain is ok, but the requested host does not exist.

It is even possible to query another name server instead of the one(s) specified in /etc/resolv.conf:

    dig @cat.example.org bird.example.org A

This will query name server cat.example.org for the A record of host bird. The name server that was contacted for the query will be listed in the tail of the output.

The dig can be used to test or debug your reverse zone definitions. For instance,

    dig 4.240.123.224.in-addr.arpa PTR

will test the reverse entry for the lion host. You should expect something like this:

    ;; ANSWER SECTION:
    4.240.123.224.in-addr.arpa.  1D IN PTR lion.example.org.

    ;; AUTHORITY SECTION:
    240.123.224.in-addr.arpa.  1D IN NS  lion.example.org.

    ;; ADDITIONAL SECTION:
    lion.example.org.      1D IN A       224.123.240.4

If you get something like

    ;; ANSWER SECTION:
    4.240.123.224.in-addr.arpa. 1D IN PTR lion.example.org.240.123.224.in-addr.arpa.

you've made an error in your zone file. Given a current origin of 240.123.224.in-addr.arpa., consider the line:

    4  IN PTR lion.example.org ; WRONG!

The dot at the end was omitted, so the current origin is appended automatically. To correct this, add the trailing dot:

    4  IN PTR lion.example.org. ; RIGHT!

The host program reports resolver information in a simple format.

When a hostname is specified as a parameter, the corresponding A record will be shown.

    host bird.example.org

will result in output like

    bird.example.org    A    224.123.240.4

The host program is especially useful when a hostname is wanted and an IP address is given. For example:

    host 224.123.240.4

from our example hosts shows output like:

    Name: bird.example.org
    Address: 224.123.240.4

The following command is also possible:

    host 4.240.123.224.in-addr.arpa

resolves the PTR record:

    4.240.123.224.in-addr.arpa PTR bird.example.org

The nslookup program is yet another way to resolve names. However, its setup is quite different. It's a tool that can be used interactively and more request types can be handled than with dig or host.

For instance, start the interactive mode by entering nslookup and typing:

    ls -d example.org.

In result, the output will be shown in a zonefile-like format (beginning shown):

    [lion.example.org]
    $ORIGIN example.org.
    @    1D IN SOA lion postmaster.lion (
                    2001110800   ; serial
                            8H   ; refresh
                            1H   ; retry
                            1W   ; expiry
                            1D ) ; minimum

                        1D IN NS   lion
                        1D IN MX 0 lion

The first line, in square brackets, contains the name of the name server that sent the answer.

A lot of commands can be given to nslookup in interactive mode: the help command will present a list.