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