The most commonly used types of resource records are listed in Table 27-4. They are usually entered in the order shown in Table 27-4, but that is not a requirement.
Table 27-4 Commonly Used Resource Record Types
Type |
Description |
---|---|
SOA |
Start of authority |
NS |
Name server |
A |
Internet address (name to address) |
PTR |
Pointer (address to name) |
CNAME |
Canonical name (nickname) |
TXT |
Text information |
WKS |
Well-known services |
HINFO |
Host information |
MX |
Mail exchanger |
Example 27-1 shows the syntax of a start-of-authority (SOA) resource record.
name class SOA origin person-in-charge ( serial number refresh retry expire ttl) |
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: doc.com. is correct, while doc.com 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, dnsmaster.doc.com. is correct, but dnsmaster.doc.com is wrong.
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.
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 27-2 is a 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 ) |
Example 27-3 shows the syntax of a name-server (NS) resource record:
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 27-4 is a sample NS resource record.
;domainname [TTL] class NS nameserver doc.com 90000 IN NS sirius.doc.com. |
Example 27-5 shows the syntax of an address (A) resource record:
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).
;machinename [TTL] class A address sirius IN A 123.45.6.1 |
Example 27-7 shows the syntax of a host-information (HINFO) resource record:
[optional name] [optional TTL] class HINFO hardware OS |
The host-information resource record (HINFO) contains host-specific data. It lists the hardware and operating system 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 27-8 is a sample HINFO resource record.
;[name] [TTL] class HINFO hardware OS IN HINFO Sparc-10 UNIX |
Because the HINFO field provides information about the machines on your network, many sites consider it a security risk and no longer use it.
Example 27-9 shows the syntax of a well-known services (WKS) resource record:
[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 27-10is an example of a 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 ) |
The WKS record is optional. For security reasons, most sites no longer provide this information.
Example 27-11 shows the syntax of a canonical-name (CNAME) resource record.
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 27-12is a sample CNAME resource record.
;nickname [TTL] class CNAME canonical-name mailhost IN CNAME antares.doc.com |
Example 27-13 shows the syntax for a pointer (PTR) resource record.
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 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 27-14sets up reverse pointers for the special in-addr.arpa domain.
;special name [TTL] class PTR-real-name 1 IN PTR sirius.doc.com. |
Example 27-15 shows the syntax for a mail-exchanger (MX) resource record.
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 27-16, 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 27-16, 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.
;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. |