Solaris Naming Administration Guide

Data File Resource Record Format

All 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 Format

In 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:

namettl			class		record-type				record-specific-data

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 Field

The 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 Field

The 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 Field

The third field is the record class. Only one class is currently in use: IN for the TCP/IP protocol family.

The record-type Field

The 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 Field

The 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 may change in the future; thus, you should be consistent in your use of lower and uppercase.

Special Resource Record Characters

The following characters have special meanings:

Table 28-4 Special Resource Record Characters




A free-standing dot in the name field refers to the current domain. 


A free-standing @ in the name field denotes the current origin.


Two free-standing dots represent the null domain name of the root when used in the name field. 


Where X is any character other than a digit (0-9), quotes that character so that its special meaning does not apply. For example, you can use \. to place a dot character in a label.


Where each D is a digit, this 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.


Use parentheses to 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. 

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 may 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 Entries

The 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().


An 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:

$INCLUDE /etc/named/data/mailboxes

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. This is simply a way to allow 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 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 primary or secondary line of the named.conf file.

Resource Record Types

The most commonly used types of resource records are listed in Table 28-5. They are usually entered in the order shown in Table 28-5, but that is not a requirement.

Table 28-5 Commonly Used Resource Record Types




Start of authority 


Name server 

Internet address (name to address) 


Pointer (address to name) 


Canonical name (nickname) 


Text information 


Well-known services 


Host information 


Mail exchanger 

SOA-- Start of Authority

Example 28-2 shows the syntax of a start-of-authority (SOA) resource record.

Example 28-2 SOA Record Format

name class SOA origin person-in-charge ( serial number

The Start-Of-Authority record designates the start of a zone. The zone ends at the next SOA record. The SOA record fields are described below.


This field indicates the name of the zone. Note that the zone name must end with a trailing dot. For example: is correct, while is wrong.


This field is the address class. For example, IN for Internet (the most commonly used class).


This field is the type of this resource record.


This 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, is correct, but is wrong.


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


This field is the version number of this data file. You must increment this number whenever you make a change to the data: secondary 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.


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


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


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


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

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

Example 28-3 Sample SOA Resource Record

;name class 		SOA 	origin				 person-in-charge IN		SOA (
							101			;Serial
							7200		;Refresh
							3600		;Retry
							432000		;Expire	
							86400)		;Minimum			 )

NS--Name Server

Example 28-4 shows the syntax of a name-server (NS) resource record:

Example 28-4 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 primary and secondary master server for the domain. Example 28-5 is a sample NS resource record.

Example 28-5 Sample NS Resource Record

;domainname    [TTL] 	 class	NS	nameserver        90000     IN	NS


Example 28-6 shows the syntax of an address (A) resource record:

Example 28-6 Address Record Format

machinename	[optional TTL] class A	address

The address (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 28-7 Sample Address Record

;machinename	[TTL]	class	A	address
sirius		IN		A

HINFO--Host Information

Example 28-8 shows the syntax of a host-information (HINFO) resource record:

Example 28-8 HINFO Record Format

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

The host-information resource record (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 28-9 is a sample HINFO resource record.

Example 28-9 Sample HINFO Resource Record

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

Caution - 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.

WKS--Well-Known Services

Example 28-10 shows the syntax of a well-known services (WKS) resource record:

Example 28-10 WKS Record Format

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

The Well-Known Services (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 28-11 is an example of a WKS resource record.

Example 28-11 Sample WKS Resource Record

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

Caution - Caution -

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

CNAME--Canonical Name

Example 28-12 shows the syntax of a canonical-name (CNAME) resource record.

Example 28-12 CNAME Record Format

 nickname [optional TTL] class CNAME	canonical-name

The Canonical-Name Resource record (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 28-13 is a sample CNAME resource record.

Example 28-13 Sample CNAME Resource Record

;nickname      [TTL]	class	CNAME	canonical-name
mailhost		IN	CNAME

PTR--Pointer Record

Example 28-14 shows the syntax for a pointer (PTR) resource record.

Example 28-14 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, PTR's are used mainly in the 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 28-15 sets up reverse pointers for the special domain.

Example 28-15 Sample PTR Resource Record

;special name   [TTL]	class	PTR-real-name
1			IN	PTR

MX--Mail Exchanger

Example 28-16 shows the syntax for a mail-exchanger (MX) resource record.

Example 28-16 MX Record Format

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

The mail-exchanger resource records are used to specify a machine that knows how to deliver mail to a domain or specific machines in a domain. There may be more than one MX resource record for a given name. In Example 28-17, 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 may 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 may or may 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 simply state that any mail to a domain is to be routed through a relay. In Example 28-17, all mail to hosts in domain is routed through RELAY.CS.NET. You do this by creating a wildcard resource record, which states that the mail exchanger for * is RELAY.CS.NET. The asterisk will match any host or subdomain of, but it will not match itself.

Example 28-17 Sample MX Resource Record

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