Windows Insider

Zoom, Zoom, Zoom

Windows Server 2003 has a number of differences from Windows 2000 in how it handles DNS queries. They can speed up domain construction and troubleshooting, helping you squeeze more power out of your network.

• By Bill Boswell
• 08/01/2003

So, you’re kicking the tires of Windows Server 2003 and wondering what goodies lie under the hood. You might be attracted to the additional Active Directory horsepower, the new LoJack attitude towards security or the glitzy new group policies. A true connoisseur, though, might take particular interest in the new DNS features that simplify domain construction and help with troubleshooting.

Conditional Forwarding
Consider this scenario. Your company supplies parts to a large conglomerate. The conglomerate provides a Web portal for accessing a suite of services such as requests for quotes, purchase orders, fulfillment notifications, and the like. The servers hosting these Web services reside in a special perimeter network not exposed to the Internet. The conglomerate provides its vendors with an extranet connection leading to this perimeter network.

The Web portal exposes servers via hyperlinks with references that identify the servers by their fully qualified DNS names. For example, an HTML pointer might have the value <a href=“http://vendorWebserver1. conglomerate.
com/purchaseorders”>. When a client in your company sees the host name vendorWebserver1. conglomerate.com, it fires off an A record query to its primary DNS server in your domain. This query has the recursive flag set, telling the DNS server to search for the record if the targeted DNS domain falls outside the server’s scope of authority.

Ordinarily, a DNS server begins such a search by sending an iterative (non-recursive) lookup request to an Internet Top Level Domain (TLD) server. These TLD servers maintain a set of Name Server (NS) records for registered domains along with glue records that contain the host name and IP address corresponding to each NS record. For example, the TLD server for the .com domain might have an NS record indicating that domain conglomerate.com is hosted on name server ns1.conglomerate.com along with a glue record showing the IP address of the server NS1. In response to an A record query, a TLD server returns the NS and glue records for the DNS servers in the DNS domain that roots the tree specified in the query. The querying DNS server then sends the A record request to the name server identified by the TLD server. This process repeats until the DNS server either finds a name server capable of responding to the query with the address of the exact machine desired or exhausts all possibilities.

Here, as Bill Shakespeare would say, lies the rub. In our scenario, the Web servers in the perimeter network aren’t exposed to the Internet and therefore don’t have resource records on the conglomerate’s external DNS server. The resource records only reside on the conglomerate’s internal DNS server. The administrators who control the extranet Web portal have opened port 53 through the perimeter firewall to provide you access to the internal DNS server. Your job is to take advantage of this additional query path without disrupting responses to resource record queries for other DNS domains.

Windows Server 2003 makes this a simple chore with new feature called conditional forwarding. Before seeing how conditional forwarding works, let’s take a look at standard DNS forwarding.

Rather than start a new set of iterative search transactions when confronted with an uncached resource record outside its zone of authority, a DNS server forwards the resource record request to a specified server called a forwarder and waits a period of time for a reply. This Las Vegas-style approach represents a wager on the part of the DNS server that the forwarder has a copy of the requested record, either because it is authoritative for the zone or because someone else has recently requested the same resource record. A Windows DNS server waits five seconds for a forwarder to reply before starting its own iterative search.

Conditional forwarding leverages this process by allowing you to provision specific forwarders based on the DNS domain specified in the client’s query. Figure 1 shows the configuration options for conditional forwarding. In our scenario, the Windows 2003 DNS server would forward a resource record query for a host in the conglomerate.com zone to the internal DNS server listed in the conditional forwarders list rather sending it to the normal Internet forwarder. The internal DNS server for the conglomerate.com zone responds with the requested resource record. The DNS server in company.com never needs to waste time searching the Internet for a record that won’t be found there.

Figure 1. DNS server properties showing the new conditional forwarding options. (Click image to view larger version.)

Stub Zones
You confront another DNS challenge when building a forest containing multiple domains. For example, consider the DNS needs of a secondary school district in Anytown. The school district has two overworked and underpaid administrators who oversee all central IT operations; but each school has its own computing budget and hires its own IT staff. Many of the schools eschew paying trained computing professionals and give stipends to teachers who demonstrate an ability (any ability) for managing the school’s computer systems. For this reason, each school has its own domain in the Anytown school district Active Directory forest. Figure 2 shows the namespace structure for the forest.

Figure 2. The domain diagram for our fictional school system forest with a centrally managed root domain and separate domains for each school.

In this forest, a root domain called anytownschools.edu holds objects representing accounts for the district staff users and desktops along with the central staff administrator accounts and the servers they manage. Each school has its own domain to assure autonomy of the local admins. In addition, the math/science department in each high school has a separate domain to compartmentalize the Information Technology students into a separate management namespace, a configuration change implemented following an unfortunate incident involving a late night lab, a keyboard littered with sunflower seeds, and a student’s pet parrot.

Each school uses Active Directory-integrated zones with all domain controllers configured as DNS servers. A DNS server in the root domain acts as a forwarder for the child DNS servers. The root zone contains delegation records specifying the name servers for the child zones and glue records containing their IP addresses. Here’s an example zone file showing the Start of Authority (SOA) record, the NS record for the zone’s primary master, and the delegation record and glue record for the child zone:

;

; Database file ; anytownschools.edu.dns for ; anytownschools.edu zone.

; Zone version: 5

;

@ IN SOA w2k3-dc1.anytownschools.edu. hostmaster.anytownschools.edu. (

5 ; serial number

900 ; refresh

600 ; retry

86400 ; expire

3600 ) ; default TTL

;

; Zone NS records

;

@ NS w2k3-dc1.

;

; Zone records

;

w2k3-dc1 A 192.168.0.1

;

; Delegated sub-zone:

; westside.anytownschools.edu

;

westside NS w2k3-dc22. westside.anytownschools.edu.

w2k3-dc22.westside A 192.168.3.22

; End delegation

Here’s how this works. When a user in the westmathsci.westside.
anytownschools.edu domain attempts to access a server in the eastmathsci.eastside. anytownschools.edu domain, the DNS locator in the client desktop submits an A record query to a westmath sci.west side.anytownschools.edu DNS server. The server can’t answer the query because it doesn’t host a copy of the target zone, so it forwards the request to a DNS server in anytownschools.edu.

The root server for anytownschools.edu refers to its delegation entries for the eastside.anytownschools.edu zone and returns the corresponding NS and glue records to the westmathsci.westside.anytownschools.edu DNS server, which then submits its A record request to the server specified in the NS and glue records. This server also can’t answer the request (assuming that its cache doesn’t contain the record) and returns the NS and glue records for the eastsidemathsci.eastside.anytownschools. edu zone and the process repeats again.

Problems can arise in this situation if an administrator in one of the schools or in the Math/Science department in one of the high schools changes the IP address of a DC/DNS server or demotes a DC and promotes another without informing an admin in the parent domain so that he or she can change the delegation entries. This results in a lame delegation in which the NS and glue records point at a non-existent server. Lame delegations can cause numerous name resolution problems in a multi-tiered DNS namespace. They can also be frustratingly difficult to diagnose.

Stub zones to the rescue. A stub zone works like a standard DNS secondary zone except that the zone file contains only the Start of Authority (SOA), Name Server (NS), and glue records associated with the child zone. The stub zone server periodically does a zone transfer to refresh its copy of the stub zone, which automatically adds, modifies, and deletes any entries in the stub zone without the need for manual intervention. This makes it nearly impossible to get lame delegations.

Application Naming Contexts
The DNS structure for the Anytown school district highlights another challenge when configuring Windows DNS to support Active Directory. In an Active Directory-integrated DNS zone, each resource record becomes an object in a container called MicrosoftDNS in the domain naming context. This works out fine for resource records that have meaning only within a domain, but it can cause a problem in a multi-domain forest where many resource records have forest-wide significance. These include SRV records pointing at Global Catalog servers, CNAME records representing the Globally Unique Identifier (GUID) for each domain, and the SRV record pointing at the PDC emulator in each domain. These records are stored under a designator called _msdcs. Each domain stores its own set of records under _msdcs.child. domain.root while the root domain in the forest hosts the forest-wide records under _msdcs.domain.root.

Because all DCs in the forest need to see the forest-wide records, it makes sense to store them locally on each DNS server. In Windows 2000, this is done by creating a separate zone called _msdcs.domain.root (where domain. root is the name of the forest root domain), then putting a secondary of this zone on each DNS server.

Windows 2003 resolves the situation a bit more elegantly. When you integrate a DNS zone into Active Directory, the system puts the objects representing resource records in separate naming contexts. Domain records go in a DomainDNSZones naming context and forest records go in a ForestDNSZones naming context.

These special naming contexts are instances of a new feature Windows 2003 feature called an Application naming context. A naming context forms a replication boundary in LDAP, so each DNS naming context can be targeted at a specific set of DCs. Figure 3 shows the targeting options. You can choose to replicate the Domain DNSZones naming context only to DCs in that domain while replicating the ForestDNSZones naming context to every DC in the forest. A third option mimics the standard Win2K way of handling a zone where the records stay in the domain naming context.

Figure 3. DNS naming context properties showing replication targeting options. (Click image to view larger version.)

Windows 2003 DNS permits you to place a DNS zone into an application naming context regardless of the functional level of the domain or the forest, but if you use anything other than the default domain naming context to store resource records, Win2K DCs can’t see the records and won’t function as DNS servers. To take advantage of application naming contexts for storing and replicating DNS zones, you must be running Windows 2003 on all DCs and the forest must be set at Windows 2003 functional level.

DNS Extensions
I’ve mentioned service locator (SRV) records several times. These records can cause a subtle problem for Windows. Here’s how.

A typical DNS transaction uses UDP datagrams for fast, efficient information transfers. Historically, DNS has used a maximum UDP datagram size of 512 octets, but when a Windows client requests _ldap or _kerberos SRV records in a large domain, a DNS server might need to return dozens and dozens of resource records, both SRV records and the A records that contain the target servers’ IP addresses. If the resource records can’t fit into 512 octets, Win2K forces clients to resubmit their request using TCP rather than UDP. This slows down DNS transactions owing to the additional overhead of TCP in terms of memory utilization and additional network conversations.

Windows 2003 enables clients and servers to use larger UDP datagrams by supporting the EDNS0 extension as described in RFC 2671, “Extension Mechanisms for DNS.” This extension permits a client and server to negotiate a maximum supported UDP datagram size so they can correctly size their send and receive buffers and thereby avoid a costly TCP transaction.

It sometimes happens that routers and firewalls expect all DNS transactions to take place within 512-byte UDP datagrams and consider anything larger to be a potential problem. You may need to reconfigure your network infrastructure to accommodate the result of EDNS0 transactions.

The DNSLint Utility
No discussion of Windows 2003 DNS improvements would be complete without a look at a new Resource Kit utility called DNSLint. This command-line tool helps ferret out potential DNS configuration errors and lame delegations that can cause failures in Active Directory and other applications that rely on DNS. It’s available as a free download from the Microsoft Web site at http://support.microsoft.com/?kbid=321045.

As input, DNSLint takes the name of an Active Directory domain or the IP address of a DC and a DNS server that hosts the forest root zone. The output is an HTML page containing details on the DNS configuration and highlighting any errors. You can provide a list of servers from a text file, useful for running periodic diagnostic tests from a script.

Experience Windows Server 2003 Fahrvergnuegen
These DNS features, in and of themselves, might not be enough to convince the boss to let you get behind the wheel of a spanking new copy of Windows 2003, but they should certainly get her in the showroom. Next month’s column covers the divorce of Active Directory from Windows domains and tells you who gets custody of a child called ADAM. Until then, happy motoring.