The Domain Name System (DNS) configuration file, by default called
/etc/namedb/named.conf, specifies the names of the DNS data files.
These data files consist of entries, also known as Resource Records (RR),
that follow the formats described in this chapter.
G.1 Format of DNS Resource Records
Here is the general format of a DNS Resource Record:
name ttl addr-class entry-type entry-specific-data
The fields are defined as follows:
| Field | Description |
| name | This is the name of the domain, for
example
For some data file entries the name field is left blank. In that case, the domain name is assumed to be the same as the previous entry. A free standing period (.) refers to the current domain. A free standing at sign ( Two
free standing periods ( |
| ttl | This is the time-to-live field, and specifies how long, in seconds, the data will be stored in the database. If this field is left blank, the value defaults to the ttl value specified in the SOA (start of authority) entry or, ultimately, the value of the $ttl entry. The maximum time-to-live is 99999999 seconds, or 3 years. |
| addr-class | This field is the address class. There are three classes: IN — Internet addresses, TXT — naming service data, ANY — all other types of network addresses. The address class of all data file entries of a given entry-type in a particular zone must be the same. Therefore, only the first entry in a zone need specify the addr-class field. |
| entry-type | This field states the resource record type, for example SOA (start of authority) or A (address). |
| entry-specific-data | All fields after the entry-type field vary for each type of date file entry (resource record). |
The case is preserved in name and data fields when loaded into the DNS server. Comparisons and lookups using DNS are case insensitive.
The following characters have special meanings in DNS data file entries:
| Character | Meaning |
| \x | A backslash (\) escapes the next nondigit (x) character so that the character's special meaning does not apply. For example, you could use a period (.) to place a period character in a label. |
| \nnn | A backslash denotes the octet corresponding to the decimal number represented by nnn. The resulting octet is assumed to be text and is not checked for special meaning. |
| () | Parentheses group data that cross a line. In effect, line terminations are not recognized within parentheses. |
| ; | A semicolon starts a comment, causing the rest of the line to be ignored. |
| * | An asterisk signifies a wildcard. |
Most DNS data file entries have the current domain appended to their names if they are not terminated by a period (.). This is useful for appending the current domain name to the data, such as system names, but could cause problems when you do not want this to happen. Therefore, if the name is not in the domain for which you are creating the data file, end the name with a period.
Data files (resource records) can have the following types of entries:
G.2 Description of Data File Entries
The following sections describe each data file entry and its format.
G.2.1 Include Entry
An include entry is similar to a header file in the C programming language.
This feature is particularly useful for separating different types of data
into multiple files.
An include entry begins with
$include
in the first column, and is followed by the name of the file to be included.
For example:
$include /etc/namedb/mailboxes
This entry requests DNS to load the data file
/etc/namedb/mailboxes.
The include entry loads data files into the local zone and acts as a
data file organizer.
For example, you can use
$include
entries to separate mail from host information.
G.2.2 Origin Entry
An origin entry changes the origin in a data file.
This feature is particularly
useful for putting more than one domain in a data file.
An origin entry begins
with
$origin
in the first column, followed by a domain
origin, as shown in the following example:
$origin state.dec.com.
This entry includes the domain
state.dec.com
in
the data file.
As a result, DNS can provide information about the
state.dec.com
domain in addition to the local domain, provided your
server has authority for the zone.
The
$origin
and
$include
entries
can work together.
They can save typing and help keep the files organized.
For example, assume that the following entries are in the
hosts.rev
file:
$origin ll.128.in-addr.arpa. $include cities.dec.com.rev
The period after
arpa
signifies the complete domain
name.
Assume that the
cities.dec.com.rev
file consists
of entries similar to the following:
33.22 IN PTR chicago.cities.dec.com.
In this situation, the complete reverse name for the host chicago is translated to be as follows:
33.22.11.128. in-addr.arpa. IN PTR chicago.cities.dec.com.
The time-to-live entry is similar to the ttl field in other resource
records; it specifies how long data will be stored in the cache.
However,
when you set the time-to-live in the optional
$ttl
entry,
the limit takes takes effect only if no time-to-live value is specified for
a particular resource record or its corresponding SOA record.
A
$ttl
entry begins with
$ttl
in the first column, a value in the second column, and an optional comment
in the third column.
For example, this entry specifies that resource records
without a specified ttl will expire after 21600 seconds (or six hours):
$ttl 21600 default time to live
When you specify it in this manner, the time-to-live value must be in the range of 0 to 2147483647 seconds. Alternatively, you can specify the time-to-live in the following format, where you need not specify all of the fields:
weeksWdaysDhoursHminutesMsecondsS
For example, the maximum value in this format (3550 weeks, 5 days, 3 hours, 14 minutes, 7 seconds) would be specified as follows:
$ttl 3550W5D3H14M7S
The address (A) data file entry lists the IPv4 address for a specific system. An A entry has the following format:
name ttl addr-class entry-type address
The fields in the A entry have the values described in Section G.1, with the exception of the address field. This field specifies the IPv4 address for each system. There must be only one A entry for each address on a given system.
The following is an example of two A entries:
;name ttl addr-class entry-type address
miami.cities.dec.com. IN A 128.11.22.44
IN A 128.11.22.33
In this example, the host miami.cities.dec.com has two IP addresses, both IPv4. (See Section G.2.5 for an example of a host with an IPv4 address and an IPv6 address.)
Note that in the first entry the
ttl
field
is blank, thus using the default ttl specified in the SOA entry or the $ttl
entry.
In the second entry, the first and second fields are blank, thus using
the default name specified in the previous entry and the same default ttl.
G.2.5 IPv6 Address Entry
The IPv6 address (AAAA) data file entry lists the address for a specific IPv6 system. An AAAA entry has the following format:
name ttl addr-class entry-type address
The fields in the AAAA entry have the values described in Section G.1, with the exception of the address field. This field specifies the IPv6 address for each system. There must be only one AAAA entry for each address on a given system.
The following is an example of a AAAA entry:
;name ttl addr-class entry-type address
boston.cities.dec.com. IN A 128.11.22.42
IN AAAA 1070:0:0:0:0:800:200C:417B
In this example, the host boston.cities.dec.com has two IP addresses, one IPv4 address and one IPv6 address. The coupling of the AAAA entry with the A entry is typical of some IPv6 configurations because it provides backwards compatibility for IPv4 networks.
See
Network Administration: Connections
for more information about IPv6.
G.2.6 Canonical Name Entry
The canonical name (CNAME) entry specifies an alias for a canonical name. For example, if the canonical name (also known as the full DNS name or the fully qualified name) is miami.cities.dec.com, a reasonable alias might be miami or mi.
An alias must be unique, and all other entries must be associated with the canonical name and not with the alias. Do not create an alias and then use it in other entries. A CNAME entry has the following format:
aliases ttl addr-class entry-type can-name
The fields in the CNAME entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| alias | This field specifies the nickname (alias) of the canonical name of the host. |
| can-name | This is the canonical name of the host. If the canonical name is a part of the current domain, you need to specify only the host name; for example, miami. If the canonical name is for a host in another domain, you must specify the fully qualified DNS name, followed by a period (.). For example: ohio.state.dec.com. |
The following example shows two CNAME entries. The first entry is for a CNAME in the current domain, cities.dec.com; the second entry is for a CNAME in another domain:
;aliases ttl addr-class entry-type can-name to IN CNAME toledo oh IN CNAME ohio.state.dec.com.
The host information (HINFO) data file entry is for host specific information. This entry lists the hardware and operating system that are running at the specified host system. Only a single space separates the name of the hardware from the operating system information. Thus, if you need to use spaces as part of a host or operating system name, you must place the name in quotation marks. In addition, there can be no more than one HINFO entry for each host on the domain. The following is the HINFO entry format:
host ttl addr-class entry-type hardware opsys
The fields in the HINFO entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| host | This field specifies the host name. If the host is in the current domain, you need to specify only the host; for example, chicago. If the host is in a different domain, you must specify the full DNS name, for example, utah.state.dec.com.. Be sure to include the period (.) at the end of the host name. This indicates the fully qualified DNS name. |
| hardware | This field specifies the type of CPU; for example, an AlphaServer 8400. |
| opsys | This field specifies the type of operating system running on the specified host. Its recommended setting is Tru64 UNIX for the Tru64 UNIX operating system. |
The following is an example of a HINFO entry:
;name ttl addr-class entry-type hardware opsys ohio.state.dec.com. IN HINFO "AlphaServer 8400" "Tru64 UNIX"
In this example, note that the second field specifying the ttl is blank,
thus using the default ttl specified in the SOA entry or the $ttl entry.
G.2.8 Mailbox Entry
The mailbox (MB) entry lists the system where a user wants to receive mail. The following is the format of an MB entry:
login ttl addr-class entry-type system
The fields in the MB entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| login | This field is the login name for a user. Login names must be unique for the domain. |
| system | This field specifies the name system where the user wants to receive mail. |
The following is an example of an MB entry:
;login ttl addr-class entry-type system fred IN MB potsdam.cities.dec.com.
In this example, note that the second field is blank, thus using the
default ttl specified in the SOA entry or the $ttl entry.
Consequently, the
user Fred will have mail delivered to the host named potsdam in the domain
cities.dec.com.
G.2.9 Mail Group Entry
The mail group (MG) entry specifies the members of a mail group. The MG entry is usually used with a MINFO entry. The following is the format of an MG entry:
group ttl addr-class entry-type member
The fields in the MG entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| group | This field specifies the name of the mail group, for example, users or marketing. |
| member | This field specifies the login name and the domain of the user to be included in the mail group. |
The following is an example of a MINFO entry and several MG entries:
;group ttl addr-class entry-type requests member
fun IN MINFO BIND-REQUEST fred@miami.cities.dec.com.
IN MG john@miami.cities.dec.com.
MG amy@miami.cities.dec.com.
In this example, note that the second field for all three entries is
blank, thus using the default ttl specified in the SOA entry or the $ttl entry.
In addition, Fred, John, and Amy will receive any mail sent to the mail group
fun.
G.2.10 Mailbox Information Entry
The mailbox information (MINFO) entry creates a mail group for a mailing list. The MINFO entry is usually associated with a mail group (MG) entry, but can also be used with a mailbox (MB) entry. The following is the format of a MINFO entry:
mailbox ttl addr-class entry-type requests maintainer
The fields in the MINFO entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| mailbox | This field specifies the name of the mailbox,
and its value is usually
BIND. |
| requests | This field specifies the name where users can send mail relating to DNS or mail. For example, a user might want to send a mail message requesting that an alias be set up. |
| maintainer | This field contains the login name of the person who will receive mail error messages. This is particularly useful when an error in member's names needs to be reported to a person other than the sender. |
The following is an example of a MINFO entry:
mailbox ttl addr-class entry-type requests maintainer BIND IN MINFO BIND-REQUEST fred@miami.cities.dec.com.
In this example, note that the second field is blank, thus using the
default ttl specified in the SOA entry or the $ttl entry.
G.2.11 Mail Rename Entry
The mail rename (MR) entry lists aliases for a specific user. The following is the format of an MR entry:
alias ttl addr-class entry-type login
The fields in the MR entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| alias | This field lists the nicknames for the specified user. The alias must be unique to the domain. |
| login | This field is the login name for the user whose alias is being established. There should also be a corresponding MB entry for the specified login name. Login names must be unique for the domain. |
The following is an example of an MR entry:
;alias ttl addr-class entry-type login lady IN MR diana princess IN MR diana
This example shows how to set up the aliases lady and princess for a
user whose login name is diana.
Note that the second field is left blank,
thus using the default ttl specified in the SOA entry or the $ttl entry.
G.2.12 Mail Exchanger Entry
The mail exchanger (MX) entry specifies a system in the local domain (called a gateway) that knows how to deliver mail to a system that might not be directly connected to the local network. Consequently, the MX entry is useful for systems outside your local network that want to send mail to a user on one of your network's hosts.
You can also use the MX entry to list some of the hosts in the
/etc/hosts
file so that they do not appear to other systems using
DNS service.
The following is the format of an MX entry:
system ttl addr-class entry-type pref-value gateway
The fields in the MX entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| system | This field specifies the name of the system where mail is to be sent. |
| pref-value | This field specifies the order a mailer is to follow when there is more than one way to deliver mail to a given system. |
| gateway | This field contains the name of the gateway system, that is, the system that can deliver mail to the destination system on another network. |
The following is an example of two MX entries:
;system ttl addr-class entry-type pref-value gateway tampa.cities.dec.com IN MX 0 seismo.cs.au. *.folks.dec.com IN MX 0 relay.cs.net.
In this example, all mail destined for the domain folks.dec.com, regardless
of the host name, is sent by route of the relay.cs.net host.
In addition,
note that the ttl field in both entries is blank, thus using the default ttl
specified in the SOA entry or the $ttl entry.
The second entry uses an asterisk,
which is a wildcard.
G.2.13 Name Server Entry
The name server (NS) entry specifies that a system is a name server for the specified domain. The following is the format of the NS entry:
name ttl addr-class entry-type server
The fields in the NS entry have the values described in Section G.1, with the exception of the server field. This field specifies the name of the primary master server for the domain specified in the first field.
The following is an example of an NS entry:
;name ttl addr-class entry-type server
IN NS utah.states.dec.com.
G.2.14 Domain Name Pointer Entry
The domain name pointer (PTR) entry allows special names to point to
some other location in the domain.
PTR names must be unique to the zone.
These
entries are located on a primary server in the
/etc/namedb/hosts.rev
file.
The following is the format of a PTR entry:
rev-addr ttl addr-class entry-type hostname
The fields in the PTR entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| rev-addr | This field specifies the reverse IP address of the host. For example, if the host's address is 128.11.22.33, the reverse address is 33.22.11.128.in-addr.arpa. This field also
supports IPv6 addresses.
An IPv6 address is represented in reverse order as
a sequence of 4-bit nibbles separated by dots with the suffix
|
| hostname | This is the fully qualified DNS name of the host, for example, miami.cities.dec.com. Be sure to include the period (.) at the end of the host name if the host is not in the current domain. |
The following is an example of two IPv4 PTR entries:
;rev-addr ttl addr-class entry-type hostname 33.22 IN PTR chicago 66.55.44.121.in-addr.arpa. IN PTR mail.peace.org.
In this example, the first entry is for a host whose IP host address
is 22.33 in the current domain.
The specified reverse address (33.22) is meaningful
assuming that a
$origin
entry exists.
See
Section G.2.2
for a description of the
$origin
entry.
If there is not
an
$origin
entry, then the entire IP address, in reverse,
must be specified.
The second entry is for a host in different domain (mail.peace.org.). As a rule, do not do this because you are putting data in your server's cache for which your server is not authoritative. PTR entries and other resource records are for hosts in your domain only. The PTR entry sets up a reverse pointer for the host mail.peace.org.
The following is an example of an IPv6 PTR entry:
;rev-addr ttl addr-class entry-type hostname $ORIGIN 0.0.7.a.f.e.f.f.f.8.f.0.0.2.0.0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int. d 3600 IN PTR equinox.ipv6.campus.edu.
In this example, the administrator uses the
$origin
entry to create a more organized resource record.
By specifying most of the
IPv6 address in the
$origin
entry, you can prevent the
PTR entry from wrapping over to the next line.
The forward IPv6 address for this entry is 3ffe:8050:201:1860:0200:f8ff:fefa:700d.
See
Network Administration: Connections
for more information about IPv6.
G.2.15 Start of Authority Entry
The start of authority (SOA) entry designates the beginning of a zone. There can be no more than one SOA entry per zone. The following is the format of an SOA entry:
name ttl addr-class entry-type origin person serial# refresh retry expire min
The fields in the SOA entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| origin | This field is the name of the host on which the data file resides. This is usually a master server. |
| person | This field defines the login name and mailing address of the person responsible for DNS running on the local domain. |
| serial# | This field specifies the version number of the data file. The person editing the master files for the zone must increment the value in this field each time a change is made to the data within the file. The serial number being changed informs the secondary servers that there is new data to be obtained from the master server. The maximum number is 232-1 after the decimal point. The serial number field allows DNS to determine which of two copies of data files in a zone are more recent. Typically, the serial number field begins at one (1) and is incremented by one each time the original data file is modified. It is best to use whole integers. |
| refresh | This field specifies how often, in seconds, a secondary DNS server is to check with the master server to see if it needs to update its data files. If the data files are out of date (as indicated by a mismatch of serial number fields), they are updated with the contents of the master server's files. The minimum refresh period is 30 seconds. If the refresh field is blank, however, the data file is not dynamically updated. |
| retry | This field specifies how often, in seconds, a secondary DNS server will try to refresh its data files after a refresh failure has occurred while making the check. If a DNS server attempts to refresh the files and fails, it tries to refresh them again every so many seconds, as specified in the retry field. |
| expire | This field specifies the upper limit, in seconds, that a secondary DNS server can use the data files in its cache before the data expires for lack of being updated, or before DNS server checks to see if its cache needs to be updated. |
| min | This field specifies the default time to live, in seconds, that a data entry can exist in the event that the ttl entry is left blank. |
The following is an example of an SOA entry. The first line is a comment that shows the fields:
;name ttl addr-class entry-type origin person
@ IN SOA utah.states.dec.com. hes.utah.states.dec.com. (
1 ; serial
3600 ; refresh every hr.
300 ; retry every 5 min.
3600000 ; expire in 1000 hrs.
86400 ) ; min. life is 24 hrs.
In this example note that the parentheses indicate to DNS that this is a single entry. The ttl field is blank, indicating that the default time to live specified in the min field (86400 seconds) is being used.
The semicolons allow comments for readability.
In the example, the serial
field is 1, the refresh field is 3600 seconds (once per hour), the retry field
is 300 seconds (once per 5 minutes), the expire field is 3,600,000 seconds
(1000 hours), and the min field is 86400 seconds (24 hours).
G.2.16 Location of Services Entry
The location of services (SRV) entry describes services supported in a particular target domain. It replaces the well-known services (WKS) entry, which is maintained for backwards compatibility. The following is the format of an SRV entry:
_service._protocol.name ttl addr-class entry-type priority weight target
The fields in the SRV entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| service | This case-insensitive field specifies
the symbolic name of the desired service.
You can select a service name from
the
/etc/services
file, or define a new, unique service
name locally.
You must prepend an underscore (_) to the service, for example,
_ldap, to prevent collisions with other DNS labels. |
| protocol | This case-insensitive field specifies
the symbolic name of the protocol to use.
You must prepend an underscore (_)
to the protocol, for example,
_TCP
or
_UDP,
to prevent collisions with other DNS labels. |
| name | This field specifies the domain to which this SRV record refers. As with other resource records, the name field can be left blank if the SRV record is inserted directly below records from the same domain. |
| priority | This field specifies the priority, a value from 0 to 65535, of the target system or server. Clients for the specified service attempt to contact the system with the lowest priority value. Systems with the same priority are tried in an order defined by the weight field. |
| weight | This field specifies the relative weight, a value from 0 to 65535, for entries that have the same priority value. Higher weight values are more likely to be selected. |
| port | This field specifies the port of the
service, a value from 0-65535, on the target server.
You can obtain
the port number from the
/etc/services
file, or define
a new, unique port number locally. |
| target | This is the fully qualified host name of the target system or server, for example, miami.cities.dec.com. One or more address records must exist for this host name, and the name must not be an alias. If you need to indicate that a service is definitely not available at this domain, specify a dot (.) for the target value. |
The following is an example of SRV entries:
;_service._protocol.name entry priority weight port target
_ldap._tcp SRV 0 1 389 whitepages2.crimson.com.
SRV 0 3 389 whitepages.crimson.com.
SRV 1 0 389 zeus.crimson.com.
In this example, the three SRV entries describe support for the Lightweight Directory Access Protocol (LDAP) in the crimson.com domain. The primary LDAP servers for the domain are whitepages and whitepages2. They share the same priority, but because whitepages is a newer and faster server, the administrator assigns a higher weight value to it. As a result, whitepages handles a majority of the directory queries for the domain.
If both primary LDAP servers are unavailable, clients switch to querying
the zeus server, which provides backup for various services in the domain.
G.2.17 Well Known Services Entry
The well known services entry (WKS) has been replaced by the Location of Services entry (SRV); however, WKS is maintained for backwards compatibility.
The WKS entry describes well known services supported by a particular
protocol at a specified address.
The services and port numbers are obtained
from the list of services specified in the
/etc/services
file.
The following is the format of a WKS entry:
name ttl addr-class entry-type address protocol services
The fields in the WKS entry have the values described in Section G.1, with the following exceptions:
| Field | Description |
| address | This field specifies the IP address for each system. There can be only one WKS entry for each protocol at each address. |
| protocol | This field specifies the protocol to be used, for example TCP or UDP. |
The following is an example of two WKS entries:
;name ttl addr-class entry-type address protocol services
IN WKS 128.32.0.4 UDP who route
IN WKS 128.32.0.78 TCP (echo talk
discard sunrpc sftp
uucp-path netstat host
systat daytime link
auth time ftp
nntp whois pop
finger smtp supdup
domain nameserver
chargen)
Note that the first and second fields of both entries in this example are blank, which indicates that they are using the domain name specified in a previous entry and the default ttl specified in the SOA entry or the $ttl entry. The services listed in the second entry are contained within parentheses and are thus interpreted as being one entry, even though they appear on several lines.