Windows Insider

Anthony's Tale

Anthony wanted to run Windows DNS on his company’s BIND network. It worked—until the intern came along.

• By Bill Boswell
• 07/01/2003

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 the network.”

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 198.41.0.4, 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 mode.

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

Secure Updates
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 again.

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/ dnsext-charter.html.

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 to succeed.

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.