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.
Warning
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 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 192.168.0.10
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
www.hasselltech.net and I have three web servers at 192.168.0.50,
192.168.0.51, and 192.168.0.52, 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 www.hasselltech.net, they
have a 33% chance of receiving 192.168.0.50 as the web server of
choice, a 33% chance of receiving 192.168.0.51, and a 33% chance of
receiving 192.168.0.52. It’s a
poor-man’s load-balancing system.
Tip
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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
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 www.hasselltech.net on IP address 192.168.0.51, and another A record set up for the same hostname on IP address 10.0.0.25, a client computer located on the 10.0.0.0 subnet will receive the 10.0.0.25 A record from his request, and a client computer located on the 192.168.0.0 subnet will receive the 192.168.0.51 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.
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—www.hasselltech.net, ftp.hasselltech.net, and mail.hasselltech.net all might be on one IP address, 192.168.1.2. 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 www-secure.hasselltech.net on 192.168.1.2, you can’t have another CNAME record named www-secure.hasselltech.net 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.
Tip
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 colossus.hasselltech.net
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:
Hasselltech.net, MX preference 10, to mail.hasselltech.net
Hasselltech.net, MX preference 100, to queue.perigee.net
This instructs connecting computers to send Internet email destined to hasselltech.net to the machine mail.hasselltech.net. However, if that machine isn’t answering requests, connecting computers are instructed to try the machine queue.perigee.net 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.
Tip
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 mail.hasselltech.net @ MX 100 queue.perigee.net
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 sales-ns.hasselltech.net machine which handles that zone, or an NS record for the “billing” subdomain to delegate duties to the billing-dns.hasselltech.net computer.
A sample NS record in zone file format looks like this:
@ NS colossus.hasselltech.net. @ NS ns2.hasselltech.net.
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 colossus.hasselltech.net. admin.hasselltech.net. ( ; serial number ; refresh ; retry 86400 ; expire 3600 ) ; default TTL
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:
61.130.98.66.in-addr.arpa. IN PTR alpha.enablehosting.com
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 colossus.hasselltech.net.
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:
_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 the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
