named.hosts(4tcp)
named.hosts --
hosts database file
Synopsis
[$ORIGIN domain]
[$INCLUDE filename]
[name] [ttl] address_class record_type record_specific_data
...
Description
The named.hosts file on a primary server
contains the authoritative information for a zone.
This information consists of resource records for a zone
with records for the same host normally being grouped together.
The actual filename is arbitrary; it
must be specified by a primary
directive in named.boot
and, if not specified by an absolute pathname, must be located
relative to the directory specified by any directory
directive.
Format of resource records
Resource records have the following fields:
name-
The name of the record.
For all resource records except the first in a file,
the name is optional and can be left blank.
If not specified, the last specified name is used.
ttl-
Optional time-to-live field.
This specifies how long this data is stored in the database.
If left blank, the default time-to-live is specified
in the Start Of Authority (SOA) resource record.
address_class-
This field lists one of three classes:
IN-
Internet addresses.
HS-
A limited subset of MIT/Athena ``Hesiod'' data.
ANY-
All other address classes.
record_ type-
The type of this record, for example, NS.
record_specific_data-
Data that is dependent on the type of the resource record.
Case is preserved in name and data fields when loaded into the name server.
All comparisons and lookups in the name server database are case-insensitive.
Special resource record characters
These characters have special meanings in resource records:
.-
A free-standing dot in the name field refers to the current zone.
@-
A free-standing ``@'' in the name
field denotes the current origin.
You can use origins within configuration files as a shorthand for
fully qualified domain names.
..-
Two free-standing dots represent the null
domain name of the root when used in the name field.
\X-
``X'' is any character other than a digit (0-9).
``\X'' escapes the character so that its
special meaning does not apply.
For example, ``\.'' can be used to place a dot character in a label.
\DDD-
Each ``D'' is a digit.
``\DDD''
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.
()-
Parentheses 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. This is only meaningful for
some resource record types, notably MX, and then only in
the name field. Do not use an asterisk in the data field.
Anywhere a name appears, either in the name field or in a data field
defined to contained names, the current origin is appended if the name
does not end with a ``.''. This is useful for appending
the current zone name to the data, such as machine names, but can
cause problems when you do not want this to happen.
The following rule
helps avoid this problem: if the name is not in the zone for which
you are creating the data file, end the name with a ``.''.
Changing the origin
Use the $ORIGIN statement to change the domain origin in a data file.
The line starts in column 1 and is followed by a domain origin.
This is useful for putting more than one domain in a data file.
Only use $ORIGIN to change domains within a particular zone.
For example, you might change domains to a subdomain within the current
zone. For example:
$ORIGIN mynet.COM
[assorted domain data...]
$ORIGIN sub.mynet.COM
[more domain data...]
Separating data into multiple files
The $INCLUDE statement allows data for a given zone to be separated
into multiple files. For example, mailbox data might be kept separate
from host data by including this line in a resource record:
$INCLUDE /usr/named/data/mailboxes
The line is interpreted as a request to load the file
/usr/named/data/mailboxes.
Additionally, you may append a temporary $ORIGIN to use while
the file is read. For example:
$INCLUDE /usr/named/data/mail-exchangers $ORIGIN mynet.COM
The inclusion of the new origin will not cause data to branch into
another zone. Only the boot file can introduce or redefine zone boundaries.
Required records for a zone
The records A, NS, and SOA are
required for the normal operation of a zone.
It is normally convenient to move the
SOA and NS records to a separate
named.soa(4tcp)
file for each zone.
In this case, you would include the
directive $INCLUDE named.soa in the
named.hosts file.
A (address)
A records list the addresses of a given machine.
The name field is the machine name and the address is the
network address.
There should be one A record for the addresses of every machine
in a zone.
Here is an example of an address record for a machine named
volga which has two network addresses:
;{name} {ttl} addr-class A address
volga IN A 172.16.118.1
IN A 172.16.246.1
NS (name server)
NS lists a name server responsible for a given zone.
The first name field lists the zone that is serviced by
the listed name server.
There should be one NS record for each name
server for the zone, and every zone should have at least two
name servers, preferably on separate networks. Here is an
example of a name server record:
;{name} {ttl} addr-class NS Name servers name
@ IN NS volga.mynet.COM.
The ``@'' character specifies the current origin.
The address class is IN (Internet addresses),
and the record type is name server (NS).
The record uses the default time-to-live (ttl) value.
Here, the record-specific data is the identity of the name server.
SOA (start of authority)
The SOA record designates the start of a zone
and must appear at the beginning of every DNS
hosts file.
The record_specific_data in a
SOA record must include the following information:
Origin-
Name of the host on which this data file resides.
Person in charge-
Mailing address for the person responsible for the name server.
Serial number-
Version number of this data file;
this number should be incremented whenever a change is made to the zone data.
Using a decimal point in the serial number is not recommended.
Refresh time-
How often, in seconds, a secondary name server
must check with the primary name server to see if an update is needed.
Retry time-
How long, in seconds, a secondary server should wait before retrying
a failed zone transfer.
Expiry time-
Upper time limit, in seconds, that a secondary name server
can use the data before it expires for lack of getting a refresh.
Minimum time-to-live-
Default time-to-live in seconds for
resource records that do not specify
a time-to-live value in the zone file.
There should only be one SOA record per zone.
Here is an example of an SOA record:
;name {ttl} addr-class SOA Origin Person in charge
@ IN SOA volga.mynet.COM. dave.mynet.COM (
1993041403 ; Serial number
3600 ; Refresh time
300 ; Retry time
3600000 ; Expiry time
259200 ) ; Minimum time-to-live
The minimum time-to-live assigned to records and to the zone is
very important. A high value leads to low network traffic and fast
response time, while lower values generate additional traffic but allow
faster propagation of changes.
A general guideline is to set the minimum time-to-live
to three days (259200 seconds).
If your zone is very stable, consider setting the value even higher.
If you need to propagate changes more quickly, reduce the minimum
time-to-live value several days before making the changes,
then restore its previous value after making the changes.
Only changes and deletions are affected by the minimum time-to-live;
additions are governed by the refresh time.
Optional records
AFSDB (DCE or AFS server)
AFSDB records specify the hosts that provide a style of
distributed service advertised under this domain name. A subtype value
(analogous to the ``preference'' value in the MX record) indicates
which style of distributed service is provided with the given name.
Subtype 1 indicates that the named host is an AFS®
database server for the AFS cell of the given domain name.
Subtype 2 indicates that the named host provides intra-cell
name service for the DCE®
cell named by the given domain name.
Here is an example AFSDB record:
name {ttl} addr-class AFSDB subtype mail exchanger
mynet.COM. IN AFSDB 1 missouri.mynet.COM.
mynet.COM. IN AFSDB 1 yukon.mynet.COM.
mynet.COM. IN AFSDB 2 nile.mynet.COM.
In the example above, missouri.mynet.COM and
yukon.mynet.COM are declared to be AFS database
servers for the mynet.COM AFS cell, so that AFS clients
wishing service from nile.COM
are directed to those two hosts
for further information. The third record declares that
nile.mynet.COM houses a directory server for the
root of the DCE cell mynet.COM, so that DCE
clients that wish to refer to DCE services should consult with
the host nile.mynet.COM for further information. The
DCE subtype of record is usually accompanied by
a TXT record for other information specifying other
details to be used in accessing the
DCE cell. RFC 1183 contains more detailed
information on the use of this record type.
The AFSDB record is still experimental;
not all name servers implement or recognize it.
CNAME (canonical name)
CNAME specifies an
alias or nickname for the official, or canonical, name.
An alias should be the only record associated with the alias;
all other resource records should be
associated with the canonical name and not with the alias.
Any resource records that include a zone name as their value (for
example,
NS or MX) must list the canonical name, not the alias.
This resource record is especially useful when changing machine names.
In this instance, create a CNAME record with the old name
until users are accustomed to using the new name.
Here is an example of a CNAME record:
;aliases {ttl} addr-class CNAME Canonical name
volga-cities IN CNAME volga
HINFO (host information)
HINFO records contain host-specific data.
They list the hardware and operating system that are running at
the listed host.
If you want to include a space in the machine name,
you must quote the name.
Host information is not specific to any address class,
so ANY may be used for the address class.
There should be one HINFO record for each host.
For security reasons, many sites do not include the HINFO
record, and no applications depend on this record.
Here is an example:
;{name} {ttl} addr-class HINFO Hardware OS
ANY HINFO Intel i486 UNIX
MB (mailbox)
MB lists the machine where a user wants to receive mail.
The name field is the user's login; the machine field denotes the machine
to which mail is to be delivered.
Mail box names should be unique to the zone. Here is an example of
an MB record:
;name {ttl} addr-class MB Machine
carol IN MB yukon.mynet.COM.
MG (mail group member)
The mail group record (MG) lists members of a mail group:
;{mail group name} {ttl} addr-class MG member name
IN MG Bloom
An example for setting up a mailing list is as follows:
Bind IN MINFO Bind-Request dave.mynet.COM.
IN MG mark.mynet.COM.
IN MG vicki.mynet.COM.
IN MG naomi.mynet.COM.
IN MG carol.mynet.COM.
IN MG denis.mynet.COM.
MINFO (mailbox information)
MINFO creates a mail group for a mailing list.
This resource record is usually associated with a mail group,
but it can be used with a mailbox record.
The ``name'' specifies the name of the mailbox.
The ``requests'' field
is where mail such as requests to be added to a mail group should be sent.
The ``maintainer'' is a mailbox that should receive error messages.
This is particularly appropriate for mailing lists when
errors in members' names should be reported to a person other than
the sender. Here is an example of this record:
;name {ttl} addr-class MINFO requests maintainer
Bind IN MINFO BIND-REQUEST dave.mynet.COM
MR (mail rename)
MR records list aliases for a user.
The name field lists the alias for the name listed in the fourth field,
which should have a corresponding MB record. Here is an
example of a mail rename record:
;name {ttl} addr-class MR corresponding MB
Postmaster IN MR carol
MX (mail exchanger)
MX records specify a list of
hosts that are configured to receive mail sent to this domain name.
Every host that receives mail should have an MX record, since
if one is not found at the time the mail is delivered, an MX value
will be imputed with a cost of 0 and a destination of the host itself.
In the following example, Seismo.CSS.GOV
is a mail gateway that knows how to deliver mail
to Munnari.OZ.AU. These two machines may have a
private connection or use a different transport medium. The preference
value is the order that a mailer should follow when there is more than
one way to deliver mail to a single machine. Lower numbers indicate
higher precedence, and mailers are supposed to randomize same-valued
MX hosts so as to distribute the load evenly if the costs are
equal. See RFC 974 for more detailed information.
Here is an example MX record:
;name {ttl} addr-class MX preference value mailer exchanger
Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV.
.IL. IN MX 0 RELAY.CS.NET.
In the second example, all mail to hosts in
the domain IL is routed through RELAY.CS.NET.
This is done by creating a wildcard resource record,
which states that .IL has an MX
of RELAY.CS.NET.
Wildcards are often not an optimal solution, because MX records must
appear the same both inside and outside a given domain. Therefore, if
you want to use mail exchangers within your domain, do not use a top-level
wildcard. Instead, create specific MX records for each of
the machines in your domain.
PTR (domain name pointer)
PTR records allow hostnames to be looked up from
IP addresses.
PTR records are needed by
gethostbyaddr(3N).
PTR names should be unique to the zone.
The following example of a PTR record
is used in setting up reverse pointers
for the localhost in the
0.0.127.IN-ADDR.ARPA domain:
;name {ttl} addr-class PTR real_name
1.0.0.127.in-addr.arpa. IN PTR localhost.
Note the trailing ''.''s which prevent the appending of the current
$ORIGIN.
This entry can be shortened by letting the current origin be appended:
;name {ttl} addr-class PTR real_name
1 IN PTR localhost.
The following example is for the 16.172.IN-ADDR.ARPA
domain:
;name {ttl} addr-class PTR real_name
3.118 IN PTR thames.mynet.COM.
In this record, the name field is the network
number of the host in reverse order. You only need to specify enough
octets to make the name unique within a zone.
For example, if all hosts in a zone are on network
172.16.118, then only the last octet needs to be specified.
If hosts can be on either the 172.16.118 or 172.16.246 networks
within a zone, then the last two octets need to be specified.
PX (pointer to X.400/RFC 822 mapping information
PX records specify rules for mapping between X.400 O/R and
RFC 822 mail addresses. See RFC 1327 for information
about the mapping process and see RFC 1664 for how to specify an
X.400 domain in DNS syntax.
The following PX record maps X.400 to RFC 822
(``table 1 rules'' in RFC 1327):
;name {ttl} addr-class PX prefer 822-dom X.400-dom
.ADMD-garr.X42D.it IN PX 50 it. ADMD-garr.C-it
The following PX record maps RFC 822 to X.400
(``table 2 rules'' in RFC 1327):
;name {ttl} addr-class PX prefer 822-dom X.400-dom
.nfn.it IN PX 50 infn.it. O.PRMD-infn.ADMD-garr.C-it
The following PX record encodes RFC 822 as X.400
(``gate table'' in RFC 1327):
;name {ttl} addr-class PX prefer 822-dom X.400-dom
.it IN PX 50 it. O-gate.PRMD-garr.ADMD-garr.C-it
It is recommended to use ``name'' values that contain wildcards
to maintain compatibility with existing
services that use static RFC 1327 tables.
The preference field (``prefer'') works in a similar way to
that in MX records; a value of 50 is recommended.
``822-dom'' provides the mapping rule for RFC 822.
``X.400-dom'' provides the mapping rule for X.400 in
DNS format.
To specify mapping rules from X.400 to RFC 822 syntax,
an appropriate X.400 domain tree must be created in DNS
including specific SOA and NS records for the domain
itself. The mapping rules from RFC 822 to X.400 can be
embedded directly into the ``name'' tree. See RFC 1664 for
details of the organization of this structure and of how to use PX
records. Take care in coordinating DNS mapping information with
the same information specified in RFC 1327 tables.
The PX record is still experimental;
not all name servers implement or recognize it.
RP (responsible person)
RP identifies the name (or group name) of the
responsible person(s) for a host. This information is useful in
troubleshooting problems over the network. Here is an example:
;owner {ttl} addr-class RP mbox-domain-name TXT-domain-name
dave IN RP dave.mynet.COM sysadmins.mynet.COM
The mbox-domain-name field contains the mailbox address for the
responsible person. The address is specified following the standard
DNS convention, with the mailbox name prepended to the domain name. A
period (.) indicates that no mailbox is available.
The TXT-domain-name field indicates a domain in
which TXT records exist. Subsequent searches can
retrieve the records from the TXT domain. In the
example, sysadmins.mynet.COM is the name
of a TXT record that might
contain the names and phone numbers of system administrators.
The RP record is class-insensitive,
and multiple records for a single name
may appear in the database. If multiple records exist, they should
have identical time-to-live values.
Not all name servers implement or recognize the RP record
at this time.
TXT (text)
A TXT record contains free-form textual data. The syntax of the
text depends upon the domain in which it appears; several systems use
TXT records to encode user databases and other administrative data.
;name {ttl} addr-class TXT string
yukon.mynet.COM IN TXT "free-form text"
This functionality is not widely used on the Internet.
WKS (well-known services)
WKS records
describe the well-known services
supported by a particular protocol at a specified address.
The list of services and
port numbers comes from the list of services
specified in /etc/services.
There should be only one WKS record per protocol per address.
Because the WKS record is not widely used throughout the
Internet, applications should not rely on the existence of this record
to determine the presence or absence of a service. Instead, the application
should simply attempt to use the service.
Here is an example of a WKS record:
;{name} {ttl} addr-class WKS address protocol list of services
IN WKS 172.16.118.1 UDP echo tftp time
IN WKS 172.16.118.1 TCP (telnet discard
sunrpc sftp
uucp-path systat
netstat qotd nntp
link chargen ftp
auth whois mtp
pop rje finger smtp
supdup hostnames
domain
name server)
Secure zones
Secure zones implement named security on a zone by zone basis.
Networks or hosts on a permitted list may obtain particular
information from a secure zone. To use zone security, at least one
``secure_zone'' TXT resource record must exist for the
zone. No restrictions will otherwise be applied to the zone's data. The
format of the ``secure_zone'' TXT resource record is:
secure_zone addr-class TXT net_address[:netmask]|host_address:H
addr-class is either IN (Internet) or HS
(Hesiod). net_address[:netmask] allows queries from the
specified network address. The default network mask for the address will be
used if netmask is omitted. host_address:H
allows queries from a specified host IP address.
Multiple secure_zone TXT records may be specified for a zone.
In this example, the zone will only answer Internet requests
from the local loopback interface 127.0.0.1,
from the class B network 148.151.0.0,
from the class C subnetted class B network 148.152.7.0,
and from host 148.152.1.1:
secure_zone IN TXT 127.0.0.1:H
secure_zone IN TXT 148.151.0.0
secure_zone IN TXT 148.152.7.0:255.255.255.0
secure_zone IN TXT 148.152.1.1:H
The loopback interface is included so that a local client can resolve
names.
Secure zones can be used to restrict access to Hesiod password maps, or to
separate internal and external internet address resolution on a firewall
machine without the need to run a separate named process for
internal and external address resolution.
Files
/etc/inet/named.d/db.zone-
suggested name for hosts database file
References
named(1Mtcp),
named.boot(4tcp),
named.local(4tcp),
named.rev(4tcp),
named.soa(4tcp),
root.cache(4tcp)
Standard Resource Record Format in RFC 1035
© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 25 April 2004