Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Functional Description of DNS Query Handling

It's important to have a fairly good idea of how DNS queries are handled before starting to architect your name resolution system (or change an existing system that is functioning properly). This topic contains step-by-step descriptions of DNS queries using several scenarios:

• A query handled by an authoritative server




• A query handled by a non-authoritative server




• A reverse-lookup query

Knowing how DNS queries are handled helps when designing a DNS system and when integrating Windows Server 2003 name services into an existing DNS infrastructure.

Queries Handled by Authoritative Servers

Assume, for example, that a user at a Windows Server 2003 computer in the company.com domain pings a server called srv1. Procedure 5.1 shows what happens from the point of view of DNS.

Procedure 5.1 Functional Description of Query Handling by an Authoritative Name Server

1. Tcpip.sys needs the IP address of srv1 so it can build an ICMP packet. To get this address, Tcpip.sys uses its internal DNS resolver. The remainder of this discussion refers to this resolver as if it were a separate service.

2. The resolver fires off a query to its associated DNS server. The query contains the following:

   
   

   • The fully qualified DNS name of the target computerin this case, srv1.company.com.

   
   

   • The resource record type being requested. It's doing a simple host name lookup, so the query is for an A record.

   
   

   • The resource record class being requested. This is nearly always the IN, or Internet, class. Other classes are used only in very limited circumstances.

   
   
   
   

   DNS Packet Contents It can be instructive to view the contents of the DNS messages involved in a name query transaction. The Network Monitor service that comes with Windows Server 2003 is a great tool for capturing and examining packets going to and from the local network interface. Figure 5.4 shows a captured packet containing the response to a Host query (A record) from an authoritative DNS server. The following are the key items to examine: UDP entry. Indicates that DNS query uses UDP port 53. This is the well-known port for DNS. DNS flags. The server indicates that it is authoritative for the domain, it supports recursive queries, and there was no error in the response. DNS question section. This contains a copy of the original DNS query asking for a host record for dc01.company.com. DNS answer section. The response contains the A record information for dc01.company.com, including its IP address and the default TTL value from the SOA record. Figure 5.4. Captured packet showing DNS standard query response. If you have a DNS server inside a firewall and you need to send queries to a TLD root server or some other public name server, you must either enable UDP port 53 at the firewall or configure your DNS server to use Network Address Translation (NAT) or a proxy to access the Internet. Windows Server 2003 running DNS answers a DNS query on the same interface that receives the query, so enabling UDP port 53 is adequate to support DNS queries and their responses.

3. When the DNS server receives the query, it parses the host name to find the DNS domain, company.com. In this instance, the DNS server is authoritative for the requested zone, so it does a zone lookup to find the requested resource record.

4. When the DNS server finds the A record for srv1, it sends the entire contents of the record back to the client in the form of a

   DNS Query Response . If the A record does not contain a TTL value, the DNS server inserts the minimum TTL value from the SOA record for the zone. The default TTL is one hour, or 3,600 seconds.

   If the DNS server cannot find the requested record, it returns a Record Not Found response. An authoritative DNS server does not consult another DNS server when it cannot resolve a query within its zone of authority. When the resolver gets a Record Not Found response from an authoritative name server, it returns an error to the application without attempting further lookups.

5. Now that the resolver has obtained the IP address, Tcpip.sys has some work to do. It uses the IP address from the A record to build an IP packet, then it uses

   Address Resolution Protocol (ARP) to find the MAC address associated with the IP address. Tcpip.sys then hands over the packet and the MAC address to the NDIS (Network Driver Interface Specification) driver, which works with the adapter driver to build a transmission frame that is sent to the target server.

6. Tcpip.sys also hands the A record over to the

   DNS Resolver Cache service. The Resolver Cache holds onto the A record for the time period specified in the TTL.

Queries Handled by Non-Authoritative Servers

Consider the situation if the user, instead of trying to access a file on a server on the internal network, tries to access a file on an external network such as the Internet. For example, the user opens a browser and points it at www.roswellnm.org. (I was born in Roswell. My friends say that explains a lot about me.) In this trace, let's skip the OSI Layer 7 details and get right to the DNS query (see Procedure 5.2).

Procedure 5.2 Functional Description of Query Handling by Non-Authoritative Name Server

1. The DNS resolver sends off a recursive query to its DNS server asking for an A record for www.roswellnm.org. A recursive query tells the DNS server to do all the work in resolving the address.

2. The local DNS server in the company.com DNS domain has no zone file for roswellnm.org. The recursive query tells the server to refer the request to another DNS server, but which one? This is where the root hints in the Cache.dns file come into play.

3. After consulting the root hints file, the DNS server fires off an iterative query to a top-level domain (TLD) server saying, in effect, "Give me an A record for www.roswellnm.org or tell me the name of a server that can help me."

4. In every likelihood, the TLD root server does not have an A record for www.roswellnm.org. However, the TLD server is authoritative for the domain .org. That means it has name server (NS) records pointing at servers that host the zone for .org.

5. The root server consults its NS records and discovers several name servers for roswellnm.org. It returns the NS and A records for each of these name servers. Here's one example: dns1.interland.net at IP address 64.224.20.132.

   Trace Names If you'reExamining Zones with Nslookup."

6. The company.com DNS server now sends an iterative query to dns1.interland.net asking for an A record for www.roswellnm.org. The resolver at the client is still waiting patiently.

7. The DNS service on dns1.interland.net is authoritative for roswellnm.org. It does a zone file lookup and finds an A record for www with the IP address 209.35.62.148.

8. When the company.com DNS server receives the A record for www.roswellnm.org in answer to its query, it forwards the record to the client that originally sent the query. It also caches a copy in case another client sends a similar query. The aging time is determined by the TTL value in the A record.

The key point to remember about the actions of the non-authoritative server is that the root hints file is used to find the name and IP address of a root server. Without root hints or a forwarder, the query would have failed.

Reverse Lookup Queries

A standard DNS zone is called a

forward lookup zone because it searches by the name of the record until it either finds the entry or reaches the end of the zone. But what if a user knows the IP address of a host and wants the associated name? An example of this kind of reverse lookup occurs when you use ping with the a switch. This tells ping to display the host name along with the ICMP Echo Reply, like this:

E:\>ping -a 10.1.1.254
Pinging router.company.com [10.1.1.254] with 32 bytes of data:
Reply from 10.1.1.254: bytes=32 time<10ms TTL=128

This seems simple enough, but it turns out to be something of an exercise. DNS forward lookup zones are structured around host names, not IP addresses. Extracting a host name based on an IP address from a forward lookup zone would require an incredibly expensive scan that could encompass all the millions of zones scattered on DNS servers all over the planet.

DNS avoids this impossible situation by creating a separate zone file based on IP addresses. This is called a

reverse lookup zone . Figure 5.5 shows an example reverse lookup zone displayed in the Windows Server 2003 DNS console.

Structure of a Reverse Lookup Zone

A reverse lookup zone is built using one record type, the PTR record. A PTR record contains the octets from the host ID in reverse order. The following listing contains examples of zone entries from a reverse lookup zone for the 10.1.0.0 network:

; Database file 1.10.in-addr.arpa.dns for 1.10.in-addr.arpa zone.
; Zone version:  8
;  Zone records
1.1        PTR    dc01
21.1       PTR    srv12
254.1       PTR    router01

Note that the network address 10.1.0.0 is reversed to make 1.10. If the network address were 222.100.93.0, the start of the zone file name would be 93.100.222.

This reversal is necessary because the dotted-decimal notation used by IP addresses puts the most significant octet to the far

left , whereas the referral mechanism used by DNS assumes that the most significant field is at the far

right . Following the DNS referral method to its logical conclusion, if the inverted IP addresses form a contiguous tree, there would need to be 255 root domains with 255 separate primary name servers, one each for the 255 available addresses in the upper octet of the dotted-decimal IP address format.

The top of this reverse lookup namespace needs a root, so the

Advanced Research Project Administration (ARPA), which was in charge of the Internet at the time DNS was devised, created an artificial root with the name in-addr.arpa. With the in-addr.arpa root in place, a single TLD server can own the whole reverse lookup zone with 255 nodes at the second level, a paltry number compared to the kazillions of second-level domains in the .com namespace.

What this means to you as a DNS administrator is that you must build a reverse lookup zone rooted at in-addr.arpa for every IP network in your organization. The name for each of these zones would start with the reverse of its network ID followed by the suffix in-addr.arpa. For example, the network ID 209.12.73.0 would have a reverse lookup zone of 73.12.209.in-addr.arpa. Typically, you would use the primary name server for the root domain of your organization as the primary server for the reverse lookup zones.

Reverse Lookup Process

Procedure 5.3 shows how DNS handles a reverse lookup request. Assume, for example, that a user in the company.com domain, address 10.1.0.0, uses ping a to find the host name for 209.12.73.4.

Procedure 5.3 Functional Description of Reverse Lookup Query

1. The resolver sends its DNS server a reverse lookup query, called a

   Domain Name Pointer request, for 4.73.12.209.in-addr.arpa.

2. The DNS server is not authoritative for the 73.12.209.in-addr.arpa zone, so it refers the query to one of the TLD servers.

3. The TLD server does not have a zone file for 73.12.209.in-addr.arpa, but it has an NS record for the name server that holds the zone for 209.in-addr.arpa. It returns a referral containing the NS and A records for that name server.

4. The company.com DNS server now sends its PTR query to the name server in the referral. This server does not have a zone file for 73.12.209.in-addr.arpa either, but it returns the NS and A records for a name server holding the zone for 12.209.in-addr.arpa.

5. The company.com DNS server now sends the PTR query to the name server in the referral. This server

   does hold the zone file for 73.12.209.in-addr.arpa. It returns the contents of the PTR record for 4 along with the associated A record, which contains the host name, www.newmexico.com.

Many DNS administrators don't create reverse lookup zones on the theory that they aren't used often enough to make them worth the trouble. I recommend creating reverse lookup zones so you have all DNS tools at your disposal.