DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

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