Anthony wanted to run Windows DNS on his company’s BIND network. It worked—until the intern came along.
Anthony is a systems administrator in a law firm called Contingency Professionals. The firm has nearly 3,000 users. Anthony was running Windows NT 4.0 until a few weeks ago, when he did an in-place upgrade and created a single Active Directory domain with organizational units to hold users and computers in each of the firm’s offices.
Anthony originally wanted to root the domain at the firm’s registered
Internet name, contingencypros.com, but the firm’s network services administrator—not
a friend of Anthony’s, although they do manage to be courteous to each
other in the lunch room—refused to sanction any “Windows stuff” in the
BIND-based root zone. Anthony negotiated a separate Domain Name System
(DNS) zone for AD with the name ad.contingencypros.com. The network services
administrator voiced skepticism that any Windows product was capable of
supporting the firm’s internal name resolution infrastructure and insisted
that all Unix hosts and workstations remain pointed at the BIND server.
Windows DNS Deployment
Anthony deployed DNS before starting his AD upgrades so he could make
sure his name-resolution infrastructure was on solid footing. He installed
Windows 2000 DNS servers as members of the NT domain and configured them
to host the ad.contingencypros.com zone. He configured the DNS server
in the home office as the primary master for the zone, with the servers
in the other offices as secondaries. He pointed the Windows servers and
desktops at the new DNS servers by changing static mappings on servers
and updating the Dynamic Host Configuration Protocol (DHCP) scope options
affecting desktops. This didn’t affect the Unix clients. The network services
administrator had long ago put them on a separate VLAN with a separate
DHCP server so they “wouldn’t be bothered by all that NetBIOS stuff on
Anthony configured each Win2K DNS server to use root hints to perform
lookups for Internet addresses. Root hints are a list of Top Level Domain
(TLD) servers stored in a file called %systemroot%\System32\DNS\cache.
dns. When a client requests a resource record for a host outside the ad.contingencypros.com
zone, the Windows DNS server performs a series of iterative DNS queries
starting with one or more of the TLD servers in the root hints list. The
TLD server returns a list of name servers authoritative for the zone,
and the Windows DNS server contacts one of these servers to query for
the resource record. It continues this process down the list of child
zones until it finds a DNS server that either hosts a copy of the target
zone or has the requested resource record in cache. For example, a query
for www.yahoo.com could be sent to
the TLD root server, a.root-servers.net, at 220.127.116.11, which would return
a list of yahoo.com name servers.
As a side note, the TLD servers in cache.dns have been superseded by new servers managed by the various top-level domain management organizations. These new servers called generic TLD (or gTLD) servers, provide delegation for zones under their respective top-level domains. For example, the gtld.biz servers host records for the .biz TLD. For a full list of the old TLD servers and the new gTLD servers, visit www.qorbit.net/
documents/golden-networks. There is no need to update the root hints list because the legacy TLD servers pass out referrals to the gTLD servers.
Using root hints to resolve names in the contingencypros.com zone presented
Anthony with a challenge. The Windows clients would request a host record
for a Unix server in contingencypros.com, and the Windows DNS servers
would query the Internet TLD servers rather than the internal BIND server.
For example, a query for www.contingencypros.com
would return the firm’s external Web site, not the intranet site.
Anthony resolved this problem by configuring his DNS servers to use the firm’s BIND server as a forwarder. In this configuration, when a Windows DNS server gets a query for a host in the contingencypros.com zone (or any zone outside of ad.contingencypros.com), it first forwards the query to the BIND server and then waits for the forwarder to respond. If it doesn’t get a response in five seconds, the Windows servers begin their own search, starting with the Internet TLD servers.
Configuring the BIND server to be a forwarder has a niggling side effect, though. The Windows servers send it every out-of-zone query, forcing it to search for Internet host records it doesn’t already have in cache. Anthony prefers to have his own DNS servers do the searches. Next month’s column shows how to accomplish this simply using conditional forwarding in Windows Server 2003 DNS.
In preparation for the AD upgrades, Anthony configured the Windows DNS servers to accept dynamic updates. This permitted any new Win2K domain controllers to automatically register their host (A), reverse lookup (PTR), domain aliases (CNAME), and lengthy Service Locator (SRV) records, instead of entering the records into the zone by hand.
To accomplish the dynamic update trick, a DNS client submits an opcode called UPDATE along with the record it wants to register. The Win2K or Windows Server 2003 DNS server that gets an UPDATE request from a client adds the associated record to the zone file and sends an acknowledgement back to the client. Modern Windows platforms update their A and PTR records each time they initialize a network connection and every 24 hours thereafter. The DHCP Client service performs these periodic re-registrations, even for statically configured interfaces. The Netlogon service on DCs updates the server’s A, PTR, CNAME and SRV records every hour.
As part of his initial DNS configuration, Anthony manually created host
records in ad.contingencypros.com for his NT IIS servers. This enabled
his Windows clients to find intranet Web sites hosted by the IIS servers
without forwarding requests to the BIND server. He then went ahead with
the in-place upgrade to AD, which went without a hitch. He’s now in Native
One Tuesday Morning
Earlier this week, Anthony got a call from a help desk technician saying
that several internal Web sites had stopped responding to clients. The
same IIS server hosted the affected sites, so Anthony pinged the IIS server
to see if it was still active. He got a puzzling response. The address
returned by ping came from a subnet set aside for servers, but the address
itself wasn’t familiar to Anthony.
He fired up a DNS MMC console and pointed it at the primary master DNS server. There he discovered that the host record for the IIS server contained the unfamiliar IP address. He obtained the associated MAC address using arp –c then pawed through the MAC tables on his switches until he found the port used by the server. He physically traced the cable in the port and found it connected to a desktop-class machine sitting on a test stand. It was running Win2K Server.
The desktop belonged to an intern studying for Windows certification.
The intern had installed IIS with the same name as the existing Web server
but a different address to avoid IP conflicts. The intern was proud to
point out his knowledge that Windows Internet Name Service (WINS) entries
for the existing server wouldn’t be disturbed because the WINS server
would refuse to overwrite a record if the existing machine were on the
wire. Anthony asked him about the modified DNS resource record, and the
intern expressed doubt that Anthony had interpreted the configuration
correctly. “DNS doesn’t have a ‘no duplicate names’ feature like WINS,”
the intern explained carefully. “It should create a second host record
for the server. That’s why I used the same name, because I wanted to test
round-robin failover of virtual folders on two Web servers.”
Anthony didn’t have time to give the intern an explanation of the true
operation of the UPDATE opcode or to deliver a chewing out for testing
in a production environment because, at that moment, he was called into
the senior partner’s office to explain the service outage. There he found
the network services administrator, who was pointing out that his Apache
servers running on FreeBSD were completely unaffected. Anthony was more
or less successful in explaining to management that the problem was related
to DNS, not Web services, and he promised to keep it from hap- pening
That evening, Anthony set to work moving the ad.contingencypros.com DNS zone file from the current DNS primary master over to a Win2K DC so he could integrate the zone into AD and set the zone to accept only secure updates. He did this because a secure DNS update transaction in Windows requires the client to have Kerberos credentials, which means the client must be a domain member. This stops unauthorized standalone machines from overwriting DNS resource records. He installed DNS on the other DCs and remapped the clients to point at the new servers using a change to the DHCP scope options.
As a side note, the secure update method used by Windows differs from
the mechanism described in RFC 3007, “Secure Domain Name System Dynamic
Update,” and other DNS Security (DNSSEC) RFCs. DNSSEC uses digital signatures
to validate the submitter’s identity and the identity of the DNS server.
A DNSSEC-compliant DNS server stores its own public key and the public
key for clients in special KEY resource records. The clients store their
corresponding private keys locally. Win2K and Windows 2003 DNS servers
can store DNSSEC resource records, but they don’t participate in DNSSEC
transactions. For more information about what’s moving and shaking in
the DNS world, visit the DNS Extensions Working Group site at www.ietf.org/html.charters/
Object-Based Security and DNS
Anthony was satisfied that securing the zone in AD would prevent a repeat
of the incident with the intern, but let’s go a step further and look
for any operational issues that might result from the secure zone configuration.
Integrating a DNS zone into AD copies each resource record from the text-based zone file in %systemroot%System32\DNS into an AD container under \System\Microsoft
DNS. For the most part, each resource record gets a discrete DomainDNS object. However, LDAP rules stipulate that two objects with the same common name can’t exist in the same container, so multiple resource records with the same host name and different IP addresses are stored in a single object with multiple DNSRecord attributes. The DNS management console displays the multiple attributes as separate resource records.
Resource record objects obey the same security rules as any other AD object. One of these rules states that the entity creating an object owns it. In the case of dynamically registered DNS resource records, the objects are owned by the computer account that sent the Update request. This ownership can create issues down the road.
For example, if you disjoin a computer from a domain using the standard shell interface, the system disables the associated Computer account and assigns a DNSTombstone attribute to the associated DNS resource record object. This tombstone attribute prevents the object from being displayed in the DNS console but retains the full object with all its attributes. If scavenging is enabled for the zone, the tombstoned record will be deleted seven days later. If another computer with the same name joins the domain during this time, the system resets the existing computer account, gives it to the new machine and retains the same DNS resource record with a different IP address, if the address changed.
But what happens if a drive crashes or an administrator like Anthony
reimages a desktop? In those instances, the computer object in AD remains
unchanged, as do the DNS resource record objects. The administrator can
rejoin a newly rebuilt computer back into the domain using the same computer
name if he or she has sufficient permissions. An extended permission set
called, “Add Computers to Domain,” exposed in the Delegation Wizard at
the root of a domain, grants sufficient permissions for this rejoining
Protection Against Hijackers
This means that an administrator with sufficient permissions can, accidentally
or maliciously, hijack an existing computer account even with secure updates
enabled by waiting until the target machine is turned off then joining
a machine with the same name to the domain. If this occurs, the new machine
takes over the secure channel to the domain and the DNS resource records.
Even if the offending machine is removed from the network, the original machine can’t authenticate users because it has lost its secure channel to the domain. Attempts to resolve this by running NETDOM /RESET wouldn’t succeed because an administrator account in the domain would no longer have access for writing new account password information to the local LSA secrets. The only cure would be to disjoin the computer from the domain and rejoin it again.
So Anthony was correct in his assumption that he was protected from negligent
behavior on the part of his intern, but he isn’t protected from willful
misbehavior on the part of an administrator with sufficient access permissions.
Next month’s column will go into more detail about other DNS configuration
options and discuss new DNS features in Windows 2003.