The person-in-charge Field

This field is the email address of the person responsible for the name server. For example, kjd.nismaster.doc.com. Again, this name must end with a trailing dot.

The serial Field

This field is the version number of this data file. You must increment this number whenever you make a change to the data: slave servers use the serial field to detect whether the data file has been changed since the last time they copied the file from the master server.

The refresh Field

This field indicates how often, in seconds, a slave name server should check with the master name server to see if an update is needed. For example, 7200 indicates a period of two hours.

The retry Field

This field indicates how long, in seconds, a slave server is to retry after a failure to check for a refresh.

The expire Field

This field is the upper limit, in seconds, that a slave name server is to use the data before it expires for lack of getting a refresh.

The ttl Field

This field is the default number of seconds to be used for the time-to-live field on resource records that do not have a ttl specified elsewhere.

There should only be one SOA record per zone. Example 5-20 is a sample SOA resource record.

Example 5-20 Sample SOA Resource Record

;name class 		SOA 	origin				 person-in-charge
doc.com. IN		SOA	dnsmaster.doc.com. root.nismaster.doc.com. (
							101			;Serial
							7200		;Refresh
							3600		;Retry
							432000		;Expire	
							86400)		;Minimum			 )

Name Server (NS)

The Example 5-21 example shows the syntax of a name-server (NS) resource record.

Example 5-21 NS Record Format

domainname [optional TTL] class NS name-server-name

The name-server record lists by name a server responsible for a given domain. The name field lists the domain that is serviced by the listed name server. If no name field is listed, then it defaults to the last name listed. One NS record should exist for each master and slave server for the domain. Example 5-22 is a sample NS resource record.

Example 5-22 Sample NS Resource Record

;domainname    [TTL] 	 class	NS	nameserver
doc.com        90000     IN	NS 	sirius.doc.com.

Address (A)

The Example 5-23 example shows the syntax of an address (A) resource record.

Example 5-23 Address Record Format

	machinename	[optional TTL] class A	address

The A record lists the address for a given machine. The name field is the host name, and the address is the IP address. One A record should exist for each address of the machine (in other words, routers, or gateways require at least two entries, a separate entry including the IP address assigned to each network interface).

Example 5-24 Sample Address Record

;machinename	[TTL]	class	A	address
sirius		IN		A	123.45.6.1

Host Information (HINFO)

The Example 5-25 example shows the syntax of a host-information (HINFO) resource record.

Example 5-25 HINFO Record Format

[optional name] [optional TTL] 	class	HINFO hardware	OS

The HINFO contains host-specific data. It lists the hardware and operating environment that are running at the listed host. If you want to include a space in the machine name or in the entry in the hardware field, you must surround the entry with quotes. The name field specifies the name of the host. If no name is specified, it defaults to the last in.named host. One HINFO record should exist for each host. Example 5-26 is a sample HINFO resource record.

Example 5-26 Sample HINFO Resource Record

;[name]   [TTL] class HINFO   hardware    OS
                IN    HINFO   Sparc-10    UNIX

Caution - Because the HINFO field provides information about the machines on your network, many sites consider it a security risk and no longer use it.

Well-Known Services (WKS)

The Example 5-27 example shows the syntax of a well-known services (WKS) resource record.

Example 5-27 WKS Record Format

[Optional name] [TTL] class WKS address protocol-list-of-services

The WKS record describes the well-known services supported by a particular protocol at a specified address. The list of services and port numbers come from the list of services specified in the services database. Only one WKS record should exist per protocol per address. Example 5-28 is an example of a WKS resource record.

Example 5-28 Sample WKS Resource Record

;[name]	[TTL]	class	WKS	address 	 protocol-list-of-services
altair		IN	WKS	123.45.6.1	 TCP ( smtp discard rpc
 sftp uucp-path systat daytime
 netstat qotd nntp doc.com )

Caution - The WKS record is optional. For security reasons, most sites no longer provide this information.

Canonical Name (CNAME)

Example 5-29 shows the syntax of a canonical-name (CNAME) resource record.

Example 5-29 CNAME Record Format

 nickname [optional TTL] class CNAME	canonical-name

The CNAME specifies a nickname or alias for a canonical name. A nickname should be unique. All other resource records should be associated with the canonical name and not with the nickname. Do not create a nickname and then use it in other resource records. Nicknames are particularly useful during a transition period, when a machine's name has changed but you want to permit people using the old name to reach the machine. Nicknames can also be used to identify machines that serve some specific purpose such as a mail server. Example 5-30 is a sample CNAME resource record.

Example 5-30 Sample CNAME Resource Record

;nickname      [TTL]	class	CNAME	canonical-name
mailhost		IN	CNAME	antares.doc.com

Pointer Record (PTR)

Example 5-31 shows the syntax for a PTR resource record.

Example 5-31 PTR Record Format

 special-name	[optional TTL]  class	 PTR-real-name

A pointer record allows special names to point to some other location in the domain. In the example, PTRs are used mainly in the in-addr.arpa. records for the translation of an address (the special name) to a real name. When translating an address, if the domain is fully qualified only the machine identification number need be specified. PTR names should be unique to the zone. The PTR records Example 5-32 sets up reverse pointers for the special in-addr.arpa domain.

Example 5-32 Sample PTR Resource Record

;special name   [TTL]	class	PTR-real-name
1			IN	PTR sirius.doc.com.

Mail Exchanger (MX)

Example 5-33 shows the syntax for a mail-exchanger (MX) resource record.

Example 5-33 MX Record Format

name [optional TTL] class	MX preference-value mailer-exchanger

The MX resource records are used to specify a machine that knows how to deliver mail to a domain or specific machines in a domain. There might be more than one MX resource record for a given name. In Example 5-34, Seismo.CSS.GOV. (note the fully qualified domain name) is a mail gateway that knows how to deliver mail to Munnari.OZ.AU. Other machines on the network cannot deliver mail directly to Munnari. Seismo and Munnari might have a private connection or use a different transport medium. The preference-value field indicates the order a mailer should follow when there is more than one way to deliver mail to a single machine. The value 0 (zero) indicates the highest preference. If there is more than one MX resource record for the same name, records might or might not have the same preference value.

You can use names with the wildcard asterisk (*) for mail routing with MX records. There are likely to be servers on the network that state that any mail to a domain is to be routed through a relay. In Example 5-34, all mail to hosts in domain foo.com is routed through RELAY.CS.NET. You do this by creating a wildcard resource record, which states that the mail exchanger for *.foo.com is RELAY.CS.NET. The asterisk will match any host or subdomain of foo.com, but it will not match foo.com itself.

Example 5-34 Sample MX Resource Record

;name	 	[TTL]	class		MX	 preference mailer-exchanger
Munnari.OZ.AU.		IN		MX	 0	Seismo.CSS.GOV.
foo.com.		IN		MX	 10	RELAY.CS.NET.
*.foo.com.		IN		MX	 20	RELAY.CS.NET.