The Domain Name Service

The A records

The most obvious requirement are the IP addresses of the systems on the network. In the zone example.org, define the A records like this:

localhost  IN A  127.0.0.1     local machine, via loopback interface
freebie    IN A  223.147.37.1 
presto     IN A  223.147.37.2
bumble     IN A  223.147.37.3
wait       IN A  223.147.37.4
gw         IN A  223.147.37.5

In practice, as we will see in the completed configuration file, we tend to put the A records further towards the end of the list, because they are usually the most numerous. It makes the file easier to read if we put them after the shorter groups of entries.

The NS records

DNS uses a special kind of record to tell where your name servers are. In our case, we're running name servers on freebie and presto. We could write:

IN NS  freebie.example.org.
IN NS  presto.example.org. 

This would work just fine, but in fact we'll do it a little differently, as we'll see in the next section.

Nicknames

We're running a whole lot of services on the reference network, in particular a web server and an ftp server. By convention, a web server machine is called www, an ftp server is called ftp, and a name server is called ns. But they're both running on machines with different names. What do we do? We give our machines nicknames:

www  IN CNAME  freebie
ftp  IN CNAME  presto

We'd like to do the same with the name servers, but unfortunately DNS doesn't like that, and will complain about your DNS configuration all over the world if you make ns a CNAME. There's a good reason for this: if you use CNAME records to define your name servers, remote systems have toper form two lookups to find the address of the name server, one to retrieve the CNAME and one to get the corresponding A record for the CNAME. Define new Are cords for them:

     IN NS  ns
     IN NS  ns1

ns   IN A   223.147.37.1
ns1  IN A   223.147.37.2

You'll note that we're using relative domain names in these examples. They are taken to be relative to the name that starts the SOA record.

The MX records

As we will see on page 493, you could send mail to hosts listed in an A record, but it's not a good idea. Instead, you should have at least two MX records to tell SMTP what to do with mail for your domain. This method has an added advantage: it allows you to rename individual machines without having to change the users' mail IDs. We'll take this advice and assume that all mail is sent to user@example.org. In addition, we'll use the ISP's mail server mail.example.net as a backup in case our mail server is down. That way, when it comes back up, the delivery will be expedited. The resulting MX records look like:

IN MX  50   bumble.example.org. 
IN MX  100  mail.example.net

The numbers 50 and 100 are called preferences. Theoretically you could make them 1 and 2, except that you might want to put others in between. A mail transfer agent sends mail to the system with the lowest preference unless it does not respond—then it tries the MX record with the next-lowest preference, and so on.

The HINFO records

Finally, you may want to tell the world about your hardware and this great operating system you're running. You can do that with the HINFO record:

freebie  IN HINFO  "Pentium/133"      "FreeBSD 4. 0-CURRENT (4. 4BSD)"
presto   IN HINFO  "Pentium II /233"  "FreeBSD 3. 2 (4. 4BSD)"
bumble   IN HINFO  "Pentium/133"      "SCO Open Server"
wait     IN HINFO  "Pentium Pro 266"  "Microsoft Windows 95%"
gw       IN HINFO  "486/33"           "FreeBSD 3. 2 (4. 4BSD)"

Of course, telling the world the truth about your hardware also helps crackers choose the tools to use if they want to break into your system. If this worries you, don't use HINFO. It's still the exception to see HINFO records.

Putting it all together

In summary, our configuration file /etc/namedb/db.example.org looks like:

; Definition of zone example.org
$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

; name servers
              IN NS   ns
              IN NS   ns1

; MX records
              IN MX   50   bumble.example.org.
              IN MX   100  mail.example.net.

ns            IN A    223.147.37.1
ns1           IN A    223.147.37.2

; Hosts
localhost     IN A    127.0.0.1
freebie       IN A    223.147.37.1
presto        IN A    223.147.37.2
bumble        IN A    223.147.37.3
wait          IN A    223.147.37.4
gw            IN A    223.147.37.5

; nicknames
www           IN CNAME  freebie
ftp           IN CNAME  presto

; System information
freebie       IN HINFO  "Pentium/133"      "FreeBSD 4.0-CURRENT (4.4BSD)"
presto        IN HINFO  "Pentium II/233"   "FreeBSD 3.2 (4.4BSD)"
bumble        IN HINFO  "Pentium/133"      "SCO OpenServer"
wait          IN HINFO  "Pentium Pro 266"  "Microsoft Windows 95%"
gw            IN HINFO  "486/33"           "FreeBSD 3.2 (4.4BSD)"

You'll notice that comment lines start with ;, and not with the more usual #. Also, we have rearranged the MX records and the A records for the name servers. If we placed the MX records below the A records for the name servers, they would refer to ns1. example. org.

That's all the information we need for our zone example. org. But we're not done yet we need another zone. Read on.

Reverse lookup

It's not immediately apparent that you might want to perform reverse lookup, to find the name associated with a specific IP address. In fact, it’s used quite a bit, mainly to confirm that a system is really who it says it is. Many mail servers, including Free5SD.org, insist on valid reverse lookup before accepting mail. We’ll look at that in more detail in "Chapter 27" , on page 501. It's not difficult, but many systems, particularly those using Microsoft, don't have their reverse lookup set up correctly.

/etc/hosts is a file, so you can perform lookup in either direction. Not so with DNS: how can you know which name server is authoritative for the domain if you don't know its name? You can't, of course, so DNS uses a trick: it fabricates a name from the address. For the address 223.147.37.4, it creates a domain name 37.147.223. in-addr.arpa. The digits of the address are reversed, and the last digit is missing: it’s the host part of the address. It asks the name server for this domain to resolve the name 4.37.147.223.in-addr.arpa.

To resolve the names, we need another zone. That means another file, which we'll call /etc/namedb/example-reverse. It's not quite as complicated as the forward file:

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

1  IN PTR  freebie.example.org. 
2  IN PTR  presto.example.org. 
3  IN PTR  bumble.example.org. 
4  IN PTR  wait.example.org. 
5  IN PTR  gw.example.org. 

In this case, the SOA record is identical to that in /etc/namedb/db. example. org, with two exceptions: instead of the zone name at the beginning of the line, we have the @ symbol, and the serial number is different—you don't normally need to update reverse lookup domains so often. This @ symbol represents the name of the zone, in this case 37.147.223.in-addr arpa. We'll see how that works when we make the /etc/named/named.root file below. We also use the same name server entries. This time they need to be fully qualified, because they are in a different zone.

Finally, we have the PTR (reverse lookup) records. They specify only the last digit (the host part) of the IP address, so this will be prepended to the zone name. The host name at the end of the line is in fully qualified form, because it's in another zone. For example, in fully qualified form, the entry for wait could be written:

4.37.147.223.in-addr. arpa.  IN PTR  wait.example.org.

The distant view: the outside world

So far, we have gone to a lot of trouble to describe our own tiny part of the Internet. What about the rest? How can the name server find the address of, say, freefall.Free-BSD.org? So far, it can’t.

What we need now is some information about other name servers who can help us, specifically the 13 root name servers. These are named A.ROOT-SERVERS.NET. through M.ROOT-SERVERS.NET.. They are described in a file that you can get from ftp://ftp.rs.internic.net/domain/named.root if necessary, but you shouldn’t need to: after installing FreeBSD, it should be present in /etc/namedb/named.root. This file has hardly changed in years—the names have changed once, but most of the addresses have stayed the same. Of course, it’s always a good idea to check from time to time.