Learn AD in 15 Minutes a Week: Microsoft DNS - Part 2

Monday Jan 6th 2003 by Jason Zandri
Share:

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.

In 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.

DNS Features

Feature
Windows 2000
Windows NT 4.0
BIND 8.2
BIND 8.1.2
BIND 4.9.7
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 GSS-TSIG algorithm Yes No No No No
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.

Reverse Lookups

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 121.41.113.10, 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 121.41.113.10.

[NOTES FROM THE FIELD] - A Web site, http://remote.12dt.com/rns/, created by Frank Riherd 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.

DNS Caching

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 period.

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.)

DNS Records

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 domain.
The @ symbol is replaced by a period (.) in the e-mail address of the administrator.
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 121.41.113.10

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 Zandri.net "becomes" 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 below:

www              CNAME Server1
ftp                 CNAME Server1

PTR (Pointer) records 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 121.41.113.10, 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 121.41.113.10. 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 your feedback.

Until next time, best of luck in your studies.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved