1. Nuts and Bolts
Let's go through the
basic building blocks of DNS first before we break into more advanced
concepts. I'm going to provide you with a very fundamental, introductory
look at DNS, and then in the following sections I'll break down each
part with more detailed explanations and examples. Think of this as an
abstract or executive summary, just so we're all on the same page before
I move on to more technical topics.
The
main premise of DNS is to provide name resolution services—that is, to
resolve friendly textual hostnames to their associated IP addresses. DNS
is the de facto
standard for name resolution on the Internet and in modern networks
that use TCP/IP as the transmission protocol. DNS is based on domains,
which are simply textualnames that refer to logical groupings of
computers There are top-level domains (TLDs), including some that are
probably familiar to you: .COM, .NET, .ORG, and the like. There are also
second-level domains, which are less inclusive and usually take the
form of name.tld. For example, my domain is jonathanhassell.com. O'Reilly has a domain name of oreilly.com. CNN's domain is cnn.com.
Politically, there is
an organization called ICANN, short for the Internet Consortium of
Assigned Names and Numbers, which keeps track of all the top-level
domains. This keeps utter confusion from breaking out when thousands
upon thousands of top-level domains might be issued. Individuals and
businesses are allowed to register second-level domain names beneath
top-level domains—hasseltech.net, for example.
DNS resolves names
based on zones. Zones contain information on computers, services, and IP
addresses for a collection of computers. Zones typically correspond to
DNS domains, but they certainly do not have to. The DNS server or
servers in a zone that contain a readable and writeable copy of the zone
file (which contains all that information on computers, services, and
addresses) is considered to be authoritative.
You must have at least one authoritative server per zone for DNS to
function. Any other DNS servers within this zone are considered to be
secondary servers, meaning they hold a read-only copy of the DNS zone
file.
Finally, there are two types of zones: forward lookup zones
, which resolve hostnames to IP addresses, and reverse lookup zones
, which do the opposite and resolve IP addresses to hostnames. Reverse
lookup zones fall under a special top-level domain named in-addr.arpa,
which ordinary users and clients never see in the course of their
day-to-day work.
Now, let's take a closer look at these elements of DNS.
2. Zones Versus Domains
As you learned in the
previous section, a DNS domain in its simplest form is a second-level
name coupled with an ICANN-sponsored top-level domain—hasselltech.net,
for example. In DNS parlance, a zone is the range of machines and
addresses that a specific nameserver needs to be concerned about. Zones
don't necessarily need to correspond to DNS domains, meaning that I can
have multiple DNS zones for the single hasselltech.net domain. For example, I can have one zone for sales.hasselltech.net, another zone for billing.hasselltech.net, and yet another for hosting.hasselltech.net, all with separate nameservers but all within the control of the hasselltech.net domain.
Why would you want
multiple DNS zones for a single DNS domain? To delegate administration
is a common reason. If your organization is spread all over the country
and you have an administrator for each office around the country, that
administrator is likely best equipped and skilled to handle DNS
configuration for his office—after all, he works with the individual
computers more than a higher-level administrator at the home office
does. So, the home office nameserver is configured to hold afew names
and addresses for servers and machines there, and the branch office
nameservers hold zones for their respective computers. In this
configuration, when a computer comes to their servers and requests a
name for an IP address associated with a branch office, the nameservers
at the home office will refer the requesting computer to the nameserver
at that branch office that holds the names and addresses for that zone, a
process known as delegating name resolution to other servers. Additionally, the branch office server is authoritative for its zone, meaning that it holds the definitive name-to-address correspondence for computers in its zone.
Of course, domains aren't
limited to just a second-level name plus an ICANN-approved extension.
You also can have multiple levels of names: for example, customers.extranet.microsoft.com is a valid name, as is payjon.corp.hasselltech.net.
2.1. Zone Files
Zone information is stored in zone files
which, by default, are stored as ASCII test files in %SystemRoot%\system32\dns
. The files are stored in the format <domain>.dns(e.g., hasselltech.net.dns).
These ASCII files contain the different types of information contained
within forward and reverse lookup zones, which we'll look at in just a
bit.
2.2. Forward and Reverse Lookup Zones
DNS handles forward
lookups, which convert names to IP addresses, and the data is stored
within a forward lookup zone. But DNS also handles reverse lookups,
which convert IP addresses to names. There's also something called a
reverse lookup zone, which does the opposite of a forward lookup zone—it
catalogs all machines within a certain network range. You construct the
name of a reverse lookup zone in a rather odd way. The easiest way to
construct a reverse lookup zone name is to look at the range of IP
addresses you've been assigned, drop the last dotted quad that contains
the numbers you control, reverse the order of the remaining dotted
quads, and then add .in-addr.arpa. For example, if your IP address is 64.246.42.130, the name of the associated reverse lookup zone is 42.246.64.in-addr.arpa.
Reverse lookup zones are constructed a bit differently, depending on whether you have a class A, B, or C IP address. Table 1 shows the respective ways to generate a reverse lookup zone name.
Table 1. Generating a reverse lookup zone name
| Address class | Resulting zone name and method |
|---|
| Class A (12.0.0.0/8) | 12.in-addr.arpa. Only the first quad is set, so only one quad needs to be in the reverse zone. |
| Class B (152.100.0.0/16) | 100.152.in-addr.arpa. Because only two dotted quads are included, only two need to be noted in the reverse zone. |
| Class C (209.197.152.0/24) | 152.197.209.in-addr.arpa. All dotted quads set in the IP address range need to be included in the reverse lookup zone name. |
In practice, it's very
likely that you don't need a reverse lookup zone for public-facing DNS
servers, and it's equally likely that you would be prevented, on a
technical basis, from creating one. (Internal DNS servers are another
matter, which you'll see in a bit.) Although forward lookup zones
concern hostnames and DNS domain names, which are under your control and
management because you buy them from an accredited registrar, reverse
lookup zones deal mainly with IP addresses and their owners, which
probably are not under your control. Unless you have contacted the
Internet Assigned Names Authority (IANA) and obtained a block of IP
addresses specifically from them, it's probable that your ISP actually
owns the addresses and therefore is the one tasked with maintaining
reverse lookup zones.
There
are really only a few reasons why it's advantageous to control your own
reverse lookup zone. First and foremost, some mail servers will refuse
to exchange Internet mail with your servers if their reverse lookups
reveal that you're using a dynamically assigned IP address block of
typical ISPs. This can be a real problem, but your ISP usually can help
you out with this. Second, the Nslookupcommand
can return a nasty but harmless error message about being unable to
find a server name for your current IP address, depending on how you are
connected to the Internet. Although this is annoying, it's simply
saying no appropriate reverse zone is configured for the current
computer. So when you've just installed Active Directory and you run Nslookupto check things out, and you get no results, this is most likely because you haven't yet configured a reverse lookup zone.
3. 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 "-" or "_" 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. Even better,
stay away from using underscores at all. |
|
3.1. 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 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.
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 MaxCacheEntryTtlLimitto 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 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.
3.2. Canonical Name (CNAME) Records
CNAME, 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 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.
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
3.3. 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 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.
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
3.4. Nameserver (NS) Records
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.
3.5. 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 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
3.6. 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:
61.130.98.66.in-addr.arpa. IN PTR alpha.enablehosting.com
3.7. 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 colossus.hasselltech.net.
The service—in this case, Kerberos—is 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 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
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
"-" or "_" as the first character in a DNS name, as they are not
RFC-compliant. This will cause problems for you if you ever need to
integrate or operate in conjunction with Unix-based BIND DNS servers. |
