Purchase | Copyright © 2002 Paul Sheer. Click here for copying permissions. | Home |
In Chapter 27 we dealt with the ``client'' side of DNS. In this chapter we configure the name server that services such requests.
There seems to be a lot of hype that elevates the name server to something mystical and illusive. In fact, setting up a name server is a standard and trivial exercise. A name server daemon is also no heavyweight service: The named executable is 500 KB and consumes little CPU.
The package that the name server comes in is called bind. This chapter assumes a bind of approximately bind-8.2 or later. bind stands for Berkeley Internet Name Domain.
The difficulty with setting up a name server is that the configuration files are impossible to construct from the specification without some kind of typing error being made. The solution is quite simple: Never create a name server config file from scratch. Always copy one from an existing working name server. Here we give more example configuration files than explanation. You can copy these examples to create your own name server.
Please note before running bind that it has security vulnerabilities. Hence, it may be possible for someone to hack your machine if you are running an old version. Many people are also skeptical about even the latest versions of bind (9.1 at the time of writing) even though no security holes had been announced for this version. An alternative is djbdns, which is purported to be the ultimate DNS server.
Before you even start working on name server configuration, you should start a new terminal window with the command (Debian alternative in parentheses):
|
tail -f /var/log/messages ( tail -f /var/log/syslog ) |
Keep this window throughout the entire setup and testing procedure. From now on, when I refer to messages, I am referring to a message in this window.
The man pages for named are hostname(7), named-xfer(8), named(8), and ndc(8). These pages reference a document called the ``Name Server Operations Guide for BIND.'' What they actually mean is the PostScript file /usr/[share/]doc/bind-<version>/bog/file.psf (or /usr/share/doc/bind/bog.ps).
The problem with some of this documentation is that it is still based on the old (now deprecated) named.boot configuration file. There is a script /usr/doc/bind-<version>/named-bootconf/named-bootconf (or /usr/sbin/named-bootconf) that reads a named.boot file from stdin and writes a named.conf file to stdout. I found it useful to echo "old config line" | named-bootconf to see what a new style equivalent would be.
The directory /usr/[share/]doc/bind[-<version>]/html/contains the most important general information. It is a complete reference to bind configuration. Parallel directories also contain FAQ documents and various theses on security. A file style.txt contains the recommended layout of the configuration files for consistent spacing and readability. Finally an rfc/ directory contains the relevant RFCs (see Section 13.6).
There is only one main configuration file for named: /etc/named.conf (or /etc/bind/named.conf on Debian--here we assume a /etc/named.conf file for simplicity). The named service once used a file /etc/named.boot, but this has been scrapped. If there is a named.boot file in your /etc directory, then it is not being used, except possibly by a very old version of bind.
Here we will show example configurations necessary for typical scenarios of a name server.
The named.conf file will have in it the line directory "/var/named"; (or directory "/etc/named"; or directory "/var/cache/bind";). This directory holds various files containing textual lists of the name to IP address mappings that bind will serve. The following example is a name server for a company that has been given a range of IP addresses 196.28.144.16/29 (i.e., 196.28.144.16- 23), as well as one single IP address ( 160.123.181.44). This example also must support a range of internal IP addresses ( 192.168.2.0- 255) The trick is not to think about how everything works. If you just copy and edit things in a consistent fashion, carefully reading the comments, bind will work fine. I will now list all necessary files.
|
domain localdomain nameserver 127.0.0.1 |
5 10 15 20 25 30 35 40 45 50 55 |
/* * The ``directory'' line tells named that any further file name's * given are under the /var/named/ directory. */ options { directory "/var/named"; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; }; /* The list of root servers: */ zone "." { type hint; file "named.ca"; }; /* Forward lookups of the localhost: */ zone "localdomain" { type master; file "named.localdomain"; }; /* Reverse lookups of the localhost: */ zone "1.0.0.127.in-addr.arpa" { type master; file "named.127.0.0.1"; }; /* Forward lookups of hosts in my domain: */ zone "cranzgot.co.za" { type master; file "named.cranzgot.co.za"; }; /* Reverse lookups of local IP numbers: */ zone "2.168.192.in-addr.arpa" { type master; file "named.192.168.2"; }; /* Reverse lookups of 196.28.144.* Internet IP numbers: */ zone "144.28.196.in-addr.arpa" { type master; file "named.196.28.144"; }; /* Reverse lookup of 160.123.181.44 only: */ zone "44.181.123.160.in-addr.arpa" { type master; file "named.160.123.181.44"; }; |
5 10 15 20 25 |
; Get the original of this file from ftp://ftp.rs.internic.net/domain/named.root ; ; formerly ns.internic.net . 3600000 IN NS a.root-servers.net. a.root-servers.net. 3600000 A 198.41.0.4 . 3600000 NS b.root-servers.net. b.root-servers.net. 3600000 A 128.9.0.107 . 3600000 NS c.root-servers.net. c.root-servers.net. 3600000 A 192.33.4.12 . 3600000 NS d.root-servers.net. d.root-servers.net. 3600000 A 128.8.10.90 . 3600000 NS e.root-servers.net. e.root-servers.net. 3600000 A 192.203.230.10 . 3600000 NS f.root-servers.net. f.root-servers.net. 3600000 A 192.5.5.241 . 3600000 NS g.root-servers.net. g.root-servers.net. 3600000 A 192.112.36.4 . 3600000 NS h.root-servers.net. h.root-servers.net. 3600000 A 128.63.2.53 . 3600000 NS i.root-servers.net. i.root-servers.net. 3600000 A 192.36.148.17 . 3600000 NS j.root-servers.net. j.root-servers.net. 3600000 A 198.41.0.10 . 3600000 NS k.root-servers.net. k.root-servers.net. 3600000 A 193.0.14.129 . 3600000 NS l.root-servers.net. l.root-servers.net. 3600000 A 198.32.64.12 . 3600000 NS m.root-servers.net. m.root-servers.net. 3600000 A 202.12.27.33 |
5 10 |
$TTL 259200 @ IN SOA localhost.localdomain. dns-admin.localhost.localdomain. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS localhost.localdomain. localhost IN A 127.0.0.1 |
5 10 |
$TTL 259200 @ IN SOA localhost. dns-admin.localhost. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS localhost. IN PTR localhost. |
5 10 15 20 25 30 35 40 45 |
$TTL 259200 @ IN SOA ns1.cranzgot.co.za. dns-admin.ns1.cranzgot.co.za. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS ns1.cranzgot.co.za. IN NS ns2.cranzgot.co.za. IN A 160.123.181.44 IN MX 10 mail1.cranzgot.co.za. IN MX 20 mail2.cranzgot.co.za. ; We will use the first IP address for the name server itself: ns1 IN A 196.28.144.16 ; our backup name server is faaar away: ns2 IN A 146.143.21.88 ; FTP server: ftp IN A 196.28.144.17 ; Aliases: www IN CNAME cranzgot.co.za. mail1 IN CNAME ns1.cranzgot.co.za. mail2 IN CNAME ns2.cranzgot.co.za. gopher IN CNAME ftp.cranzgot.co.za. pop IN CNAME mail1.cranzgot.co.za. proxy IN CNAME ftp.cranzgot.co.za. ; Reserved for future web servers: unused18 IN A 196.28.144.18 unused19 IN A 196.28.144.19 unused20 IN A 196.28.144.20 unused21 IN A 196.28.144.21 unused22 IN A 196.28.144.22 unused23 IN A 196.28.144.23 ; local LAN: pc1 IN A 192.168.2.1 pc2 IN A 192.168.2.2 pc3 IN A 192.168.2.3 pc4 IN A 192.168.2.4 ; and so on... to 192.168.2.255 |
5 10 15 |
$TTL 259200 @ IN SOA ns1.cranzgot.co.za. dns-admin.ns1.cranzgot.co.za. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS ns1.cranzgot.co.za. 1 IN PTR pc1.cranzgot.co.za. 2 IN PTR pc2.cranzgot.co.za. 3 IN PTR pc3.cranzgot.co.za. 4 IN PTR pc4.cranzgot.co.za. ; and so on... to 255 |
5 10 15 20 25 30 35 40 |
$TTL 259200 @ IN SOA ns1.cranzgot.co.za. dns-admin.ns1.cranzgot.co.za. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS dns.big-isp.net. 0 IN NS dns.big-isp.net. 1 IN NS dns.big-isp.net. 2 IN NS dns.big-isp.net. 3 IN NS dns.big-isp.net. 4 IN NS dns.big-isp.net. 5 IN NS dns.big-isp.net. 6 IN NS dns.big-isp.net. 7 IN NS dns.big-isp.net. 8 IN NS dns.big-isp.net. 9 IN NS dns.big-isp.net. 10 IN NS dns.big-isp.net. 11 IN NS dns.big-isp.net. 12 IN NS dns.big-isp.net. 13 IN NS dns.big-isp.net. 14 IN NS dns.big-isp.net. 15 IN NS dns.big-isp.net. 16 IN PTR ns1.cranzgot.co.za. 17 IN PTR ftp.cranzgot.co.za. 18 IN PTR unused18.cranzgot.co.za. 19 IN PTR unused19.cranzgot.co.za. 20 IN PTR unused20.cranzgot.co.za. 21 IN PTR unused21.cranzgot.co.za. 22 IN PTR unused22.cranzgot.co.za. 23 IN PTR unused23.cranzgot.co.za. 24 IN NS dns.big-isp.net. 25 IN NS dns.big-isp.net. 26 IN NS dns.big-isp.net. ; and so on... up to 255 |
5 10 |
$TTL 259200 @ IN SOA ns1.cranzgot.co.za. dns-admin.ns1.cranzgot.co.za. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS ns1.cranzgot.co.za. IN NS ns2.cranzgot.co.za. IN PTR cranzgot.co.za. |
If you have created a configuration similar to that above, you can then run the bind package initialization commands. The actions available are (alternative commands in parentheses):
5 |
/etc/rc.d/init.d/named start ( /etc/init.d/named start ) ( /etc/init.d/bind start ) /etc/rc.d/init.d/named stop /etc/rc.d/init.d/named restart /etc/rc.d/init.d/named status |
You should get messages like:
5 10 15 |
Jul 8 15:45:23 ns1 named[17656]: starting. named 8.2.2-P5 Sat Aug 5 13:21:24 EDT 2000 ^I Jul 8 15:45:23 ns1 named[17656]: hint zone "" (IN) loaded (serial 0) Jul 8 15:45:23 ns1 named[17656]: master zone "localhost" (IN) loaded (serial 2000012101) Jul 8 15:45:23 ns1 named[17656]: master zone "1.0.0.127.in-addr.arpa" (IN) loaded (serial Jul 8 15:45:23 ns1 named[17656]: master zone "cranzgot.co.za" (IN) loaded (serial 20000121 Jul 8 15:45:23 ns1 named[17656]: master zone "myisp.co.za" (IN) loaded (serial 2000012101) Jul 8 15:45:23 ns1 named[17656]: master zone "2.168.192.in-addr.arpa" (IN) loaded (serial Jul 8 15:45:23 ns1 named[17656]: master zone "144.28.196.in-addr.arpa" (IN) loaded (serial Jul 8 15:45:23 ns1 named[17656]: master zone "44.181.123.160.in-addr.arpa" (IN) loaded (se Jul 8 15:45:23 ns1 named[17656]: listening on [127.0.0.1].53 (lo) Jul 8 15:45:23 ns1 named[17656]: listening on [196.28.144.16].53 (eth0) Jul 8 15:45:23 ns1 named[17656]: Forwarding source address is [0.0.0.0].1041 Jul 8 15:45:23 ns1 named: named startup succeeded Jul 8 15:45:23 ns1 named[17657]: group = 25 Jul 8 15:45:23 ns1 named[17657]: user = named Jul 8 15:45:23 ns1 named[17657]: Ready to answer queries. |
If you have made typing errors, or named files incorrectly, you will get appropriate error messages. Novice administrators are wont to edit named configuration files and restart named without checking /var/log/messages (or /var/log/syslog) for errors. NEVER do this.
If there are no apparent errors in your config files, you can now more closely examine the contents of the files.
The top-level configuration file /etc/named.conf has an obvious C style format. Comments are designated by /* */ or //.
The options section in our case specifies only one parameter: the directory for locating any files. The file options.html under the bind documentation directories has a complete list of options. Some of these are esoteric, but a few have common uses.
The lines zone "." {... will be present in all name server configurations. They tell named that the whole Internet is governed by the file named.ca. named.ca in turn contains the list of root name servers.
The lines zone "localdomain" {... are common. They specify that forward lookups for host .localdomain are contained in the file /var/named/named.localdomain. This file gives a correct result for any lookup for localhost. Many applications query the name server for this name and a fastidious configuration ought to return it correctly. Note that such a lookup works together with resolv.conf--it has a line search localdomain so that a query for localhost gives the same result as a query for localhost.localdomain.
The lines zone "1.0.0.127.in-addr.arpa" {... resolve reverse lookups for the IP address 127.0.0.1 (stored in the file named.127.0.0.1). Note that 1.0.0.127 is 127.0.0.1 written backwards. In fact, reverse lookups are just forward lookups under the domain .in-addr.arpa. Many applications reverse lookup any received connection to check its authenticity, even from localhost, so you may want to have these lines present to prevent such applications failing or blocking.
The rest of the file is the configuration specific to our domain.
The lines zone "cranzgot.co.za" {... say that information for forward lookups is located in the file named.cranzgot.co.za.
The lines zone "1.168.192.in-addr.arpa" {... say that information for reverse lookups on the IP address range 192.168.1.0- 255 is located in the file named.192.168.1.
The lines zone "44.182.124.160.in-addr.arpa" {... says that information for reverse lookups on the IP address 160.124.182.44 is located in the file named.160.124.182.44.
Each of the other named. files has a similar format. They begin with $TTL line and then an @ IN SOA. TTL stands for Time To Live, the default expiration time for all subsequent entries. This line not only prevents a No default TTL set... warning message, but really tells the rest of the Internet how long to cache an entry. If you plan on moving your site soon or often, set this to a smaller value. SOA stands for Start of Authority. The host name on the second line specifies the authority for that domain, and the adjacent <user>.<hostname> specifies the email address of the responsible person.
The next few lines contain timeout specifications for cached data and data propagation across the net. These are reasonable defaults, but if you would like to tune these values, consult the relevant documentation listed on page . The values are all in seconds.
The serial number for the file (i.e., 2000012101) is used to tell when a change has been made and hence that new data should be propagated to other servers. When updating the file in any way, you must increment this serial number. The format is conventionally YYYYMMDDxx--exactly ten digits. xx begins with, say, 01 and is incremented with each change made during a day.
It is absolutely essential that the serial number be updated whenever a file is edited. If not, the changes will not be reflected through the rest of the Internet.
If a host name ends in a . then the dot signifies a fully qualified host name. If it does not end in a . then the absence of a dot signifies that the domain should be appended to the host name. This feature is purely to make files more elegant.
For instance, the line
|
ftp IN A 196.28.144.17 |
could just as well be written
|
ftp.cranzgot.co.za. IN A 196.28.144.17 |
Always be careful to properly end qualified host names with a dot, since failing to do so causes named to append a further domain.
If a host name is omitted from the start of the line, then the domain is substituted. The purpose of this notation is also for elegance. For example,
|
IN NS ns1.cranzgot.co.za. |
is the same as
|
cranzgot.co.za. IN NS ns1.cranzgot.co.za. |
Each DNS record appears on a single line, associating some host name / domain or IP address with some other host name or IP address. Hence, it is easy to construct a file that makes the Internet think anything you want it to about your organization.
The most basic types of record are the A and PTR records. They simply associate a host name with an IP number, or an IP number with a host name, respectively. You should not have more than one host associated to a particular IP number.
The CNAME record says that a host is just an alias to another host. So have
|
ns1 IN A 196.28.144.1 mail1 IN CNAME ns1.cranzgot.co.za. |
rather than
|
ns1 IN A 196.28.144.1 mail1 IN A 196.28.144.1 |
Finally, NS and MX records
|
<domain> IN NS <nameserver> <domain> IN MX <mailserver> |
just state that domain <domain> has a name server or mail server <nameserver> or <mailserver>, respectively. MTAs can now locate your mail server as being responsible for email addresses of the form user @cranzgot.co.za.
The file /var/named/named.196.28.144 contains reverse lookup data on all 255 IP addresses under 196.28.144.. It is, however, our ISP (called big-isp.net) that is responsible for this address range, possibly having bought all 65536 addresses under 196.28.. The Internet is going to query big-isp.net when trying to do a reverse lookup for 196.28.144.?. The problem here is that there are many companies comprising the 196.28.144.? range, each with their own name server, so no single name server can be authoritative for the whole domain 144.28.196.in-addr.arpa. This is the reason for lines in /var/named/named.196.28.144 like
|
5 IN NS dns.big-isp.net. |
IP address 196.28.144.5 is not our responsibility, and hence we refer any such query to a more authoritative name server. On the ISP side, the name server dns.big-isp.net must have a file /var/named/named.196.28.144 that contains something like:
5 10 15 20 25 30 35 40 45 |
$TTL 259200 @ IN SOA dns.dns.big-isp.net. dns-admin.dns.big-isp.net. ( 2000012101 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 3600000 ; Expire after 42 days 259200 ) ; Minimum Time to Live (TTL) of 3 days IN NS dns.big-isp.net. 0 IN NS ns1.dali.co.za. 1 IN NS ns1.dali.co.za. 2 IN NS ns1.dali.co.za. 3 IN NS ns1.dali.co.za. 4 IN NS ns1.dali.co.za. 5 IN NS ns1.dali.co.za. 6 IN NS ns1.dali.co.za. 7 IN NS ns1.dali.co.za. 8 IN NS ns1.picasso.co.za. 9 IN NS ns1.picasso.co.za. 10 IN NS ns1.picasso.co.za. 11 IN NS ns1.picasso.co.za. 12 IN NS ns1.picasso.co.za. 13 IN NS ns1.picasso.co.za. 14 IN NS ns1.picasso.co.za. 15 IN NS ns1.picasso.co.za. 16 IN NS ns1.cranzgot.co.za. 17 IN NS ns1.cranzgot.co.za. 18 IN NS ns1.cranzgot.co.za. 19 IN NS ns1.cranzgot.co.za. 20 IN NS ns1.cranzgot.co.za. 21 IN NS ns1.cranzgot.co.za. 22 IN NS ns1.cranzgot.co.za. 23 IN NS ns1.cranzgot.co.za. 24 IN NS ns1.matisse.co.za. 25 IN NS ns1.matisse.co.za. 26 IN NS ns1.matisse.co.za. 27 IN NS ns1.matisse.co.za. 28 IN NS ns1.matisse.co.za. 29 IN NS ns1.matisse.co.za. 30 IN NS ns1.matisse.co.za. 31 IN NS ns1.matisse.co.za. ; and so on... up to 255 |
Here, Matisse, Dali, and Picasso are other companies that have bought small IP address blocks from big-isp. Each of these lines will redirect queries to the appropriate name server.
If you have more than one A record for a particular machine, then named will return multiple IP addresses upon a lookup. Load sharing between several web servers is now possible--the record ordering is randomized with each new lookup and your web browser will only choose the first listed IP address. For instance, host cnn.com returns several IP addresses. Their zone file configuration might look like
5 |
cnn.com. IN A 207.25.71.5 cnn.com. IN A 207.25.71.6 . . . cnn.com. IN A 207.25.71.29 cnn.com. IN A 207.25.71.30 |
If you have a dialup connection, the name server should be configured as what is called a caching-only name server. Of course, there is no such thing as a caching-only name server--the term just means that the name. files have only a few essential records in them. The point of a caching server is to prevent spurious DNS lookups that may eat modem bandwidth or cause a dial-on-demand server to initiate a dialout. It also prevents applications blocking, waiting for a DNS lookup. (Typical examples are sendmail, which blocks for a couple of minutes when a machine is turned on without the network plugged in; and netscape 4, which tries to look up the IP address of news.<localdomain>.)
For a caching name server, the /etc/name.conf file should look as follows. Replace <nameserver> with the IP address of the name server your ISP has given you. Your local machine name is assumed to be cericon.priv.ate. (The following listings are minus superfluous comments and newlines for brevity):
5 10 |
options { forwarders { <nameserver>; }; directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "localdomain" { type master; file "named.localdomain"; }; zone "1.0.0.127.in-addr.arpa" { type master; file "named.127.0.0.1";}; zone "priv.ate" { type master; file "named.priv.ate"; }; zone "168.192.in-addr.arpa" { type master; file "named.192.168"; }; |
The /var/named/named.priv.ate file should look like:
5 |
$TTL 259200 @ IN SOA cericon.priv.ate. root.cericon.priv.ate. ( 2000012101 10800 3600 3600000 259200 ) IN NS cericon.priv.ate. cericon IN A 192.168.1.1 news IN A 192.168.1.2 |
The /var/named/named.192.168 file should look like:
5 |
$TTL 259200 @ IN SOA localhost. root.localhost. ( 2000012101 10800 3600 3600000 259200 ) IN NS localhost. 1.1 IN PTR cericon.priv.ate. |
The remaining files are the same as before. In addition to the above, your host name has to be configured as in Chapter 27.
The one contingency of dialup machines is that IP addresses are often dynamically assigned, so your 192.168. addresses aren't going to apply. Probably one way to get around this is to dial in a few times to get a feel for what IP addresses you are likely to get. Assuming you know that your ISP always gives you 196.26.x .x, you can have a reverse lookup file named.196.26 with nothing in it. This will just cause reverse lookups to fail instead of blocking.
Such a ``hack'' is probably unnecessary. It is best to identify the particular application that is causing a spurious dialout or causing a block, and then apply your creativity to the particular case.
named can operate as a backup server to another server, also called a slave or secondary server.
Like the caching-only server there, is no such thing as a secondary server. It's just the same named running with reduced capacity.
Let's say we would like ns2.cranzgot.co.za to be a secondary to ns1.cranzgot.co.za. The named.conf file would look as follows:
5 10 15 20 25 30 35 40 45 50 |
options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "localdomain" { type master; file "named.localdomain"; }; zone "1.0.0.127.in-addr.arpa" { type master; file "named.127.0.0.1"; }; zone "cranzgot.co.za" { type slave; file "named.cranzgot.co.za"; masters { 196.28.144.16; }; }; zone "2.168.192.in-addr.arpa" { type slave; file "named.192.168.2"; masters { 196.28.144.16; }; }; zone "144.28.196.in-addr.arpa" { type slave; file "named.196.28.144"; masters { 196.28.144.16; }; }; zone "44.181.123.160.in-addr.arpa" { type slave; file "named.160.123.181.44"; masters { 196.28.144.16; }; }; |
When an entry has a `` master'' in it, you must supply the appropriate file. When an entry has a `` slave'' in it, named will automatically download the file from 196.28.144.16 (i.e., ns1.cranzgot.co.za) the first time a lookup is required from that domain.
And that's DNS!