Providing DNS for a Real Domain with BIND


BIND is the de facto standard DNS software suite for UNIX. It contains a nameserver daemon (named) that answers DNS queries, a resolver library that enables programs to make such queries, and some utility programs. BIND is maintained by the ISC (Internet Software Consortium) at the website http://www.isc.org/bind/.

Three major versions of BIND are in common use today: 4, 8, and 9. The use of BIND 4 is now strongly discouraged because of numerous security vulnerabilities and other bugs, and is not discussed here. BIND 8, with many new features and bug fixes, is now quite widely deployed. It is actively maintained, but still vulnerable to a variety of attacks; its use is strongly discouraged as well. Fedora now provides BIND 9.

Note

If you are upgrading from BIND 8 to BIND 9, make sure to read the file /usr/share/doc/bind-9.2.3/misc/migration for any issues regarding configuration files (which will cause BIND not to run) and use of existing shell scripts. An HTML version of the BIND 9 manual is the Bv9ARM.html file under the /usr/share/doc/bind-9.2.3/arm directory.


In this chapter, we discuss the use of BIND 9, which ships with Fedora. BIND 9 was rewritten from scratch in an attempt to make the code more robust and leave behind the problems inherent in the old code. It is compliant with new DNS standards and represents a substantial improvement in features, performance, and security.

The bind RPM package contains the named daemon and a wealth of BIND documentation. The bind-utils RPM package contains, among other things, the invaluable dig(1) utility. If you choose to compile BIND yourself, you can download the source distribution from the ISC's website and follow the build instructions therein.

Note

You can find build instructions in the README file under the /usr/share/doc/bind-9.2.3 directory as well.


After you install the RPMs, the following directories are of special interest because they contain the file used by BIND and contain the information shown in the listing:

---------- /etc/                          The rndc.conf, named.conf configuration files. /usr/bin/                      dig, host, nslookup, nsupdate. /usr/sbin/                     named, rndc, and various support programs. /usr/share/doc/bind-9.2.3/     BIND documentation. /usr/share/man/                Manual pages. /var/named/*                   Zone files. ----------


If you install from source, the files will be in the locations you specified at configure time, with the default directories under /usr/local/.

The following example uses BIND to configure a nameserver and then expand it as necessary to provide useful DNS service. To accomplish this, you must configure named (the nameserver daemon) and rndc components (a control utility that permits various interactions with a running instance of named). You also might need to configure the resolver software, as discussed later. Three configuration files are used:

  • rndc.key to specify the key used to authenticate between rndc and named

  • rndc.conf to configure rndc

  • named.conf to configure named

When rndc communicates with named, it uses cryptographic keys to digitally sign commands before sending them over the network to named. The configuration file, /etc/rndc.key, specifies the key used for the authentication.

The only authentication mechanism currently supported by named is the use of a secret key, encrypted with the HMAC-MD5 algorithm and shared between rndc and named. The easiest way to generate a key is to use the dnssec-keygen utility. In the following example, the utility is asked to generate a 128-bit HMAC-MD5 user key named rndc:

$ dnssec-keygen -a hmac-md5 -b 128 -n user rndc Krndc.+157+14529 $ cat Krndc.+157+14529.private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: mKKd2FiHMFe1JqXl/z4cfw==


The utility creates two files with .key and .private extensions, respectively. The Key: line in the .private file tells us the secret that rndc and named need to share (mKKd2FiHMFe1JqXl/z4cfw==). When we have this, we can set up the rndc.key configuration file, which is shared by both rndc.conf and named.conf.

key "rndc" {  algorithm   hmac-md5;  secret    "mKKd2FiHMFe1JqXl/z4cfw=="; }; ----------


rndc.conf

rndc uses a TCP connection (on port 953) to communicate with named. The configuration file, /etc/rndc.conf by default, must specify a server to talk to as well as include the corresponding key (which must be recognized by named) to use while talking to it:

---------- # Use the key named "rndc" when talking to the nameserver "localhost." server localhost {     key                 "rndc"; }; # Defaults. options {     default-server      localhost;     default-key         "rndc"; }; # Include the key to use include "/etc/rndc.key; ----------


The file needs to have three sections:

  • Server section Defines a nameserver (localhost) and specifies a key (rndc) to be used while communicating with it

  • Options section Sets up reasonable defaults because the file might list multiple servers and keys

  • Key section Includes the file we have already created, /etc/rndc.key

Should you need it, the rndc(8) and rndc.conf(5) manual pages contain more information.

named.conf

You next must configure named itself. Its single configuration file (/etc/named.conf) has syntax very similar to rndc.conf; this section describes only a small subset of the configuration directives essential to the configuration of a functional nameserver. For a more exhaustive reference, consult the BIND 9 ARM (Administrator Reference Manual); it is distributed with BIND, and Fedora Core installs it under /usr/share/doc/bind-*/arm/).

Only the options and named sections in the named.conf file are absolutely necessary. The options section must tell named where the zone files are kept, and named must know where to find the root zone ("."). We also set up a controls section to enable suitably authenticated commands from rndc to be accepted. Because clients (notably nslookup) often depend on resolving the nameserver's IP, we set up the 0.0.127.in-addr.arpa reverse zone as well.

We start with a configuration file similar to this:

----------options {     # This is where zone files are kept. directory            "/var/named"; }; # Allow rndc running on localhost to send us commands. controls {     inet  127.0.0.1         allow { localhost; }         keys { rndc; }; };""include "/etc/rndc.key"; # Information about the root zone. zone "." {     type                hint; file                "root.hints"; }; # Lots of software depends on being able to resolve 127.0.0.1 zone "0.0.127.in-addr.arpa" {     type master;     file                "rev/127.0.0"; }; ----------


The options section is where we specify the directory in which named should look for zone files (as named in other sections of the file). You learn about using other options in later examples in this chapter.

Next, we instruct named to accept commands from an authenticated rndc. We include the key file, /etc/rndc.key, and the controls section saying that rndc connects from localhost and uses the specified key. (You can specify more than one IP address in the allow list or use an access control list as described in the "Managing DNS Security" section, later in this chapter.)

The . zone tells named about the root nameservers with names and addresses in the root.hints file. This information determines which root nameserver is initially consulted, although this decision is frequently revised based on the server's response time. Although the hints file can be obtained via FTP, the recommended, network-friendly way to keep it synchronized is to use dig. We ask a root nameserver (it doesn't matter which one) for the NS records of . and use the dig output directly:

---------- |    # dig @j.root-servers.net. ns > /var/named/root.hints |    # cat /var/named/root.hints |    ; <<>> DiG 8.2 <<>> @j.root-servers.net . ns |    ; (1 server found) |    ;; res options: init recurs defnam dnsrch |    ;; got answer: |    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 |    ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 |    ;; QUERY SECTION: |    ;; ., type = NS, class = IN | |    ;; ANSWER SECTION: |    .                  6D IN NS        H.ROOT-SERVERS.NET. |    .                  6D IN NS        C.ROOT-SERVERS.NET. |    .                  6D IN NS        G.ROOT-SERVERS.NET. |    .                  6D IN NS        F.ROOT-SERVERS.NET. |    .                  6D IN NS        B.ROOT-SERVERS.NET. |    .                  6D IN NS        J.ROOT-SERVERS.NET. |    .                  6D IN NS        K.ROOT-SERVERS.NET. |    .                  6D IN NS        L.ROOT-SERVERS.NET. |    .                  6D IN NS        M.ROOT-SERVERS.NET. |    .                  6D IN NS        I.ROOT-SERVERS.NET. |    .                  6D IN NS        E.ROOT-SERVERS.NET. |    .                  6D IN NS        D.ROOT-SERVERS.NET. |    .                  6D IN NS        A.ROOT-SERVERS.NET. | |    ;; ADDITIONAL SECTION: |    H.ROOT-SERVERS.NET.        5w6d16h IN A    128.63.2.53 |    C.ROOT-SERVERS.NET.        5w6d16h IN A    192.33.4.12 |    G.ROOT-SERVERS.NET.        5w6d16h IN A    192.112.36.4 |    F.ROOT-SERVERS.NET.        5w6d16h IN A    192.5.5.241 |    B.ROOT-SERVERS.NET.        5w6d16h IN A    128.9.0.107 |    J.ROOT-SERVERS.NET.        5w6d16h IN A    198.41.0.10 |    K.ROOT-SERVERS.NET.        5w6d16h IN A    193.0.14.129 |    L.ROOT-SERVERS.NET.        5w6d16h IN A    198.32.64.12 |    M.ROOT-SERVERS.NET.        5w6d16h IN A    202.12.27.33 |    I.ROOT-SERVERS.NET.        5w6d16h IN A    192.36.148.17 |    E.ROOT-SERVERS.NET.        5w6d16h IN A    192.203.230.10 |    D.ROOT-SERVERS.NET.        5w6d16h IN A    128.8.10.90 |    A.ROOT-SERVERS.NET.        5w6d16h IN A    198.41.0.4 | |    ;; Total query time: 4489 msec |    ;; FROM: lustre to SERVER: j.root-servers.net 198.41.0.10 |    ;; WHEN: Mon Sep 10 04:18:26 2001 |    ;; MSG SIZE sent: 17 rcvd: 436 ----------


The Zone File

The zone 0.0.127.in-addr.arpa section in named.conf says that we are a master nameserver for that zone and that the zone data is in the file 127.0.0. Before examining the first real zone file in detail, look at the general format of a resource record specification:

name   TTL   class   type   data


Here, name is the DNS name with which this record is associated. In a zone file, names ending with a "." are fully qualified, whereas others are relative to the name of the zone. In the zone example.com, foo refers to the fully qualified name foo.example.com. The special name @ is a short form for the name of the zone itself. If the name is omitted, the last specified name is used again.

The TTL (Time To Live) field is a number that specifies the time for which the record can be cached. This is explained in greater detail in the discussion of the SOA record in the next section. If this field is omitted, the default TTL for the zone is assumed. TTL values are usually in seconds, but you can append an m for minutes, h for hours, or d for days.

BIND supports different record classes, but for all practical purposes, the only important class is IN, for Internet. If no class is explicitly specified, a default value of IN is assumed; to save a little typing, we do not mention the class in any of the zone files we write here.

The type field is mandatory and names the RR in use, such as A, NS, MX, or SOA. (We use only a few of the existing RRs here. Consult the DNS standards for a complete list.)

The data field (or fields) contains data specific to this type of record. The appropriate syntax will be introduced as we examine the use of each RR in turn.

Here is the zone file for the 0.0.127.in-addr.arpa zone:

---------- |    $TTL 2D |    @       SOA      localhost. hostmaster.example.com. ( |                             2001090101  ; Serial |                             24h         ; Refresh |                             2h          ; Retry |                             3600000     ; Expire (1000h) |                             1h)         ; Minimum TTL |            NS       localhost. | 1       PTR       localhost. ----------


The $TTL directive that should begin every zone file sets the default minimum time to live for the zone to two days. This is discussed further in the next section.

The Zone File's SOA Record

The second line in the zone file uses the special @ name that you saw earlier. Here, it stands for 0.0.127.in-addr.arpa, to which the SOA (Start of Authority) record belongs. The rest of the fields (continued until the closing parenthesis) contain SOA-specific data.

The first data field in the SOA record is the fully qualified name of the master nameserver for the domain. The second field is the email address of the contact person for the zone. It is written as a DNS name by replacing the @ sign with a "."; foo@example.com would be written as foo.example.com. (note the trailing .).

Do not use an address such as a.b@example.com because it is written as a.b.example.com and will later be misinterpreted as a@b.example.com.

Tip

It is important to ensure that mail to the contact email address specified in the SOA field is frequently read because it is used to report DNS setup problems and other potentially useful information.


The next several numeric fields specify various characteristics of this zone. These values must be correctly configured, and to do so, you must understand each field. As shown in the comments (note that zone file comments are not the in the same syntax as named.conf comments), the fields are serial number, refresh interval, retry time, expire period, and minimum TTL.

Serial numbers are 32-bit quantities that can hold values between 0 and 4,294,967,295 (2321). Every time the zone data is changed, the serial number must be incremented. This change serves as a signal to slaves that they need to transfer the contents of the zone again. It is conventional to assign serial numbers in the format YYYYMMDDnn; that is, the date of the change and a two-digit revision number (for example, 2001090101). For changes made on the same day, you increment only the revision. This reasonably assumes that you make no more than 99 changes to a zone in one day. For changes on the next day, the date is changed and the revision number starts from 01 again.

The refresh interval specifies how often a slave server should check whether the master data has been updated. It has been set to 24 hours here, but if the zone changes often, the value should be lower. Slaves can reload the zone much sooner if both they and the master support the DNS NOTIFY mechanism, and most DNS software does.

The retry time is relevant only when a slave fails to contact the master after the refresh time has elapsed. It specifies how long it should wait before trying again. (It is set to two hours here.) If the slave is consistently unable to contact the master for the length of the expire period (usually because of some catastrophic failure), it discards the zone data it already has and stops answering queries for the zone. Thus, the expire period should be long enough to allow for the recovery of the master nameserver. It has been repeatedly shown that a value of one or two weeks is too short. One thousand hours (about six weeks) is accepted as a good default.

As you read earlier, every RR has a TTL field that specifies how long it can be cached before the origin of the data must be consulted again. If the RR definition does not explicitly specify a TTL value, the default TTL (set by the $TTL directive) is used instead. This enables individual RRs to override the default TTL value as required.

The SOA TTL, the last numeric field in the SOA record, is used to determine how long negative responses (NXDOMAIN) should be cached. (That is, if a query results in an NXDOMAIN response, that fact is cached for as long as indicated by the SOA TTL.) Older versions of BIND used the SOA minimum TTL to set the default TTL, but BIND 9 no longer does so. The default TTL of 2 (two days) and SOA TTL of 1 (one hour) are recommended for cache friendliness.

The values used previously are good defaults for zones that do not change often. You might have to adjust them a bit for zones with very different requirements. In that case, the website at http://www.ripe.net/docs/ripe-203.html is recommended reading.

The Zone File's Other Records

The next two lines in the zone file create NS and PTR records. The NS record has no explicit name specified, so it uses the last one, which is the @ of the SOA record. Thus, the nameserver for 0.0.127.in-addr.arpa is defined to be localhost.

The PTR record has the name 1, which becomes 1.0.0.127.in-addr.arpa (which is how you write the address 127.0.0.1 as a DNS name). When qualified, the PTR record name 1 becomes localhost. (You will see some of the numerous other RR types later when we configure our nameserver to be authoritative for a real domain.)

TXT Records and SPF

One record not already mentioned is the TXT record. This record is usually used for documentation purposes in DNS, but a recent proposal uses the TXT record to help in the fight against email address forgery, spam, and phishing attacks.

One problem with email and SMTP is that when email is being delivered, the sender can claim that the email is coming from trusted.bank.com, when really it is coming from smalltime.crook.com. When the recipient of the email gets the email, it looks like valid instructions from trusted. bank.com, but if the receiver trusts the email and follows its instructions, his bank accounts can become vulnerable. These situations can be controlled by using SPF (Sender Policy Framework).

Domains can publish the valid IP address of their email servers in specially formatted TXT records. A TXT record could look like this:

trusted.bank.com. IN TXT "v=spf1 ip4:37.21.50.80 -all"


This record specifies that only one IP address is allowed to send mail for trusted.bank.com.

Receiving email servers can then do one extra check with incoming email. When an email arrives, they know the IP address that the email is coming from. They also know that the sender claims to be coming from trusted.bank.com, for example. The receiving email server can look up the DNS TXT record for trusted.bank.com, extract the allowed IP addresses, and compare them to the IP address that the email really is coming from. If they match, it is an extremely good indication that the email really is coming from trusted.bank.com. If they do not match, it is a very good indication that the email is bogus and should be deleted or investigated further.

The SPF system does rely on cooperation between senders and receivers. Senders must publish their TXT records in DNS, and receivers must check the records with incoming email. If you want more details on SPF, visit the home page at http://spf.pobox.com/.


Logging

We now have all the elements of a minimal functioning DNS server, but before we experiment further, some extra logging will allow us to see exactly what named is doing. Log options are configured in a logging section in named.conf, and the various options are described in detail in the BIND 9 ARM.

All log messages go to one or more channelseach of which can write messages to the syslog, to an ordinary file, stderr, or null. (Log messages written to null are discarded.) Categories of messages exist, such as those generated while parsing configuration files, those caused by OS errors, and so on. Your logging statement must define some channels and associate them with the categories of messages that you want to see.

BIND logging is very flexible, but complicated, so we examine only a simple log configuration here. The following addition to named.conf sets up a channel called custom, which writes time-stamped messages to a file and sends messages in the listed categories to it:

---------- |    logging { |        channel custom { |            file "/tmp/named.log";  # Where to send messages. |            print-time yes;         # Print timestamps? |            print-category yes;     # Print message category? |        }; | |        category config       { custom; };     # Configuration files |        category notify       { custom; };     # NOTIFY messages |        category dnssec       { custom; };     # TSIG messages |        category general      { custom; };     # Miscellaneous |        category security     { custom; };     # Security messages |        category xfer-out     { custom; };     # Zone transfers |        category lame-servers { custom; }; |    }; | ----------


Note

Retaining and frequently examining your logs is especially important because syntax errors often cause BIND to reject a zone and not answer queries for it, causing your server to become lame (meaning that it is not authoritative for a zone for which it is supposed to be).


Resolver Configuration

The last step before running BIND is to set up the local resolver software. This involves configuring the /etc/hosts, /etc/resolv.conf, and /etc/nsswitch.conf files.

To avoid gratuitous network traffic, most UNIX resolvers still use a hosts-like text file named /etc/hosts to store the names and addresses of commonly used hosts. Each line in this file contains an IP address and a list of names for the host. Add entries to this file for any hosts you want to be able to resolve independently from DNS. If the entry is found in /etc/hosts, the resolver does not have to contact a DNS server to resolve the name, which reduces network traffic.

/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 the ability 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 ndcthe 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!



Red Hat Fedora 5 Unleashed
Red Hat Fedora 5 Unleashed
ISBN: 067232847X
EAN: 2147483647
Year: 2004
Pages: 362

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net