/etc/resolv.conf specifies the addresses of preferred nameservers and a list of domains relative to which unqualified names are resolved. You specify a nameserver with a line of the form nameserver 1.2.3.4 (where 1.2.3.4 is the address of the nameserver). You can use multiple nameserver lines (usually up to three). You can use a search line to specify a list of domains to search for unqualified names.
A search line such as search example.com example.net causes the resolver to attempt to resolve the unqualified name xyz, first as xyz.example.com, and then, if that fails, as xyz.example.net. Do not use too many domains in the search list because it slows down resolution.
A hosts: files dns line in /etc/nsswitch.conf causes the resolver to consult /etc/hosts before using the DNS during the course of a name lookup. This allows you to override the DNS by making temporary changes to /etc/hosts, which is especially useful during network testing. (Older resolvers might require an order hosts, bind line in the /etc/host.conf file instead.)
Running the named Nameserver Daemon
Finally! You can now start named with /etc/rc.d/init.d/named start. You should see messages similar to the ones that follow in the syslog (or another location, according to the logging configuration you have set up). One way to do this is to monitor the log file with the tail command; that scrolls the changes in the file down the screen:
# tail -f /var/log/messages
----------
July 9 23:48:33 titan named[2605]: starting BIND 9.2.3 -u named
July 9 23:48:33 titan named[2605]: using 1 CPU
July 9 23:48:33 titan named[2608]: loading configuration from '/etc/named.conf'
July 9 23:48:33 titan named[2608]: no IPv6 interfaces found
July 9 23:48:33 titan named[2608]: listening on IPv4 interface lo, 127.0.0.1#53
July 9 23:48:33 titan named: named startup succeeded
July 9 23:48:33 titan named[2608]: listening on IPv4 interface\
eth0, 192.168.2.68#53
July 9 23:48:33 titan named[2608]: command channel listening on 127.0.0.1#953
October 9 23:48:33 titan named[2608]: zone 0.0.127.in-addr.arpa/IN: \
loaded serial 1997022700
October 9 23:48:33 titan named[2608]: zone localhost/IN: loaded serial 42
October 9 23:48:33 titan named[2608]: running
----------
You can use rndc to interact with this instance of named. Running rndc without arguments displays a list of available commands, including ones to reload or refresh zones, dump statistics and the database to disk, toggle query logging, and stop the server. Unfortunately, rndc does not yet implement all the commands that were supported by ndc — the control program shipped with earlier versions of BIND.
You should now be able to resolve 1.0.0.127.in-addr.arpa locally (try dig @localhost 1.0.0.127.in-addr.arpa PTR +norec) and other names via recursive resolution. If you cannot accomplish this resolution, something is wrong, and you should read the "Troubleshooting DNS" section later in this chapter to diagnose and correct your problem before proceeding further. Remember to read the logs!
Providing DNS for a Real Domain
You can expand the minimal nameserver configuration you just created into one that performs useful name service for a real domain. Suppose that your ISP has assigned to you the IP addresses in the 192.0.2.0/29 range (which has six usable addresses: 192.0.2.1-6) and that you want to serve authoritative data for the domain example.com. A friend has agreed to configure her nameserver (192.0.2.96) to be a slave for the domain, as well as a backup mail server. In return, she wants the foo.example.com subdomain delegated to her own nameservers.
Forward Zone
First, you must introduce the zone to named.conf:
----------
| zone "example.com" {
| type master;
| file "example.com";
| };
----------
and create the zone file:
----------
| $TTL 2D
| @ SOA ns1.example.com. hostmaster.example.com. (
| 2001090101 ; Serial
| 24h ; Refresh
| 2h ; Retry
| 3600000 ; Expire (1000h)
| 1h) ; Minimum TTL
| NS ns1.example.com.
| NS ns2.example.com.
| MX 5 mx1.example.com.
| MX 10 mx2.example.com.
| A 192.0.2.1
|
| ; Addresses
| ns1 A 192.0.2.1 ; Nameservers
| ns2 A 192.0.2.96
| mx1 A 192.0.2.2 ; Mail servers
| mx2 A 192.0.2.96
| www A 192.0.2.3 ; Web servers
| dev A 192.0.2.4
| work A 192.0.2.5 ; Workstations
| play A 192.0.2.6
|
| ; Delegations
| foo NS dns1.foo.example.com.
| foo NS dns2.foo.example.com.
| dns1.foo A 192.0.2.96
| dns2.foo A 192.0.2.1
----------
The SOA record is similar to the one you saw before. Note that the next five records use the implicit name @, which is short for example.com.
The two NS records define ns1.example.com (your own server, 192.0.2.1) and ns2.example.com (your friend's server, 192.0.2.96) as authoritative nameservers for example.com.
The MX (Mail Exchanger) records specify a mail server for the zone. An MX RR takes two arguments: a priority number and the name of a host. In delivering mail addressed to example.com, the listed MXes are tried in increasing order of priority. In this case, mx1.example.com (your own machine, 192.0.2.2) has the lowest priority and is always tried first. If the attempt to deliver mail to mx1 fails for some reason, the next listed MX, mx2.example.com (your friend's server), is tried.
The A record says that the address of example.com is 192.0.2.1, and the next few lines specify addresses for other hosts in the zone: your nameservers ns1 and ns2, mail servers mx1 and mx2, two web servers, and two workstations.
Next you add NS records to delegate authority over the foo.example.com domain to dns1 and dns2.foo.example.com. The A records for dns1 and dns2 are known as glue records, and they enable resolvers to find the address of the authoritative nameservers so that they can continue the query. (If you were using dig, the NS records for dns1 and dns2 would be listed in the AUTHORITY section of the response, whereas the ADDITIONAL section would contain their addresses.)