The Start of Authority (SOA) record marks the beginning of a zone, and it is usually the first record in a zone file. Each zone has only one SOA record. All of the records that follow are part of the zone declared by the SOA. The SOA record defines parameters for the entire zone.

Unlike the other resource records, the SOA record cannot be created through the New Resource Record dialog. The New Zone Wizard creates the SOA record when a new primary zone is created. However, the values in the SOA record can be modified later through the Start of Authority (SOA) tab of the zone properties dialog, as described in Chapter 6.

The format of the SOA record is:

               zone [ttl] IN SOA origin contact (
 serial
 refresh
 retry
 expire
 minimum
 )

The components of the SOA record in the zone file are:

A sample SOA record for the example.com domain is:

@    IN    SOA        mandy.example.com. Administrator.example.com. (
                      9                   ; serial
                      43200               ; refresh twice a day
                      1800                ; retry every half hour
                      604800              ; expire after one week
                      1800                ; default ttl half an hour )

This SOA record says that mandy is the master server for this zone and that the person responsible for this zone can be reached at the email address [email protected]. The SOA serial number indicates the cached zone has been updated fewer than 10 times. The SOA tells the slave servers to check the zone for changes twice a day and to retry every half hour if they don’t get an answer. If they retry for a week and never get an answer, they should discard the data for this zone. Finally, if an RR in this zone does not have an explicit TTL, the TTL of the RR will default to 30 minutes.

Name Server (NS ) resource records identify the authoritative servers for a zone. These records are the pointers that link the domain hierarchy together. NS records in the top-level domains point to the servers for the second-level domains, which in turn contain NS records that point to the servers for their subdomains. Name server records pointing to the servers for subordinate domains are required for those domains to be accessible. Without NS records, the servers for a domain would be unknown. NS records are so important that they are created by the New Zone Wizard whenever a primary zone is created. However, the list of NS records associated with the zone can be modified through the Name Servers tab of the zone properties dialog, as described in Chapter 6. The syntax of the NS RR, as it appears in a zone file, is domain [ttl] IN NS server, where:

The majority of the resource records in a forward lookup zone file are address records . Address records are used to convert hostnames to IP addresses, which is the most common use of the DNS database. Figure C-1 shows the address record dialog box used to create A records via the DNS console.

Figure C-1. The address record dialog box

Enter the hostname and the IP address in the dialog box to add an address record to the zone. The A record added to the zone file contains the following fields (host [ttl] IN A address):

A glue record is a special type of address record. Most address records refer to hosts within the zone, but sometimes an address record needs to refer to a host in a subordinate zone. Recall that the NS record for a subdomain server identifies the server by name. An address is needed to communicate with that server, so an A record must also be provided when a subdomain is delegated its own zone. The address record and the name server record combine to link the domains together—thus the term glue record. Chapter 6 describes glue records in the discussion of how to delegate a subdomain.

The mail exchanger (MX ) record redirects mail to a mail server. It can redirect mail for an individual computer or an entire domain. MX records are extremely useful because most domains contain many systems that don’t run mail server software and many systems that are offline for part of every day. MX records redirect mail addressed to those systems to reliable servers that run mail server software. Figure C-2 shows the dialog used to add an MX record to the zone.

Figure C-2. The MX dialog box

Use the dialog box to define the name, preference, and server fields of the MX record. The mail server name and the priority assigned to that server are filled in Figure C-2, but the name field, which is taken from the “Host or child domain” box, is left blank. A blank name field means that this MX record is being defined for the current zone. In effect, this defines a mail server for the entire domain. The format of the MX RR in the zone file is [name] [ttl] IN MX preference server:

Here is how MX records work. If a remote system has mail to send to a host, it requests the host’s MX records. DNS returns all of the MX records for the specified host. The remote server chooses the MX with the lowest preference value and attempts to deliver the mail to that server. If it cannot connect to that server, it tries each of the remaining servers in preference order until it can deliver the mail. If no MX records are returned by DNS, the remote server delivers the mail directly to the host to which the mail is addressed. MX records only define how to redirect mail. The remote system and the mail server perform all of the processing that actually delivers the mail.

The Canonical Name (CNAME ) resource record defines an alias for the official name of a host. The CNAME record provides a facility similar to nicknames in the host table. The facility provides alternate hostnames for the convenience of users, such as www for web servers, ns for name servers, and smtp for email servers. Figure C-3 shows the dialog box used to add CNAME records to the zone file.

Figure C-3. The CNAME dialog box

Use the dialog box to enter the alias of the host as well as the canonical name of the host. The format of the CNAME record that the dialog inserts into the zone file is alias [ttl] IN CNAME hostname:

One important thing to remember about the CNAME record is that all other resource records must be associated with the official hostname, and not with the alias. This means that the alias cannot appear in the name field of any other resource record. For example:

www       IN   MX      5 jamis.example.com.

Assume that www is an alias assign, as shown in Figure C-3. In that case, the MX record in this example is illegal because it contains an alias in the name field. The DNS console will not let you make this mistake. Trying to create the MX record shown above using the DNS console generates the error shown in Figure C-4.

Figure C-4. MX record creation error

The Domain Name Pointer (PTR ) resource record is used to convert a numeric IP address to a hostname. This is the opposite of what is done by the address record, which converts a hostname to an address. PTR records are used to construct the in-addr.arpa reverse domain files.

Don’t ignore the reverse domain even if name service appears to run fine without it. Programs use the reverse domain to map IP addresses to hostnames when displaying information messages that include IP addresses. Some service providers use reverse domains to track who is using their service, and if they cannot map an IP address back to a hostname, they reject the connection.

The DNS console lets you keep the reverse domain updated automatically. Notice the “Update associated pointer (PTR) record” checkbox on the address dialog shown in Figure C-1. When that box is checked, the DNS console adds a PTR record to the reverse lookup zone when the A record is added to the forward lookup file. PTR records can also be added to the reverse lookup zone using the Pointer (PTR) dialog shown in Figure C-5.

Figure C-5. The Pointer (PTR) dialog box

Use the dialog box to define the IP address that appears in the name field of the PTR record and the hostname that appears in the data field. The format of the PTR record in the zone file is name [ttl] IN PTR hostname:

The Service Location record, which is defined in RFC 2052, provides a standardized way to locate network servers. Generic names such as www.example.org and ftp.example.org are widely used to locate network servers, but these names are not really a standard. The SRV record provides a standard convention for creating generic server names and it adds features for server selection and load balancing. SRV records are used extensively in AD integrated DNS, which is covered in Chapter 7. The format of the SRV record is:

_service._protocol.name [ttl] IN SRV priority weight port server

The name field of the SRV record has a unique _ service ._ protocol . name format. Dots are used to separate the components in the name field just as there are in any domain name. The underscore characters (_) are used to prevent the service name and the protocol name from colliding with real domain names. service is the name of the offered service as listed in the %SystemRoot%system32etcservices file. protocol is either _tcp or _udp depending on which transport protocol is associated with the specified service. name is a standard host or domain name that would be found in any name field. Using these criteria, the name that could be used to find the FTP servers for the example.org domain would be _ftp._tcp.example.org. A correctly formatted name is built by selecting a service from the Service drop-down list and a protocol from the Protocol drop-down list in the Service Location (SRV) dialog box.

The data field of the SRV record contains four values:

Figure C-6 shows the dialog box used to add a SRV record to the zone.

Figure C-6. The Service Location (SRV) dialog box

The SRV service and protocol values are selected from drop-down lists. When a service value is selected, the correct port value for that service appears in the “Port number” box. In this example, a priority of 10 was selected to simplify adding other FTP servers in the future. (10 allows for future servers to be easily added with lower or higher priority numbers.) A base weight value of 1 was used even though there are no other FTP servers defined at this time. These values can be easily changed in the future if necessary.

The dialog shown in Figure C-6 creates the following zone file entry:

_ftp._tcp               SRV     10 1 21 jamis.example.com.

It is easy to see how the values in the dialog box map to the finished resource record.

This concludes our short tour of the basic resource records. There are several more resource records that can be defined in the DNS console than those already covered. Those other RRs are described in the next section However, the few resource records described in this section make up the bulk of most zone files.

The experimental AFSDB record points to the server for an AFS or DCE cell. AFS, originally called the Andrew File System, is a distributed filesystem that is optimized for use over wide area networks (WANs). DCE, the Distributed Computing Environment, is just that, a standard that describes the interactions between computers in a distributed computing environment. AFS and DCE systems use DNS to point to their servers. They do this by using cell names that are compatible with DNS domain names. The AFSDB record maps the cell name to the correct server. The format of an AFSDB record is:

               cell_name [ttl] IN AFSDB type server

The cell_name looks just like a domain name and, in fact, is often the name of the current domain. The Microsoft DNS server defaults to using the current domain name unless a specific name is entered in the AFS Database (AFSDB) dialog. The type field, which is correctly set in the dialog by simply clicking a button, contains a 1 if the server is an AFS server or a 2 if it is a DCE server. The server field contains the DNS domain name of the AFS or DCE server. The AFSDB record is defined in RFC 1183.

The ATMA record maps a hostname to an Asynchronous Transfer Mode (ATM) address. ATM is a high-speed fiber optic network technology. It transmits small chunks of information that are only 53 bytes long to make it easier to optimize support for real-time traffic such as voice or video. The ATMA record was not standardized in an RFC. Instead, it is standardized by the ATM Forum in ATM Name System Specification Version 1.0. The format of the ATMA record is:

               name [ttl] IN ATMA atm_address

name is the hostname to which the ATM address is assigned; atm_address is the ATM address written in either the E.164 international telephone standard format or in the ISO NSAP (network service access point) standard format. When the hostname and ATM address are entered in the ATM Address (ATMA) dialog box, either the E.164 address button or the NSAP address button must be selected to indicate the format you used to enter the address.

The Host Information record provides a short description of the hardware and operating system used by a host. RFC 1035 defines the HINFO record. The format of the HINFO record is:

               host [ttl] IN HINFO hardware software

Originally, the hardware and software items in the data field were supposed to come from an official list of hardware and software registered in RFC 1700, Assigned Numbers. That might have worked in the days of mainframes when computer models changed slowly, but it wouldn’t work today. Administrators who use this record simply make up descriptive entries for the hardware and software and enter those in the “CPU type” box and the “Operating system” box of the Host Information (HINFO) dialog.

Adding this record to the zone file is generally discouraged because it can provide information to network intruders and has no particular use.

The AAAA record maps a domain name to an Internet Protocol Version 6 (IPv6) address. The AAAA record is defined in RFC 3596, DNS Extensions to Support IP Version 6. The format of the AAAA record is:

               name [ttl] IN AAAA ipv6_address

The format is the same as an A record except that the address provided in the data field is a 128-bit IPv6 address instead of a 32-bit IPv4 address. Instead of the dotted decimal notation used to write an IPv4 address, an IPv6 address is written as eight, 16-bit hexadecimal numbers separated by colons, as follows:

big6 IN AAAA 1234:a:b:c:d:e:f:9876

The traditional PTR record is used to map IPv6 addresses back to domain names. A new top-level reverse-mapping domain was created called ip6.int. When IPv6 addresses are converted to names in the reverse-mapping domain, they are reversed and written out as 32, four-bit nibbles separated by dots. Thus, the IPv6 address 1234:a:b:c:d:e:f:9876 becomes:

6.7.8.9.f.0.0.0.e.0.0.0.d.0.0.0.c.0.0.0.b.0.0.0.a.0.0.0.4.3.2.1.ip6.int.

Only systems that use IPv6 are assigned IPv6 addresses, and only systems that run the IPv6 protocol stack need to lookup AAAA records. Unless you run IPv6 on your network you won’t use this record.

The experimental ISDN record maps a domain name to an ISDN address. Integrated Services Digital Network (ISDN) is a digital telephone service that can carry voice and data. Poor price/performance has limited the number of ISDN users in the United States, but it is popular in many other countries. The format of the ISDN record is:

               name [ttl] IN ISDN ISDN_address subaddress

The ISDN record is rarely used because most IP-to-ISDN bridges have internal mechanisms to map from IP addresses to ISDN addresses. The ISDN record is defined in RFC 1183.

The obsolete Mail Group record defines mail delivery instructions for mailing lists using a scheme in which the list name and the mailboxes of the individual recipients in the list are defined in DNS. In actuality, mailing lists are processed by mail servers and are defined in the configuration of those servers, not in DNS. This record is no longer used. It is, however, documented in RFC 1035 and thus listed in the Resource Record Type dialog.

The obsolete Mailbox record defines mail delivery information for an individual user. As originally envisioned, every user in the domain would be given a unique MB record. This record has been obsolete for many years. The mail server, not DNS, handles mail delivery to individuals. The MB record is documented in RFC 1035 and is therefore listed in the Resource Record Type dialog. However, you should not use this record.

The obsolete Mailbox Information record defines control information for MG mailing lists by defining both the email address of the email administrator and an email address where error messages should be sent. This record is directly related to the obsolete Mail Group record. Mailing lists and the administrative information about mailing lists are defined in the mail server configuration, not in DNS. The MINFO record is documented in RFC 1035 and is therefore listed in the Resource Record Type dialog. However, this record is no longer used.

The Next Domain record provides a way to formally document and authenticate nonexistent domain information. The SIG record, described later, is used to authenticate domain database records. However, a digital signature can only be calculated against an existing record. By its very nature, the information involved in negative caching has no database record to be authenticated. If the information returned by the authoritative name server states that no MX record exists for a given domain name, how is that information authenticated before being added to the cache? The NXT record is the solution. The format of the NXT record is:

               name [ttl] IN NXT next_name type_list

The type_list is a list of the types of resource records that do not exist for the object identified by name. Thus, if no MX record existed for the domain name parrot.example.org , you might have the following NXT record:

parrot.example.org. IN NXT puffin.example.org. MX

The function of the next_name field is a little more obscure. This field contains the next domain name in canonical order as defined by RFC 2535. A simple way to think of canonical ordering is as if each label in the names were sorted without regard to case. The next_name field is used to provide evidence that a name does not exist.

The NXT record is only needed when strong authentication is used. By default, all data from an authoritative server is cached, whether it is a positive response that provides the requested resource records or a negative response that indicates that the requested information does not exist. In the default situation, there is no need to document nonexisting data with the NXT record.

The Public Key record provides the public key for a given domain name. The KEY record is defined in RFC 2535. The format of the KEY record is:

               name [ttl] IN KEY flags protocol algorithm public_key

The public_key is an encryption key, written in base 64 encoding, that is to be used for public key cryptography when communicating with the object identified by name. The value for the public_key field is entered in the “Key (base 64)” box of the Key (KEY) dialog box when the Key record is created.

The value of the algorithm field can be 1 for RSA/MD5, 2 for Diffie-Hellman or for DSA, 4 for Elliptic Curve, or 252 for indirect key. Set the algorithm value by making a selection from the Algorithm drop-down list of the Key (KEY) dialog box.

The protocol field defines the protocol that will use the public key. The key is limited specifically to DNS security by RFC 3445. When the record was originally designed, however, it was to be accessible to other protocols that might want to use the key. Therefore, multiple protocol values were defined, and are supported by the DNS console. Select DNSSEC from the Protocol drop-down list to set the correct value. The full list of protocol field values is:

The flags field is a binary bit mask that contains several different subfields. The “Bit field representation” box of the Key (KEY) dialog shows the changing bit values as you configure the KEY record. Figure C-8 shows how each bit in the flags field is defined by RFC 2535.

Figure C-8. The KEY record flags bit mask

Every bit marked with a Z in Figure C-8 is reserved for future use and must be set to 0. That leaves four active subfields:

The obsolete Mail Rename record defines a mail alias. A mail alias is a nickname for a user that permits mail addressed to the nickname to be delivered to the real user. For example, [email protected] might be an alias for [email protected]. In that case, mail addressed to postmaster would really be delivered to david. The mail server handles aliases; this function is not handled by DNS. The MR record is documented in RFC 1035 and is therefore listed in the Resource Record Type dialog. However, this record is no longer used.

The Responsible Person record, which is defined in RFC 1183, identifies the point of contact for a host or domain. The format of the RP record is:

               name [ttl] IN RP mail_address text_pointer

The mail_address is the email address of the responsible person. The @ usually included in an email address is replaced with a dot. Thus, [email protected] becomes craig.example.org . The text_pointer is the domain name of a TXT record that contains additional information about the responsible person. Here’s an example of how an RP record is used with a TXT record:

ibis.example.org.   IN RP  craig.example.org. ibisRP
ibisRP.example.org. IN TXT "Craig Hunt (301)555-1234 X237"

The RP record states that the person responsible for ibis.example.org can be reached via email at [email protected] and that additional information about the person can be obtained in the TXT records for ibisRP.example.org. The TXT record in this example provides the contact person’s name and phone number, but it could provide any information you wish.

RP records could make it easier for system administrators to contact each other when things go wrong. However, most domains don’t use RP records because these records can expose internal email addresses to the outside world.

The experimental Route Through record points to a gateway that can be used to route packets to networks that are not part of the Internet. The X.25 and ISDN networks mentioned in the description of other resource record are good examples of such networks. The RT record is defined in RFC 1183. The format of the RT record is:

               name [ttl] IN RT preference gateway

The preference value in the RT record is similar to the preference value of an MX record. It is a numeric value and the lower the number, the more preferred the gateway. preference permits DNS to define multiple gateways to the remote host allowing applications that use the RT records to select the best route. When a server returns an RT record as the response to a query, it also includes all A, X25, and ISDN records that define addresses for the gateway. This allows applications on various types of networks to find addressing and routing information from DNS.

The RT record is rarely used. There are no widely available applications designed to use it. Routing protocols handle the distribution of routing information. RT was primarily of interest as a possible technique for integrating dissimilar networks.

The Signature record provides a digital signature to authenticate a set of resource records. The format of the SIG records is:

               name [ttl] IN SIG type_list (
algorithm
labels
original_ttl
signature_expiration
signature_ inception
key_tag
signer_name
signature )

The fields for the SIG record are as follows:

RFC 2535 defines the SIG record.

The Text record is used to define free-form information about the named object. RFC 1035 defines the TXT record. The format is simple:

               name [ttl] IN TXT string

The TXT record can be used to provide information useful for supporting a host. The following example illustrates this use:

buzzard IN TXT "Accounting Department server in room B152"

Because of its free-form nature, the TXT record has been used over time for special purposes, such as providing input to locally developed programs that collect domain information. As noted previously, the TXT record is also used with the RP record.

A Well Known Services record advertises the network services offered by a host. The format of the WKS record is:

               host [ttl] IN WKS address protocol services

The data field of the WKS record contains three fields:

These two WKS records are an example of advertising UDP and TCP services for the host crow:

crow IN WKS 172.20.5.5 TCP ftp telnet
crow IN WKS 172.20.5.5 UDP domain smtp

The WKS record is rarely used. There are no widely distributed programs that take advantage of WKS record, and there is the threat that network intruders will use the information in the WKS record to exploit the advertised system.

The experimental X25 record maps a domain name to an X.25 address, called an X.121 address. X.25 is an international standard for public packet-switched networks. X.25 networks have not been widely used in the United States for many years. The advent of personal computers and the Internet made them largely obsolete, though some countries still use X.25. The X25 record is defined in RFC 1183. The format of the X25 records is:

               name [ttl] IN X25 X.121_address

The X25 record is rarely used because most X.25 networks provide their own mapping to IP addresses. The scale of the Internet makes it impossible for X.25 networks, or any other network for that matter, to ignore IP. In fact, implementations of IP that run directly over X.25 have long been available.