Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

DNS Server Configuration Files

The DNS server is a potentially complex system configured by a surprisingly straightforward set of files. These files consist of a single boot file and several zone data files, each of which is pointed to by a zone record in the boot file. This section discusses these files and their features, syntax, and conventions.

The DNS Boot File: /etc/named.conf

The /etc/named.conf file is read in when named is started. Boot file comments can be done in three different ways:

/* C style comments can comment out multiple lines */
// C++ style comments comment one or fractional lines
# Shellscript style comments function like C++ style

Other statements take the form


   keyword {statement; statement; ...; statement;};

Because everything in this file is brace-, space-, and semicolon-delimited, multiple spacing and line breaks do not affect its functionality.

CAUTION

Bugs caused by syntax errors in the named files are hard to detect. Often there are no symptoms, and even when symptoms are observable, the messages are often cryptic and hard to trace to the bug. So it is imperative to check the files carefully.

The two most common section-starting keywords in named.conf are options and zone. Listing 14.1 is a named.conf that does reverse DNS on its loopback and its eth0, and does forward DNS on domain.cxm.

Example 14.1. Example named.conf File

options {
  directory "/var/named";        #referred files in /var/named
};

zone "." {
  type hint;                     #hints for caching
  file "named.ca";               #root servers file in
};                               #  /var/named/named.ca

zone "0.0.127.in-addr.arpa" {     #reverse on loopback
  type master;
  file "named.local";
};

zone "100.168.192.in-addr.arpa" {  #reverse on eth0 subnet
  type master;                   #file is on this host
  file "named.192.168.100";       #rev dns file
};

zone "domain.cxm" {               #DNS for all hosts this domain
  type master;                   #file is on this host
  file "named.domain.cxm";       #dns file for domain
};

The options section holds information that's global to the entire DNS server. This one contains a single piece of information, the directory statement, which tells named the location of any filenames mentioned in the configuration.

zone "." is the caching zone. A caching zone isn't a master or slave, but rather a set of hints for the server software to use; hence the type hints; statement. The file for zone "." is named.ca, which was created by Red Hat's installation. named.ca contains a list of all the root DNS servers on the Internet. These root servers are needed to prime named's cache. You can get the latest list of root servers from the InterNIC at

ftp://rs.internic.net/domain/named.cache

Each zone has a type statement indicating master, slave, or hint and a file statement pointing to the file containing data for the zone. Files of type slave have a nested master section. This will be demonstrated in the section "Adding a Slave DNS Server," later in this chapter.

Each zone section defines a zone of authority, which is usually a domain, a subdomain or, in the case of reverse DNS, a subnet. Almost every zone defines a file from which it derives its information. Every zone has a type statement.

notify

Another statement appearing frequently in zones and the options section is the notify statement, which can be notify yes; or notify no;. The default is yes, so there's no reason to put in a notify yes; except for documentation. If notify is yes, the zone's slaves are informed of zone data changes so they can initiate a zone transfer. If it's no, no notification is given. notify no; is often inserted to prevent bogus domains (like domain.cxm) from hitting real Internet nameservers. Note that if a notify statement appears in the options section, it serves as the default for all zones but is specified to be overridden by any zone-specific notify statement.

forwarders

With a forwarders statement in the options section, you can specify one or more nameservers to send queries that can't be resolved locally:

options {
  forwarders {  192.168.100.10; 192.168.100.20; } ;
...

This sends unresolved queries to the two servers mentioned instead of sending them to the local caching DNS. This can be advantageous when there's a premium on outside traffic. If all internal servers resolve outside names via one or two servers, those servers build up huge caches, meaning that more queries are resolved inside the building walls. Otherwise, all the servers might be making identical queries to the outside world.

If for some reason the forwarder cannot answer the query, the query is tried via the normal server-caching DNS. To absolutely forbid any remote query from a DNS server, place a forward-only; statement right below the forwarders statement. Doing this makes the forwarder server(s) a single point of failure, so it's not recommended.

DNS Zone Data Files

Zone data files are pointed to by the file statements in the boot file's zone sections and contain all data about the zone. The first thing to understand is that the syntax of a zone data file is totally different from the syntax of the boot file named.conf.

Zone Data File Syntax Is Totally Different from Boot File Syntax

It's important to remember that the syntax of the zone data files is not the same as that of the DNS boot file (named.conf). The zone data file comment character is the semicolon. For each line, DNS will fail if the name data item has spaces before it.

NOTE

The name data item is normally the first on the line and must not be preceded with spaces. However, occasionally the name data item can be absent from the line, giving the appearance of space before the first data item. What's really happening is that the name data item was left off the line, allowing it to default to the name data item in the nearest previous line containing a name data item. For all practical purposes, the next data item after the name is either the word IN or a number representing a "Time To Live" (followed by IN). Knowing this can help you avoid much confusion.

Zone Data File Naming Conventions

A zone data file can be given any name. For maintainability, however, a naming convention should be used. The conventions used in this chapter are outlined in the following paragraphs.

The cache (root server) data file is called named.ca because the Red Hat installation created it with that name. For the same reason, the reverse DNS file for the loopback at 127.0.0.1 is called named.local.

Master forward DNS data files are the word named, followed by a period, followed by the entire domain name. For instance, the master forward DNS data file for domain domain.cxm is called named.domain.cxm.

Master reverse DNS zone data files are the word named, followed by a period, followed by the IP number of the subnet. For instance, the reverse DNS zone data file for subnet 192.168.100 is named.192.168.100. Many people reverse the IP address to match the 100.168.192.in-addr.arpa statement. The naming convention is entirely up to you.

Zone Data Substitutions

As mentioned previously, the file statement in the named.conf zone record points to the zone data file describing the domain named in the zone. Because the domain is specified by the named.conf zone record, that domain is substituted for the @ symbol anywhere that symbol appears in the zone data file. The same is true for reverse DNS subnets. Furthermore, in the zone data file, any name not ending in a period is assumed to be relative to the domain specified in named.conf. For instance, if the domain specified in named.conf is domain.cxm and the name mainserv appears unterminated by a period inside the zone data file, the word mainserv means the same as the absolute version, mainserv.domain.cxm. (note the terminating period).

Zone Data File Components

The zone's file line in the /etc/named.conf file points to a file containing the information that named needs in order to answer queries on the zone's domain. The file format for these configuration files is a bit tricky, unfortunately, and requires care when you're setting it up. Be especially careful with periods—a misplaced period can quickly become difficult to track down.

The format of each line in the configuration file is as follows:


   name    IN    record_type    data

Here name is the hostname you are dealing with. Any hostnames that do not end in a period have the domain name appended to them automatically.

The second column, IN, is actually a parameter telling named to use the Internet class of records. There are two other classes, CH and HS, but they're almost never used.

The third and fourth columns, record_type and data, indicate what kind of record you're dealing with and the parameters associated with it, respectively. There are 10 possible records:

SOA Start of authority
NS Nameserver
A Address record
PTR Pointer record
MX Mail exchanger
CNAME Canonical name
RP and TXT The documentation entries
HINFO Host information
NULL Null resource record with no format or data

SOA: Start of Authority

The SOA record starts the description of a site's DNS entries. The format of this entry is as follows:

domain.cxm. IN SOA ns1.domain.cxm. hostmaster.domain.cxm. (
    2000070100     ; serial number, YYYYMMDDxx
    10800          ; refresh rate in seconds (3 hours)
    1800           ; retry in seconds (30 minutes)
    1209600        ; expire in seconds (2 weeks)
    604800 )       ; minimum in seconds (1 week)

The first line begins with the domain for which this SOA record is authoritative. In most real zone data files, the hard-coded domain.cxm. in the first column would be replaced by the @ symbol. This first data item is followed by IN, to indicate that the Internet standard is being used, and SOA, to indicate start of authority. The column after SOA is the primary nameserver for this domain. Finally, the last column specifies the email address for the person in charge. Note that the email address is not in the standard user @ domain.cxm form, but has a period instead of the @ symbol. A good practice is to create the mail alias hostmaster at your site and have all mail sent to it and forwarded to the appropriate people.

At the end of the first line is an open parenthesis. This tells named that the line continues onto the next line, thereby making the file easier to read.

The five values presented in subsequent lines detail the characteristics of this record. The first line is the record's serial number. Whenever you make a change to any entry in this file, you need to increment this value so secondary servers know to perform zone transfers. Typically, the current date in the form YYYYMMDDxx is used, where YYYY is the year, MM is the month, DD is the day, and xx is the revision done that day. This allows for multiple revisions in one day.

The second value is the refresh rate in seconds. This value tells the slave DNS servers how often they should query the master server to see if the records have been updated.

The third value is the retry rate in seconds. If the secondary server tries to contact the primary DNS server to check for updates but cannot contact it, the secondary server tries again after retry seconds.

When secondary servers have cached the entry, the fourth value indicates to them that if they cannot contact the primary server for an update, they should discard the value after the specified number of seconds. One to two weeks is a good value for this.

The final value, the minimum entry, tells caching servers how long they should wait before expiring the entry if they cannot contact the primary DNS server. Five to seven days is a good guideline for this entry.

Don't forget to place a closing parenthesis after the fifth value.

NS: Nameserver

The NS record specifies the authoritative nameservers for a given domain. For example:

     IN NS    ns1.domain.cxm.
     IN NS    ns2.domain.cxm.

Note that if the NS records directly follow the SOA record, you do not need to specify the name field in the DNS record. In that case, the NS records will assume the same name field as the SOA record.

In this example, the domain, domain.cxm, has two nameservers, ns1.domain.cxm. and ns2.domain.cxm.. These are fully qualified hostnames, so they need to have the period as the suffix. Without the period, named would evaluate their value to be ns1.domain.cxm.domain.cxm, which is not what you're looking for.

A: Address Record

The address record is used for providing translations from hostnames to IP addresses. There should be an A record for each machine that needs a publicly resolvable hostname. A sample entry using the A record is

mydesk    IN A        192.168.100.2

In this example, the address is specified for the host mydesk. Because this hostname is not suffixed by a period, named assumes it is in the same domain as the current SOA record. Thus, the hostname is mydesk.domain.cxm.

PTR: Pointer Record

The pointer record, also known as the reverse resolution record, tells named how to turn an IP address into a hostname. PTR records are a little odd in that they should not be in the same SOA as your A records. Instead, they appear in an in-addr.arpa subdomain SOA.

A PTR record looks like this:

001 2.100.168.192.  IN PTR  mydesk.domain.cxm.
002

Notice that the IP address to be reverse-resolved is in reverse order and is suffixed with a period.

MX: Mail Exchanger

The mail exchanger record enables you to specify which host on your network is in charge of receiving mail from the outside. sendmail uses this record to determine the correct machine to which mail needs to be sent. The format of an MX record looks like this:

domain.cxm.    IN MX 10    mailhub
               IN MX 50    mailhub2

The first column indicates the hostname for which mail is received. In this case, it's domain.cxm. Based on the previous examples, you might have noticed that you have yet to specify a machine that answers to domain.cxm., but the sample MX record shows that you can accept mail for it. This is an important feature of DNS; you can specify a hostname for which you accept mail even if that hostname doesn't have an A record.

As expected, the IN class is the second column. The third column specifies that this line is an MX record. The number after the MX indicates a priority level for that entry. Lower numbers mean higher priority. In this example, sendmail will try to communicate with mailhub first. If it cannot successfully communicate with mailhub, it will try mailhub2.

CNAME: Canonical Name

The CNAME record makes it possible to alias hostnames via DNS. This is useful for giving common names to servers. For example, we are used to Web servers having the hostname www, as in http://www.domain.cxm. However, you might not want to name the Web server using this convention at all. On many sites, the machines have a theme to the naming of hosts, and placing www in the middle of that might appear awkward.

To use a CNAME, you must have another record for that host—such as an A or MX record—that specifies its real name. For example:

mydesk       IN A        192.168.100.2
www       IN CNAME    mydesk

In this example, mydesk is the real name of the server and www is its alias.

RP and TXT: The Documentation Entries

Providing contact information as part of your database is often useful—not just as comments, but as actual records that can be queried by others. You can accomplish this by using the RP and TXT records.

TXT records are freeform text entries in which you can place any information you see fit. Most often, you will only want to give contact information. Each TXT record must be tied to a particular hostname. For example:

domain.cxm.    IN TXT "Contact: Heidi S."
               IN TXT "Systems Administrator/Ring Master"
               IN TXT "Voice: (800) 555-1212"

Because TXT records are freeform, you're not forced to place contact information there. As a result, the RP record was created, which explicitly states who is the person responsible for the specified host. For example:

domain.cxm.        IN RP heidis.domain.cxm. domain.cxm.

The first column states the domain for which the responsible party is set. The second column, IN, defines this record to use the Internet class. RP designates this to be a responsible party record. The fourth column specifies the email address of the person who is actually responsible. Notice that the @ symbol has been replaced by a period in this address, much as in the SOA record. The last column specifies a TXT record that gives additional information. In this example, it points back to the TXT record for domain.cxm.

HINFO: Host Information

These records list various host information, such as CPU type and operating system.

NULL: Null Resource Record

An empty record containing neither format nor data. According to RFC 1035, this can be thought of as a "user defined" record that can contain absolutely anything as long as it's not more than 65535 "octets," which are basically bytes in this context.

Other Resource Records

The DNS standard has other types of resource records. To see the full list, see RFC 1035 and some of the other RFCs that updated it. You can find RFC 1035 at http://ietf.org/rfc/rfc1035.txt. To see the entire list of RFCs, listing replacements and updates, go to ftp://ftp.isi.edu/in-notes/rfc-index.txt

Share ThisShare This

Informit Network