The Domain Name Service

Ever since the beginning of the ARPAnet, systems have had both names and IP addresses. UNIX systems, as well as many others who have copied the BSD IP implementation, used the file /etc/hosts to convert between names and addresses. This file contains a list of IP addresses and the corresponding host names, one per line.

It's clearly impossible to have an /etc/hosts file that describes the complete Internet. Even if you had disk space, the number of updates would overload your network. The solution is a distributed database, the Domain Name System, or DNS. The most common implementation of DNS is BIND, the Berkeley lnternet Name Domain^{1Does this sound like an acronym in search of a name?}. You'll notice the word Berkeley in there. BIND is part of BSD, and it's about the only game in town. Despite these names, the daemon that performs the resolution is called named (the name daemon, pronounced "name-dee").

DNS provides the information needed to connect to remote systems in the form of Resource Records, or RRs. Unfortunately, the names of the records aren't overly intuitive.

• A (Address) records translate host names to IP addresses. For example, one A record tells you that www.FreeBSD.org (currently) has the IP address 216.136.204.117. These are what most people think of when they hear the name DNS. The name specified in the A record is called the canonical name of the interface, and it should be the one to which the PTR record (see below) refers.
• PTR (Pointer) records provide a translation from IP address to name. This process is also called reverse lookup.
• MX (Mail Exchange) records specify the IP addresses of mail servers for a domain.
• SOA (Start Of Authority) records define zones, which roughly correspond to domains. We'll look at the distinction between zones and domains below.
• NS (Name Server) records describe name servers for a zone.
• HINFO (Hardware Information) records describe the hardware and software that runs on a particular system.
• CNAME (Canonical Name) records describe alternative names for a system.

FreeBSD allows you to use both /etc/hosts and DNS. One reason for this might be to have name resolution of local hosts at startup time: there's a chicken-and-egg problem with mounting NFS file systems before named is running.

The common objections to using DNS include:

• It's supposedly difficult to set up DNS configuration files.
• DNS supposedly generates a lot of network traffic.
• DNS supposedly causes a dial-on-demand system to dial all the time.

These statements are all untrue. We'll look at them in the rest of this chapter as we set up DNS for our reference network.

Domains and zones

In Internet parlance, a domain is a group of names ending with a specific domain name. We looked at domain names in "Chapter 18" , Connecting to the Internet, page 318. Note that, like file names, there are two kinds of domain names:

• A fully qualified domain name (FQDN) ends in a period (.). This domain name relates to the root domain . (a single period).
• A relative domain name relates to the current domain. You'll see them occasionally in the configuration files.

Most times, when you write a domain name, you intend it to be fully qualified. But if you write it without the terminating period, DNS will frequently append your own domain name. For example, if you specify a name like freebie.example.org, DNS won't find a fully qualified name: it's a misspelling of freebie.example.org. As result, it will look for the name freebie.example.org. example.org. It won't find it, of course, but it may spend a long time trying. The moral is simple: when writing DNS configuration files, always put a period (full stop) at the end of names that are fully qualified.

Zones

In many ways, a zone is the same thing as a domain: it’s the subset of the DNS name space that is maintained by a specific set of name servers—n DNS-speak, name servers are authoritative for the zone. The difference is mainly in the way it’s used. There is one exception, however: usually, a sub domain will have a different name server. This sub domain is part of the domain, but not of the zone.

For example, in our reference network, the name servers on freebie and presto are authoritative for example.org. The owner of the domain might give permission for somebody, maybe in a different country, to run a sub domain china.example.org, with name servers beijing.china.example.org and xianggang.china.example.org. Because there are different name servers, there are two zones: freebie.example.org would be authoritative for the zone example.org, but not for china.example.org.beijing.china.example.org and xianggang.china.example.org would be authoritative for the zone china.example.org, but not for example.org.

Setting up a name server

DNS service is supplied by the name daemon, called named. named can be run in a number of different modes. In this chapter, we'll concentrate on setting the appropriate configurations for our reference network. If you want to go further, check the following documents:

• The BIND Online Documentation, in the source distribution in the directory
• /usr/src/contrib/bind/doc/html/index.html.
• TCP/IP Network Administration, by Craig Hunt (O'Reilly).
• DNS and BIND, by Paul Albitz and Cricket Liu (O'Reilly).

In the last few years, BIND has undergone some significant changes, mainly as a result of abuse on the net. The current release is Version 9, but FreeBSD still ships with Version 8. The differences are relatively minor: Version 9 introduces a number of new features, but the contents of this chapter should also apply to Version 9. The previous version was Version 4, and you'll still find a lot of old documentation referring to it. There were no Versions 5, 6 or 7, and the main configuration file changed its format completely in Version 8; even the name changed. We’ll look at how to convert the formats on page 380. Before using the documentation above, make sure that it refers to the correct version of

BIND.

Passive DNS usage

Not every system needs to run its own name daemon. If you have another machine on the same network, you can send requests to it. For example, in the reference network, freebie and presto may be running name servers. There's no particular reason for bumble and wait, both presumably slower machines, to do so as well. Instead, you can tell them to use the name servers on the other two machines.

To do this, make sure that you don't enable named in your /etc/rc. conf, and create a file /etc/resolv.conf with the following contents:

domain example.org
nameserver 223.147.37.1     #freebie
nameserver 223.147.37.2     #presto

Specify the IP addresses, not the names, of the name servers here. This is a classic chicken-and-egg problem: you can’t access the name server to get its address until you know its address.

With this file in place, this machine will send all name server requests to freebie or presto. We’ll look at how to configure them later.