Introduction to DNS

Resource Record Types

Different types of resource records can be used to provide DNS-based data about computers on a TCP/IP network. This section describes the following resource records:

SOA
NS
A
PTR
CNAME
MX
SRV

Next, it lists some of the other resource records specified by RFC standards. Finally, it lists resource records that are specific to the Windows 2000 implementation and one resource record specified by the ATM Forum.

SOA Resource Records

Every zone contains a Start of Authority (SOA) resource record at the beginning of the zone. SOA resource records include the following fields:

The Owner, TTL, Class, and Type fields, as described in "Resource Record Format" earlier in this chapter.
The authoritative server field shows the primary DNS server authoritative for the zone.
The responsible person field shows the e-mail address of the administrator responsible for the zone. It uses a period (.) instead of an at symbol (@).
The serial number field shows how many times the zone has been updated. When a zone's secondary server contacts the master server for that zone to determine whether it needs to initiate a zone transfer, the zone's secondary server compares its own serial number with that of the master. If the serial number of the master is higher, the secondary server initiates a zone transfer.
The refresh field shows how often the secondary server for the zone checks to see whether the zone has been changed.
The retry field shows how long after sending a zone transfer request the secondary server for the zone waits for a response from the master server before retrying.
The expire field shows how long after the previous zone transfer the secondary server for the zone continues to respond to queries for the zone before discarding its own zone as invalid.
The minimum TTL field applies to all the resource records in the zone whenever a time to live value is not specified in a resource record. Whenever a resolver queries the server, the server sends back resource records along with the minimum time to live. Negative responses are cached for the minimum TTL of the SOA resource record of the authoritative zone.

The following example shows the SOA resource record:

noam.reskit.com.  IN  SOA (

                noamdc1.noam.reskit.com.     ; authoritative  server

                                                   for the zone

                administrator.noam.reskit.com.   ; zone admin e-mail

                                                 ; (responsible person)

                5099                             ; serial number

                3600                             ; refresh (1 hour)

                600                              ; retry (10 mins)

                86400                            ; expire (1 day)

                60        )                      ; minimum TTL (1 min)

NS Resource Records

The name server (NS) resource record indicates the servers authoritative for the zone. They indicate primary and secondary servers for the zone specified in the SOA resource record, and they indicate the servers for any delegated zones. Every zone must contain at least one NS record at the zone root.

For example, when the administrator on reskit.com delegated authority for the noam.reskit.com subdomain to noamdc1.noam.reskit.com., the following line was added to the zones reskit.com and noam.reskit.com:

noam.reskit.com.     IN     NS      noamdc1.noam.reskit.com.

A Resource Records

The address (A) resource record maps an FQDN to an IP address, so the resolvers can request the corresponding IP address for an FQDN. For example, the following A resource record, located in the zone noam.reskit.com, maps the FQDN of the server to its IP address:

noamdc1         IN        A      172.16.48.1

PTR Records

The pointer (PTR) resource record, in contrast to the A resource record, maps an IP address to an FQDN. For example, the following PTR resource record maps the IP address of noamdc1.noam.reskit.com to its FQDN:

1.48.16.172.in-addr.arpa.    IN    PTR    noamdc1.noam.reskit.com.

CNAME Resource Records

The canonical name (CNAME) resource record creates an alias (synonymous name) for the specified FQDN. You can use CNAME records to hide the implementation details of your network from the clients that connect to it. For example, suppose you want to put an FTP server named ftp1.noam.reskit.com on your noam.reskit.com subdomain, but you know that in six months you will move it to a computer named ftp2.noam.reskit.com, and you do not want your users to have to know about the change. You can just create an alias called ftp.noam.reskit.com that points to ftp1.noam.reskit.com, and then when you move your computer, you need only change the CNAME record to point to ftp2.noam.reskit.com. For example, the following CNAME resource record creates an alias for ftp1.noam.reskit.com:

ftp.noam.reskit.com.    IN    CNAME    ftp1.noam.reskit.com.

Once a DNS client queries for the A resource record for ftp.noam.reskit.com, the DNS server finds the CNAME resource record, resolves the query for the A resource record for ftp1.noam.reskit.com, and returns both the A and CNAME resource records to the client.

Note

According to RFC 2181, there must be only one canonical name per alias.

MX Resource Records

The mail exchange (MX) resource record specifies a mail exchange server for a DNS domain name. A mail exchange server is a host that will either process or forward mail for the DNS domain name. Processing the mail means either delivering it to the addressee or passing it to a different type of mail transport. Forwarding the mail means sending it to its final destination server, sending it using Simple Mail Transfer Protocol (SMTP) to another mail exchange server that is closer to the final destination, or queuing it for a specified amount of time.

Note

Only mail exchange servers use MX records.

If you want to use multiple mail exchange servers in one DNS domain, you can have multiple MX resource records for that domain. The following example shows MX resource records for the mail servers for the domain noam.reskit.com.:

*.noam.reskit.com.   IN     MX      0    mailserver1.noam.reskit.com.

*.noam.reskit.com.   IN     MX      10   mailserver2.noam.reskit.com.

*.noam.reskit.com.   IN     MX      10   mailserver3.noam.reskit.com.

The first three fields in this resource record are the standard owner, class, and type fields. The fourth field is the mail server priority, or preference value. The preference value specifies the preference given to the MX record among MX records. Lower priority records are preferred. Thus, when a mailer needs to send mail to a certain DNS domain, it first contacts a DNS server for that domain and retrieves all the MX records. It then contacts the mailer with the lowest preference value.

For example, suppose Jane Doe sends an e-mail message to JohnDoe@noam.reskit.com on a day that mailserver1 is down, but mailserver2 is working. Her mailer tries to deliver the message to mailserver1, because it has the lowest preference value, but it fails because mailserver1 is down. This time, Jane's mailer can choose either mailserver2 or mailserver3, because their preference values are equal. It successfully delivers the message to mailserver2.

To prevent mail loops, if the mailer is on a host that is listed as an MX for the destination host, the mailer can deliver only to an MX with a lower preference value than its own host.

Note

The sendmail program requires special configuration if a CNAME is not referenced in the MX record.

SRV Records

With MX records, you can have multiple mail servers in a DNS domain, and when a mailer needs to send mail to a host in the domain, it can find the location of a mail exchange server. But what about other applications, such as the World Wide Web or telnet?

Service (SRV) resource records enable you to specify the location of the servers for a specific service, protocol, and DNS domain. Thus, if you have two Web servers in your domain, you can create SRV resource records specifying which hosts serve as Web servers, and resolvers can then retrieve all the SRV resource records for the Web servers.

The format of an SRV record is as follows:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

The _Service field specifies the name of the service, such as http or telnet. Some services are defined in the standards, and others can be defined locally.
The _Proto field specifies the protocol, such as TCP or UDP.
The Name field specifies the domain name to which the resource record refers.
The TTL and Class fields are the same as the fields defined earlier in this chapter.
The Priority field specifies the priority of the host. Clients attempt to contact the host with the lowest priority.
The Weight field is a load balancing mechanism. When the priority field is the same for two or more records in the same domain, clients should try records with higher weights more often, unless the clients support some other load balancing mechanism.
The Port field shows the port of the service on this host.
The Target field shows the fully qualified domain name for the host supporting the service.

The following example shows SRV records for Web servers:

_http._tcp.reskit.com. IN  SRV 0  0  80      webserver1.noam.reskit.com.

_http._tcp.reskit.com. IN  SRV 10 0  80      webserver2.noam.reskit.com.

Note

This example does not specify a TTL. Therefore, the resolver uses the minimum TTL specified in the SOA resource record.

If a computer needs to locate a Web server in the reskit.com DNS domain, the resolver sends the following query:

_http._tcp.www.reskit.com.

The DNS server replies with the SRV records listed above. The resolver then chooses between WebServer1 and WebServer2 by looking at their priority values. Because WebServer1 has the lowest priority value, the DNS server chooses WebServer1.

Note

If the priority values had been the same, but the weight values had been different, the client would have chosen a Web server randomly, except that the server with the highest weight value would have had a higher probability of being chosen.

Next, the resolver requests the A record for webserver1.reskit.com, and the DNS server sends the A record. Finally, the client attempts to contact the Web server.

For more information about SRV records, see the link to the Internet Engineering Task Force (IETF) on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Windows 2000 supports the Internet Draft titled "A DNS RR for specifying the location of services (DNS SRV)."

Less Common Resource Records

Table 5.3 shows some other resource records and the RFCs that define them. Many of these resource records are considered experimental.

Table 5.3 Less Common Resource Record Types

Record Type	RFC	Description
AAAA	1886	Special address record that maps a host (computer or other network device) name to an IPv6 address.
AFSDB	1183	Gives the location of either an Andrew File System (AFS) cell database server, or a Distributed Computing Environment (DCE) cell's authenticated server. The AFS system uses DNS to map a DNS domain name to the name of an AFS cell database server. The Open Software Foundation's DCE Naming Service uses DNS for a similar function.
HINFO	1035	The host information resource record identifies a host's hardware type and operating system. The CPU Type and Operating System identifiers come from the computer names and system names listed in RFC 1700.
ISDN	1183	The Integrated Services Digital Network (ISDN) resource record is a variation of the A (address) resource record. Rather than mapping an FQDN to an IP address, the ISDN record maps the name to an ISDN address. An ISDN address is a phone number that consists of a country/region code, an area code or country/region code, a local phone number, and optionally, a subaddress. The ISDN resource record is designed to be used in conjunction with the route through (RT) resource record.
MB	1035	The mailbox (MB) resource record is an experimental record that specifies a DNS host with the specified mailbox. Other related experimental records are the mail group (MG) resource record, the mailbox rename (MR) resource record, and the mailbox information (MINFO) resource record.
MG	1035	The mail group (MG) resource record is an experimental record that specifies a mailbox that is a member of the mail group (mailing list) specified by the DNS domain name. Other related experimental records are the MB resource record, the MR resource record, and the MINFO resource record.
MINFO	1035	The MINFO resource record is an experimental record that specifies a mailbox that is responsible for the specified mailing list or mailbox. Other related experimental records are the MB resource record, the MG resource record, and the MR resource record.
MR	1035	The MR resource record is an experimental record that specifies a mailbox that is the proper rename of another specified mailbox. Other related experimental records are the MB resource record, the MG resource record, and the MINFO resource record.
RP	1183	Identifies the responsible person (RP) for the specified DNS domain or host.
RT	1183	The route through (RT) resource record specifies an intermediate host that routes packets to a destination host. The RT record is used in conjunction with the ISDN and X25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way.
TXT	1035	The text resource (TXT) record associates general textual information with an item in the DNS database. A typical use is for identifying a host's location (for example, Location: Building 26S, Room 2499). A single TXT record can contain multiple strings, up to 64 kilobytes (KB).
WKS	1035	The well-known service (WKS) resource record describes the services provided by a particular protocol on a particular interface. The protocol is usually UDP or TCP, but can be any of the entries listed in the Windows 2000 Protocols file located in % SystemRoot%\System32\Drivers\Etc\Protocol. The services are the services below port number 256 from the Windows 2000 Services file located in % SystemRoot%\System32\Drivers\Etc\Services.
X.25	1183	The X.25 resource record is a variation of the A (address) resource record. Rather than mapping a FQDN to an IP address, the X.25 record maps the name to an X.121 address. X.121 is the International Standards Organization (ISO) standard that specifies the format of addresses used in X.25 networks. The X.25 resource record is designed to be used in conjunction with the route through (RT) resource record.

Resource Records Not Defined in RFCs

In addition to the resource record types listed in the RFCs, Windows 2000 uses the following resource record types, shown in Table 5.4.

Table 5.4 Resource Record Types Not Defined in the RFCs

Name	Description
WINS	The Windows 2000 DNS server can use a WINS server for looking up the host portion of a DNS name that does not exist in the DNS zone authoritative for the name.
WINS reverse lookup (WINS-R)	This entry is used in a reverse lookup zone for finding the host portion of the DNS name if given its IP address. A DNS server issues a NetBIOS adapter status query if the zone authoritative for the queried IP address does not contain the record and does contain the WINS-R resource record.
ATMA	The ATMA resource record, defined by the ATM Forum, is used to map DNS domain names to ATM addresses. For more information, contact the ATM Forum for the ATM Name System Specification Version 1.0.

Delegation and Glue Records

Delegation and glue records are records that you add to a zone in order to delegate a subdomain into a separate zone. A delegation is an NS record in the parent zone that lists the name server authoritative for the delegated zone. A glue record is an A record for the name server authoritative for the delegated zone.

For example, suppose the name server for the DNS domain reskit.com, delegated authority for the noam.reskit.com zone to the name server noamNS.noam.reskit.com. You add the following records to the reskit.com zone:

noam.reskit.com.                IN     NS   noamNS.noam.reskit.com

noamNS.noam.reskit.com.         IN     A    172.16.54.1

Delegations are necessary for name resolution. Glue records are also necessary if the name server authoritative for the delegated zone is also a member of that domain. A glue record is necessary in the example above because noamNS.noam.reskit.com. is a member of the delegated domain noam.reskit.com. However, if it was a member of a different domain, the resolver can perform standard name resolution to resolve the name of the authoritative name server to an IP address.

When a resolver submits a query for a name in the child zone to the name server that is authoritative for the parent zone, the server authoritative for the parent zone checks its zone. The delegation tells it which name server is authoritative for the child zone. The server authoritative for the parent zone can then return a referral to the resolver.