Resource Records

A DNS zone contains various types of entries, called resource records. Resource records are the meat of a DNS zone, providing information about hostnames, IP addresses, and in some cases the services offered by a particular machine. There are several different classes of record types, the most common of which I’ll define now.


Don’t use either a “-” or a “_” as the first character in any DNS name, as they are not compliant with the DNS standard. Confusingly, Windows DNS systems will accept these entries, but it’s best to stay away from them.

Host (A) Records

Host records, or A records, simply map a hostname to an IP address. You generally create host records for each machine in your network.

A sample A record looks like this in a zone file:

colossus    A

Using host records, you can implement a load-balancing technique known as round-robin DNS. Round-robin DNS involves entering multiple A records, all configured with the same hostname, but with different IP addresses that correspond to different machines. This way, when computers contact a nameserver for a certain hostname, they have an equally proportionate chance of receiving any one of the number of machines with A records. For example, if I have a web site at and I have three web servers at,, and, I can configure three A records, all named “www,” but with the three IP addresses mentioned earlier. Now, when client computers come to the nameserver and ask for the IP address of, they have a 33% chance of receiving as the web server of choice, a 33% chance of receiving, and a 33% chance of receiving It’s a poor-man’s load-balancing system.


Let’s get a bit more technical: in this scenario, Windows 2000 and Windows XP clients will continue to attempt a connection to the first web server that was originally resolved. A DNS cache timeout value on the client is set to 86,400 seconds (one day) by default. If you change this value on the client to one second, you have better odds of reaching your server. You can change this value in the registry with the following key:


Change the MaxCacheEntryTtlLimit to the number of seconds desired.

If the group of machines that serve web sites are on different subnets, Windows Server 2003’s DNS system can return the “proper” address from a round-robin record set—that is, the one that is closest to the client requesting it. This functionality is enabled by default. For example, if you have one A record set up for on IP address, and another A record set up for the same hostname on IP address, a client computer located on the subnet will receive the A record from his request, and a client computer located on the subnet will receive the A record from his request.

Some advantages to round-robin DNS balancing include the following:

  • The price is right—it’s free with any nameserver.

  • It’s less complex than other, proprietary balancing systems.

  • It’s easy to maintain. You simply can add and delete A records in the zone file for each host as they come and go to and from production service.

The disadvantages include the following:

  • It’s less complex than other, proprietary balancing systems. Yes, this is an advantage and a disadvantage because a less complex system is less flexible than a proprietary solution.

  • If a web server goes down, DNS isn’t aware of it. It simply will continue to dole out IP addresses regardless of whether the server is available.

  • It doesn’t take into account the various capabilities and capacities of each system—it distributes the load fairly equally, whether your group of machines includes a Pentium 2 or a dual Pentium IV Xeon machine.

Canonical Name (CNAME) Records

CNAME, or canonical name, records allow you to give multiple hostnames to one IP address. Using CNAMEs, you can have a machine answering on one IP address but listening to several different hostnames—,, and all might be on one IP address, CNAMEs effectively work as aliases.

However, there is a caveat to these records: you cannot have multiple identical CNAMEs. For example, if you have a record for on, you can’t have another CNAME record named for a different IP address. CNAMEs are only for multiple names to one IP address, not for multiple IP addresses to one name. Note that these names are zone dependent, not server dependent.


Sometimes Windows will refer to CNAME records as aliases, in a confusing mix of technical accuracy and common parlance.

A sample CNAME record in zone file format looks like this:

ftp    CNAME

Mail Exchanger (MX) Records

Mail exchanger, or MX, records identify the mail server or mail servers for a specific zone or domain. Very simply, they instruct connecting computers to send all mail destined for a domain to a specific machine configured to receive Internet email.

In practice, a specific DNS zone can have multiple records. Each MX record also is assigned a preference number, which simply indicates what steps the respective machines listed should take when receiving Internet email. Lower preference numbers have higher priority. For example, let’s say I have the following MX records:

  •, MX preference 10, to

  •, MX preference 100, to

This instructs connecting computers to send Internet email destined to to the machine However, if that machine isn’t answering requests, connecting computers are instructed to try the machine and deliver mail there because the preference number is higher (100) than that of the first machine, which is 10. MX preference numbers provide a bit of failover protection if your organization’s mail server is on a flaky or nonpermanent connection.


Entering two MX records with the same preference number distributes the load between the two hosts roughly equally, much like round-robin DNS balancing using multiple A records.

A sample MX record in zone file format is similar to this:

@    MX    10
@    MX    100

Nameserver (NS) Records

Nameserver (NS) records define the authoritative nameservers for a domain. They also delegate the resolution duties for various subdomains to other zones. For example, you might configure an NS record for the “sales” subdomain to delegate name resolution duties to the machine which handles that zone, or an NS record for the “billing” subdomain to delegate duties to the computer.

A sample NS record in zone file format looks like this:

@    NS
@    NS

Start of Authority (SOA) Records

The start of authority, or SOA, record for a zone names the primary nameservers that are authoritative for a particular zone and provides contact information for the primary administrator of the zone. It also controls how long a nonauthoritative nameserver can keep the information it retrieved in its own cache before having to verify the data with the authoritative server again.

There are three important intervals to discuss when it comes to SOA records.

Refresh interval

The refresh interval indicates to secondary nameservers how long they can keep their copies of the primary nameserver’s zones before being required to request a refresh of the zone.

Retry interval

The retry interval indicates how long the secondary nameserver must wait before attempting to contact the primary nameserver again after a failed attempt to refresh its zones after the refresh interval has lapsed.

Minimum (default) TTL

This value indicates to other nameservers how long they can use information they’ve previously retrieved from this authoritative nameserver before being required to consult the authoritative server again for updated or refreshed information. This is, by default, 60 minutes. You also can set TTL values for individual records that override this minimum default setting for a zone.

A sample SOA record in zone file format looks like this:

@ IN SOA (
; serial number
; refresh
; retry
86400        ; expire
3600     )      ; default TTL

Pointer (PTR) Records

Pointer (PTR) records work very similarly to A records, except they perform the function in reverse—PTR records point IP addresses to hostnames and reside in reverse lookup zones.

A sample PTR record in zone file format looks like this: IN PTR

Service (SRV) Records

Service (SRV) records indicate the range and availability of services in a particular zone or domain. They catalog the protocols and services running on specific ports in a zone, creating a “Yellow Pages” of sorts for connecting computers to find machines in the zone that will handle their specific types of requests. Like MX records, SRV records have a preference number, so you can perform a kind of poor-man’s load balancing and fault tolerance with these as well.

SRV records require a bit more explanation because they are so important to Active Directory. Here is an example SRV record in zone file format:

_kerberos._tcp._sites.dc._msdcs 600 SRV 100 88

The service—in this case, Kerberos—is the leftmost part of the record, and the _tcp refers to whether the service operates on the TCP or UDP transmission protocols. The rightmost part of the record identifies the machine that is listening for requests for the service named in the record. The first number in the middle indicates the time to live (TTL) for that record, recorded in seconds. The rightmost number, 88, refers to the port number on which the service is listening. Finally, 100 refers to the preference number for the record—these work exactly like MX record preference numbers as described in the previous section.

Why are SRV records crucial to Active Directory? Because they indicate what domain machines are running what Active Directory services. Active Directory really looks for only four services to be advertised within SRV records:

  • _kerberos, to provide user and computer authentications

  • _kpasswd, to provide a mechanism for changing passwords securely

  • _ldap, for the Lightweight Directory Access Protocol, the way external programs communicate and exchange data with Active Directory

  • _gc, for the Global Catalog, which contains a subset of attributes for all the objects in an Active Directory forest

Get Learning Windows Server 2003 now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.