Andrew Hudson - Fedora™ Unleashed, 2008 edition

Mail sent to this address should be read frequently. The other fields should contain sensible values for your zone, and the serial number should be correctly incremented after each change.

As discussed earlier, Aand PTRrecords should always match; that is, the A record pointed to by a PTRrecord should point back to the address of the PTR record. Remember to quote the two arguments of HINFOrecords if they contain any whitespace. Avoid the use of CNAMErecords for MX, NS, and SOArecords.

In general, after making changes to zone data, it is a good idea to reload namedand examine the logs for any errors that cause namedto complain or reject the zone. Even better, you could use one of the verification tools, such as dnswalk, discussed briefly next.

BIND includes the always useful digprogram, as well as named-checkconf(to check /etc/named.conffor syntax errors) and named-checkzone(to do the same for zone files). We also especially recommend dnswalkand nslint. dnswalkis a Perl script that scans the DNS setup of a given domain for problems. It should be used in conjunction with RFC 1912, which explains most of the problems it detects. nslint, like the analogous lintutility for C programs, searches for common BIND and zonefile configuration errors.

By occasionally using these programs to troubleshoot DNS problems (especially after nontrivial zone changes), you go far toward keeping your DNS configuration healthy and trouble free.

Fedora provides a dozen or more different graphical configuration tools system administrators can use to configure network (and system) services. One of these tools is system-config-bind, a deceptively simple BIND configuration tool that requires an active X session and must be run with rootprivileges.

You can launch this client by using the command system-config-bindfrom a terminal window or by selecting the Domain Name Service menu item from the Server Settings menu. system-config-bindis automatically installed if you select the Fedora configuration tools.

Using system-config-bindand then saving any changes overwrites existing settings! If you prefer to manually edit your namedconfiguration files, do not use system-config-bind. Always make a backup of the configuration files in any event — you'll be glad you did.

After you type the root password and press the Enter key, the client launches. You then see its main window, as shown in Figure 23.2.

FIGURE 23.2 Fedora's system-config-bindutility can be used to create, modify, and save basic domain nameserver settings.

system-config-bindcan be used to add a forward master zone, reverse master zone, MXrecords, or slave zone. Click the New button to select an entry for configuration, as shown in Figure 23.3.

FIGURE 23.3 Use system-config-bindto add a new DNS record to your server or edit the existing settings.

You can edit or delete existing settings by first selecting and then clicking the Properties or Delete button in the system-config-binddialog. When you finish entering or editing your custom settings, select the Save menu item from the File menu. Configuration files are saved in /etc/named.confand under the /var/nameddirectory.

Security considerations are of vital importance to DNS administrators because DNS was not originally designed to be a secure protocol and a number of successful attacks against BIND have been found over the years. The most important defense is to keep abreast of developments in security circles and act on them promptly.

DNS is especially vulnerable to attacks known as poisoning and spoofing. Poisoning refers to placing incorrect data into the DNS database, which then spreads to clients and caches across the world, potentially causing hundreds of thousands of people to unwittingly use the bad data. Although DNS poisoning can occur because of carelessness, it has serious implications when performed deliberately. What if someone set up a clone of a common website, redirected users to it by DNS poisoning, and then asked them for their credit card numbers? Spoofing , the practice of forging network packets and making nameservers believe that they are receiving a valid answer to a query, is one of the ways malicious poisoning can be performed.

BIND has often been criticized as being very insecure, and although recent versions are greatly improved in this regard, DNS administrators today must take several precautions to ensure that its use is adequately protected from attacks. Of course, it is important to always run the latest recommended version of BIND.

One of your strongest defenses against DNS security risks is to keep abreast of developments in security circles and act on them promptly. The BugTraq mailing list, hosted at http://www.securityfocus.com/, and the SANS Institute, at http://www.sans.org/, are good places to start.

The most important step in securing any UNIX system is to configure the environment BIND in which runs to use all the security mechanisms available to it through the operating system to its advantage. In short, this means that you should apply general security measures to your computer.

Run namedwith as few privileges as it needs to function. Do not run namedas root. Even if an attacker manages to exploit a security hole in BIND, the effects of the break-in can be minimized if namedis running as user nobodyrather than as root. Of course, namedhas to be started as root because it needs to bind to port 53, but it can be instructed to switch to a given user and group with the -uand -gcommand-line options.

Starting namedwith a command such as named -u nobody -g nogroupis highly recommended. Remember, however, that if you run multiple services as nobody, you increase the risks of a compromise. In such a situation, it is best to create separate accounts for each service and use them for nothing else. Fedora runs namedas the user named.

You can also use the chroot feature of UNIX to isolate namedinto its own part of the file system. If correctly configured, such a file system "jail" restricts attackers — if they manage to break in — to a part of the file system that contains little of value. It is important to remember that a chroot jail is not a panacea, and it does not eliminate the need for other defensive measures.

Programs that use chrootbut do not take any other precautions have been shown to be unsecure. BIND does take such additional precautions. See the chroot-BIND HOWTO at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Chroot-BIND-HOWTO.html.

For a chrootenvironment to work properly, you have to set up a directory that contains everything BIND needs to run. It is recommended that you start with a working configuration of BIND, create a directory — say /usr/local/bind— and copy over the files it needs into subdirectories under that one. For instance, you have to copy the binaries, some system libraries, the configuration files, and so on. Consult the BIND documentation for details about exactly which files you need.