Part 18 of Jason Zandri's 'Learn Active Directory Design and Administration in 15 Minutes a Week' series takes a second look at Microsoft DNS and reverse lookups and caching, as well as some of the local records that the DNS server holds.
Welcome to the 18th installment
of "Learn Active Directory Design and Administration in 15 Minutes a Week," a
weekly series aimed at current IT professionals preparing to write the new
Windows Active Directory Design and Administration exams (70-219 and 70-217
respectively), as well as newcomers to the field who are trying to get a solid
grasp on this new and emerging directory service from Microsoft.
This installment takes another look at Microsoft DNS and reverse lookups, caching, and some of the local records that the DNS server holds.
Microsoft DNS - Part 1 we looked at iterative and recursive lookups and
overviewed DNS zones.
[NOTES FROM THE FIELD] -
Microsoft DNS is not a requirement for Active Directory. Microsoft DNS on Windows 2000 is RFC-compliant and allows for the deployment of Active Directory under other DNS implementations. It has been tested to work with Windows NT 4.0, BIND 8.2, BIND 8.1.2, and BIND 4.9.7.
Microsoft DNS under Windows 2000 supports some features not supported under other implementations of DNS.
Windows NT 4.0
|Support for the IETF Internet-Draft "A DNS RR
for specifying the location of services (DNS SRV)." (SRV records)||Yes||Yes (with SP 4)||Yes||Yes||Yes|
|Support for dynamic update||Yes||No||Yes||Yes||No|
|Support for secure dynamic update based on the
|Support for WINS and WINS Record||Yes||Yes||No||No||No|
|Support for fast zone transfer||Yes||Yes||Yes||Yes||Yes|
|Support for incremental zone transfer||Yes||No||Yes||No||No|
|Support for UTF||Yes||No||No||No||No|
BIND version 4.9.7 is the
earliest version of BIND supported for a Windows 2000 Active Directory
environment for DNS support.
When a DNS client requests a reverse DNS lookup it is effectively requesting to resolve a host name of a known IP address. In the standard DNS namespace, there is no connection between host names and IP addresses, and only a thorough search of all domains will allow for the reverse resolution.
The addr.arpa domain was created to avoid this type of query load on DNS
systems. Listings for system names in the in-addr.arpa domain is by their
respective IP addresses. Because the design of IP addresses is such that they
become more significant from left to right, and domain names get less significant
from left to right, the order of IP address in the in-addr.arpa domain are
listed in reverse order.
Pointer (PTR) records are added to the host names and IP addresses and the
corresponding host name. To perform a successful reverse lookup of a given IP
address, such as 126.96.36.199, the DNS server performing the query looks for a PTR record for 10.113.41.121.inaddr.arpa which will have the host
name and IP address 188.8.131.52.
[NOTES FROM THE FIELD] - A Web site,
http://remote.12dt.com/rns/, created by
allows users to punch up an IP address, and it will perform the reverse
lookup and return the name of the resolved address to you.
Microsoft Knowledge Base Article - Q245574 HOWTO: Configure REMOTE_HOST to
Perform a Reverse DNS Lookup in IIS outlines the steps to Perform a Reverse
DNS Lookup in IIS.
Often, DNS servers will be called on to resolve the same
query multiple times within a short span of time. As an example, if a number of
America Online users, arguably the largest ISP in the world, get an e-mail
that new articles have been posted to
2000trainers.com and a number of users begin their day by going to their
browsers to read the new articles, the AOL DNS servers are going to be
continually recalling the resolved address many times within a short time
DNS servers will cache the resolved addresses for a
specific amount of time specified as the Time to Live (TTL) in the returned
data. The DNS server administrator of the zone that contains the data decides on
the TTL for the data. This means that the named administrator of the
2000trainers.com domain and DNS
servers for 2000trainers.com sets
the TTL value. This tells the resolving DNS server (in this example, the ones
at AOL) how long to hold that information in its cache. The lower the TTL the
"fresher" the resolution data on the resolving DNS servers.
Once data is cached by a DNS server it will decrease the TTL from its original
value so that it will know when to flush the data from its cache. If another
query for resolution comes in to the DNS server for the URL again, the cached
data will be used and the TTL is reset (in most cases) to the original TTL. (The
only way it wouldn't be reset to the same TTL value from before would be if the
named administrator of the
2000trainers.com domain and DNS server(s) for
2000trainers.com sets a different TTL.)
The DNS database consists of a number of different resource
records, the most common of which are the address records that hold
computer names and the TCP/IP address of that computer.
Some of the other records held on the DNS server were mentioned briefly in
Microsoft DNS - Part 1, and we will detail them a little more here.
The Start of Authority Record (SOA)indicates the starting point
of authority for a given DNS zone on a specific DNS server. The SOA resource
record is the first resource record created when you add a new zone. The
following is an example of an SOA record:
@ IN SOA server1.zandri.net. (
1 ; serial number
7200 ; refresh [2h]
900 ; retry [15m]
86400 ; expire [1d]
7200 ) ; min TTL [2h]
The at symbol (@) in a database file indicates "this server."
IN indicates an Internet record.
Any host name not terminated with a period (.) will be appended with the root
The @ symbol is replaced by a period (.) in the e-mail address of the
Parentheses ( () ) must enclose line breaks that span more than one line.
[NOTES FROM THE FIELD] - The 7200 ; refresh
[2h] shows a time period of 2 hours, 900 ; retry [15m] shows a time
period of 15 minutes, 86400 ; expire [1d] shows an expiration time period
of 1 day and 7200 ; min TTL [2h] shows a minimum time to live of 2 hours.
Everything in that record after a ; is a comment,
which is why the line breaks are necessary.
Name Server (NS)
records designate the DNS domain names for the servers that are authoritative
for a given DNS zone and may list additional name servers within the
record. The following is an example of an NS record:
@ IN NS server2.zandri.net.
[NOTES FROM THE FIELD] - The at symbol (@) in a database file
indicates "this server" and the IN indicates an Internet record.
(A) records, sometimes called host records or address records, contain the name-to-IP address mapping information used to map DNS domain names to a
host IP address on the network.
The following are examples of host records:
server1 IN A 184.108.40.206
localhost IN A 127.0.0.1
Alias records, normally referred to as CNAME (canonical name) records allow you to provide additional names to a server that already has a name in an A (host)
resource record. This is how a Web server with a name of Server1 in a domain of
www.zandri.net as far as DNS resolution is concerned. An Alias
record is referencing
www.zandri.net to Server1.zandri.net. Some examples of this are listed
www CNAME Server1
ftp CNAME Server1
are used for reverse lookup queries. A reverse lookup query resolves an IP
address to a name. Reverse lookup zones are created in the in-addr.arpa domain
to designate a reverse mapping of a host IP address to a host DNS domain name.
As we mentioned earlier, to perform a successful reverse lookup of a given
IP address such as 220.127.116.11, the DNS server performing the query looks for a PTR record for 10.113.41.121.inaddr.arpa, which will have the host
name and IP address 18.104.22.168. The record for it would look like this:
10.113.41.121.inaddr.arpa. IN PTR Server1.Zandri.net.
[NOTES FROM THE FIELD] - Reverse lookup zones are not a
requirement; they are an optional configuration.
The CACHE.DNS file contains the records of the root DNS servers. The
cache file is basically the same on all name servers, and it must be present
for a DNS server to properly handle a query outside its zone.
The file is provided by default with the Windows 2000 DNS Server and has the current
records for all of the root servers on the Internet. It is stored in the %SystemRoot%\System32\Dns
folder that DNS is installed on a Windows 2000 Server.
If you are running DNS for internal use and not for connections for
forwarding to the Internet, the CACHE.DNS file should be replaced to contain the
name server's authoritative domains for the root of the private network.
[NOTES FROM THE FIELD] - In certain situations, the CACHE.DNS file in the %systemroot%\system32\dns folder is replaced, and it does
not update the root hints listed in the DNS Manager. This can happen because the
DNS server is a domain controller and is configured to load zone data on startup
from Active Directory and the registry. This behavior occurs when the root hints specified in the Active Directory have been deleted, modified, incorrectly entered, or damaged.
Additional information on this can be found in Microsoft's Knowledge Base Article -
Q249868 Replacing Root Hints with the Cache.dns File
Well, that wraps up this section of "Learn Active Directory Design and
Administration in 15 Minutes a Week." I hope you found it informative and will
return for the next installment.
If you have any questions, comments or even constructive
criticism, please feel free to drop me a note.
I want to write solid technical articles that appeal to a
large range of readers and skill levels, and I can only be sure of that through
Until next time, best of luck in your studies.