Andrew Hudson - Fedora™ Unleashed, 2008 edition

One record not already mentioned is the TXTrecord. 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 TXTrecords. A TXTrecord 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 TXTrecord 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/.

The example now has all the elements of a minimal functioning DNS server, but before experimenting further, some extra logging will allow you to see exactly what namedis 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 channels — each of which can write messages to the syslog, to an ordinary file, stderr, or null. (Log messages written to nullare 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.confsets 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; };

| };

----------

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 the zone for which it is supposed to be).

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.conffiles.

To avoid gratuitous network traffic, most UNIX resolvers still use a hosts-like text file named /etc/hoststo 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.confspecifies 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.4is the address of the nameserver). You can use multiple nameserverlines (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.netcauses 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 dnsline in /etc/nsswitch.confcauses the resolver to consult /etc/hostsbefore 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, bindline in the /etc/host.conffile instead.)

Finally! You can now start namedwith /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 rndcto interact with this instance of named. Running rndcwithout 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, rndcdoes not yet implement all the commands that were supported by ndc— the control program shipped with earlier versions of BIND.