The named.local File
The named.local file specifies the address for the local loopback interface, or localhost, with the network address 127.0.0.1. The name of this file is specified in the boot file. Like other files, you can give it a name other than the name used in this manual.
Setting Up the named.local File
The named.local file sets up the local loopback interface for your name server.
Example 5-18 Sample named.localFile
A named.local file contains these elements:
A Start of Authority (SOA) record, which indicates the start of a zone and includes the name of the host on which the named.local data file reside.
One or more Name Server (NS) records identifying master and slave DNS name servers. Server and domain names should be fully qualified.
A PTR record for localhost
$INCLUDE Files
An include file is any file named in an $INCLUDE() statement in a DNS data file. $INCLUDE files can be used to separate different types of data into multiple files for your convenience.
For example, suppose a data file contained following line:
$INCLUDE /etc/named/data/mailboxes |
This line causes the /etc/named/data/mailboxes file to be loaded at that point. In this instance, /etc/named/data/mailboxes is an $INCLUDE file. Use of $INCLUDE files is optional. You can use as many as you wish, or none at all.
Data File Resource Record Format
All the data files used by the DNS daemon in.named are written in standard resource record format. Each DNS data file must contain certain resource records. This section describes the DNS data files and the resource records each file should contain.
Standard Resource Record Format
In the standard resource record format, each line of a data file is called a resource record (RR), which contains the following fields separated by white space:
namettlclassrecord-typerecord-specific-data |
The order of the fields is always the same; however, the first two are optional (as indicated by the brackets), and the contents of the last vary according to the record-type field.
The name Field
The first field is the name of the domain that applies to the record. If this field is left blank in a given RR, it defaults to the name of the previous RR.
A domain name in a zone file can be either a fully qualified name, terminated with a dot, or a relative name, in which case the current domain is appended to it.
The ttl Field
The second field is an optional time-to-live field. This specifies how long (in seconds) this data will be cached in the database before it is disregarded and new information is requested from a server. By leaving this field blank, the ttl defaults to the minimum time specified in the Start-Of-Authority (SOA) resource record.
If the ttl value is set too low, the server will incur a lot of repeat requests for data refreshment; if, on the other hand, the ttl value is set too high, changes in the information will not be timely distributed.
Most ttl values should be initially set to between a day (86400) and a week (604800). Then, depending on the frequency of actual change of the information, you can change the appropriate ttl values to reflect that frequency. Also, if you have some ttl values that have very high numbers because you know they relate to data that rarely changes. When you know that the data is now about to change, reset the ttl to a low value (3600 to 86400) until the change takes place. Then change it back to the original high value.
All RR's with the same name, class, and type should have the same ttl value.
The class Field
The third field is the record class. Only one class is currently in use: IN for the TCP/IP protocol family.
The record-type Field
The fourth field states the resource record type. There are many types of RR's; the most commonly used types are discussed in "Resource Record Types".
The record-specific-data Field
The contents of the record-specific-data field depend on the type of the particular resource record.
Although case is preserved in names and data fields when loaded into the name server, all comparisons and lookups in the name server database are case insensitive. However, this situation might change in the future; thus, you should be consistent in your use of lower and uppercase.
Special Resource Record Characters
The following characters have special meanings:
Table 5-6 Special Resource Record Characters
Character | Definition |
|---|---|
. | A free-standing dot in the name field refers to the current domain. |
@ | A free-standing @ in the name field denotes the current origin. |
.. | Two free-standing dots represent the null domain name of the root when used in the name field. |
\X | Where X is any character other than a digit (0-9), quotes that character so that its special meaning does not apply. For example, you can use \. to place a dot character in a label. |
\DDD | Where each D is a digit, this is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. |
() | Use parentheses to group data that crosses a line. In effect, line terminations are not recognized within parentheses. |
; | A semicolon starts a comment; the remainder of the line is ignored. |
* | An asterisk signifies a wildcard. |
Most resource records have the current origin appended to names if they are not terminated by a dot (.) This is useful for appending the current domain name to the data, such as machine names, but might cause problems when you do not want this to happen. You should use a fully qualified name ending in a period if the name is not in the domain for which you are creating the data file.
Control Entries
The only lines that do not conform to the standard RR format in a data file are control-entry lines. There are two kinds of control entries: $INCLUDE() and $ORIGIN().
$INCLUDE
An include line begins with $INCLUDE in column 1, and is followed by a file name (known as the $INCLUDE file). This feature is particularly useful for separating different types of data into multiple files as in this example:
$INCLUDE /etc/named/data/mailboxes |
The line is interpreted as a request to load the /etc/named/data/mailboxes file at that point. The $INCLUDE command does not cause data to be loaded into a different zone or tree. The command allows for data for a given zone to be organized in separate files. For example, mailbox data might be kept separately from host data using this mechanism.
Use of $INCLUDE statements and files is optional. You can use as many as you wish, or none at all.
$ORIGIN()
The $ORIGIN command is a way of changing the origin in a data file. The line starts in column 1, and is followed by a domain name. It resets the current origin for relative domain names (for example, not fully qualified names) to the stated name. This is useful for putting more than one domain in a data file.
Note - You cannot use $ORIGIN() for putting more than one zone in a data file.
Use of $ORIGIN commands in a data file is optional. If there is no $ORIGIN() statement the default origin for DNS data files is the domain named in the second field of the master or slave line of the named.conf file.
Resource Record Types
The most commonly used types of resource records are listed in Table 5-7. They are usually entered in the order shown in Table 5-7, but that is not a requirement.
Table 5-7 Commonly Used Resource Record Types
Type | Description |
|---|---|
SOA | Start of authority |
NS | Name server |
A | Internet address (name to address) |
PTR | Pointer (address to name) |
CNAME | Canonical name (nickname) |
TXT | Text information |
WKS | Well-known services |
HINFO | Host information |
MX | Mail exchanger |