The Domain Name Service

Name server on a standalone system

If you only have a single machine connected to the network, and your own machine is part of the ISP's zone, you can use the resolv.conf method as well. This is a fairly typical situation if you're using a PPP or DSL link. It’s still not a good idea, however. Every lookup goes over the link, which is relatively slow. The results of the lookup aren't stored anywhere locally, so you can end up performing the same lookup again and again. DNS has an answer to the problem: save the information locally. You can do this with a caching-only name server. As the name suggests, the caching-only name server doesn't have any information of its own, but it stores the results of any queries it makes to other systems, so if a program makes the same request again—which happens frequently—it presents the results much more quickly on subsequent requests. Set up a caching-only name server like this:

• Either rename or remove /etc/resolv. conf, and create a new one with the following contents:

  name server 127.0.0.1    local name server
  
• Put this line in /etc/rc. conf:

  named enable=" YES "     # Run named, the DNS server (or NO). 
  

  If /etc/rc.conf doesn't exist, just create one with this content.
• Create a file /etc/namedb/localhost.rev containing:

  $TTL 1d
  @  IN SOA  @host@.root.@host@.   (
                         @date@  ; Serial
                         1h      ; Refresh
                         5m      ; Retry
                         100d    ; Expire
                         1h )    ; Negative cache
     IN NS   @host@.
  1  IN PTR  localhost.@domain@.
  

  We’ll look at the meaning of this file in the next section. To create it, you can start with the file /etc/namedb/PROTO.localhost.rev, which contains a template for this file. Replace @host@ with the FQDN of your host (freebie.example.org in this example), @date@ (the serial number) with the date in the form yyyymmddxx, where xx are a small integer such as 01,^{2 We’ll look at the serial number on page 368} and @domain@ with example.org. . Make sure that the FQDNs end with a trailing period. Alternatively, you can run the script /etc/namedb/make-localhost.
• Edit the file /etc/namedb/named. conf to contain:

  options {
    directory "/etc/namedb";
  
    forwarders {
      139.130.237.3;  139.130.237.17;
    };
  
  zone "0.0.127.in-addr.arpa" {
    type master;
    file "localhost.rev";
  };
  

  /etc/namedb/named. conf should already be present on your system as well. It contains a lot of comments, but at the end there's a similar zone definition, which you can edit if you want. The addresses 139.130.237.3 and 139.130.237.17. are the ISP's name server addresses. The forwarders line contains up to ten name server addresses.
• Start named:

  # ndc start
  

Name server on an end-user network

Of course, a simple caching-only name server won't work when you have your own domain. In fact, most of the authorities who allocate domain names won't even let you register an Internet domain unless you specify two functional name servers, and they'll check them before the registration can proceed. In this section, we'll look at what you need to do to run a "real " name server.

The first thing we need to do is to create a zone file for our zone example.org. We'll put it and all other zone files in a directory /etc/namedb and call it /etc/namedb/db.example.org after the name of the zone it describes.

The SOA record

The first thing we need is a record describing the Start of Authority. This defines a new zone. Write:

$TTL 1d
example.org.  IN SOA  freebie.example.org.grog.example.org. (
                      2003031801 ; Serial (date, 2 digits version of day)
                      1d   ; refresh
                      2h   ; retry
                      100d ; expire
                      1h ) ; negative cache expiry

The first line, $TTL 1d, is relatively new. It's not strictly part of the SOA record, but it's now required to fully define the SOA. It specifies the length of time that remote name servers should cache records from this zone. During this time they will not attempt another lookup. In older versions of BIND, this value was stored in the last field of the SOA record below.

The remaining lines define a single SOA record. The name on the left is the name of the zone. The keyword IN means Internet, in other words the Internet Protocols. The BIND software includes support for multiple network types, most of which have now been forgotten. The keyword SOA defines the type of record. freebie.example.org is the master name server.

The next field, grog.example.org, Is the mail address of the DNS administrator. "Wait a minute," you may say "that's not a mail address. There should be an @ there, not a . . " That's right, but unfortunately DNS uses the @ sign for other purposes, and it would be a syntax error in this position. So the implementers resorted to this kludge. To generate the mail ID, replace the first . with an @, to give yougrog@example.org.

The serial number identifies this version of the zone configuration. Remote name servers first retrieve the SOA record and check if the serial number has incremented before deciding whether to access the rest of the zone, which could be large. Make sure you increment this field every time you edit the file. If you don't, your updates will not propagate to other name servers. It's a good idea to use a format that refects the date, as here: the format gives four digits for the year, two digits for the month, two for the day, and two for the number of the modification on a particular day. The serial number in this

example shows it to be the second modification to the zone configuration on 18 March 2003.

The remaining parameters describe the timeout characteristics of the zone. Use the values in the example unless you have a good reason to change them. The data formats for the records require all times to be specified in seconds, and in previous versions of BIND, this was the only choice you had. In current versions of BIND, you can use scale factors like d for day and h for hours in the configuration file. named converts them to seconds before transmission.

• The refresh time is the time after which a remote name server will check whether the zone configuration has changed. 1day is reasonable here unless you change your configuration several times per day.
• The retry time is the time to wait if an attempt to load the zone fails.
• The expire time is the time after which a slave name server will drop the information about a zone if it has not been able to reload it from the master name server. You probably want to make this large.
• In previous versions of BIND, the last field was the minimum time to live. Now the $TTL parameter sets that value, and the last parameter specifies the negative caching time. If an authoritative name server (one that maintains the zone) reports that a record doesn't exist, it returns an SOA record as well to indicate that it's authoritative. The local name server maintains this information for the period of time specified by this field of the returned SOA record and it doesn't retry the query until the time has expired. The only way things can change here is if the remote host master changes the DNS configuration, so unreasonable to keep the negative cache time to about an hour.