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.
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 equal 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, the 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 can simply 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's a caveat to these records: you can't 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 MX records. Each MX record is also 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.
Here is a sample MX record in zone file format:
@ MX 10 mail.hasselltech.net @ MX 100 queue.perigee.net
Nameserver (NS) records define the nameservers that can answer queries for a specific 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 salesns.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 needing to verify the data with the authoritative server again.
There are three important intervals to discuss at this point 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. ( 200509171203; serial number 100; refresh 50; 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—in this case, colossus.hasseltech.net—identifies the machine that is listening for requests for the service named in the record. The first number in the middle, 600, 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 which 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 using Kerberos Key Distribution Center (KDC) servers
- _kpasswd
To provide a mechanism for changing Kerberos 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
Warning
A warning that applies from this point forward: even though Microsoft has set up these entries with a leading underscore, you do not want to use either "-" or "_" as the first character in a DNS name, as it is not RFC-compliant. This will cause problems if you ever need to integrate or operate in conjunction with Unix-based BIND DNS servers.
Get Windows Server 2008: The Definitive Guide 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.
