4.3. Resource RecordsA 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.
4.3.1. Host (A) RecordsHost 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.
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 setthat 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 disadvantages include the following:
4.3.2. Canonical Name (CNAME) RecordsCNAME, or canonical name, records allow you to give multiple host names to one IP address. Using CNAMEs, you can have a machine answering on one IP address but listening to several different hostnameswww.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.
A sample CNAME record in zone file format looks like this: ftp CNAME colossus.hasselltech.net 4.3.3. Mail Exchanger (MX) RecordsMail 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 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:
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.
A sample MX record in zone file format is similar to this: @ MX 10 mail.hasselltech.net @ MX 100 queue.perigee.net 4.3.4. Nameserver (NS) RecordsNameserver (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. 4.3.5. Start of Authority (SOA) RecordsThe 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:
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 4.3.6. Pointer (PTR) RecordsPointer (PTR) records work very similarly to A records, except they perform the function in reversePTR 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 4.3.7. Service (SRV) RecordsService (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 servicein this case, Kerberosis the leftmost part of the record, and the _tcprefers 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, in this case colossus.hasseltech.net. 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 recordthese 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:
|