![]() |
![]() |
| |||||||||||||||||||||||||||||||||||||||||
Data File Resource Record FormatAll 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 FormatIn 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:
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 FieldThe 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 FieldThe 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 FieldThe third field is the record class. Only one class is currently in use: IN for the TCP/IP protocol family. The record-type FieldThe 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 FieldThe 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 CharactersThe following characters have special meanings. Table 5-5 Special Resource Record Characters
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 EntriesThe 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(). The $INCLUDE EntryAn 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:
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. The $ORIGIN() EntryThe $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 TypesThe most commonly used types of resource records are listed in Table 5-6. They are usually entered in the order shown in Table 5-6, but that is not a requirement. Table 5-6 Commonly Used Resource Record Types
Start-of-Authority record (SOA)Example 5-19 shows the syntax of a start-of-authority (SOA) resource record. Example 5-19 SOA Record Format
The SOA record designates the start of a zone. The zone ends at the next SOA record. The SOA record fields are described below. The name FieldThis field indicates the name of the zone. Note that the zone name must end with a trailing dot. For example: doc.com. is correct, while doc.com is wrong. The class FieldThis field is the address class. For example, IN for Internet (the most commonly used class). The SOA FieldThis field is the type of this resource record. The origin FieldThis field is the name of the host where this data file resides. Note that this host name must end in a trailing dot. For example, dnsmaster.doc.com. is correct, but dnsmaster.doc.com is wrong. | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||