Active Directory Integration
In addition to the two RFC-compliant zone transfer methods, Windows Server 2003 DNS zone can be integrated into Active Directory. This eliminates the need for conventional zone transfers because Active Directory is replicated using its own multiple-master replication scheme.
Active Directory integration also makes it possible for any Windows Server 2003 or Windows 2000 domain controller that is running DNS to update the zone.
The DNS service requires very little overhead, so you can easily deploy DNS on every domain controller. In terms of performance, bandwidth utilization, and manageability, integrating DNS into Active Directory is a win. There are a few caveats, however:
No ASCII zone files.
Resource records are stored in Active Directory as objects. If you want a text file to use as a fallback, you can maintain at least one standard secondary name server. Windows Server 2003 and Windows 2000 DNS will provide zone updates to the secondary and the secondary can save these in a regular text file.
Relies on Active Directory availability.
Clients need DNS to find domain controllers. Hosting DNS on the same server that hosts Active Directory means you have multiple failures if the server goes down or is otherwise unavailable. You can minimize this risk by including at least two DNS servers in the TCP/IP configuration for the clients. Also, remember that the domain controller is also a DNS client, so make sure it points at itself for DNS lookups.
A Windows DNS server must be the primary name server.
This may cause discomfort for DNS administrators who currently run UNIX or NetWare DNS and are hesitant about cutting over to Windows.
When a DNS server gets a query for a record in another zone that it does not have in cache, it checks its root hints to find a root server and then uses iterative queries to "walk the tree" until it finds a name server that has the record. This process is detailed in the earlier section in this chapter, "Functional Description of DNS Query Handling."
There is an alternative to doing all that grunt work, and that is to check with another server that might have already done the grunt work first. This is called forwarding. The server being referenced by your DNS server is called a forwarder. Figure 5.7 shows an example DNS configuration that incorporates forwarders.
Figure 5.7. DNS configuration using standard forwarding and conditional forwarding.
The primary name server in the figure is configured to use a forwarder in two situations:
When the server receives queries for hosts in the subsidiary.com zone, it forwards those queries to one or more name servers in the subsidiary.com DNS domain. This is called conditional forwarding and is a new feature in Windows Server 2003.
When the server receives queries for hosts outside its own zone and not in subsidiary.com, it forwards those queries to a name server maintained by an ISP.
In the second case, if the primary name server also has a functional set of root hints for the Internet top-level domain servers, it waits a while and then sends a query to one of those servers as well. It's betting that the forwarder will come through with the requested record before it has to do an iterative walk through the Internet to find a name server for the requested domain.
A server configured to use a forwarder exclusively for out-of-zone lookups is called a slave server. A slave server depends completely on its forwarder. If the forwarder cannot find the record, the slave sends a No Record response back to the client. A Windows Server 2003 or Windows 2000 DNS server can be made into a slave server by selecting the Do Not Use Recursion for This Domain option in the Forwarders configuration in the server properties window.
Windows Server 2003 introduces a new feature that simplifies integrating DNS with name servers in other domains. Rather than designating a single server to use as a forwarder, you can designate separate forwarders for individual domains. This is configured as part of the DNS server properties in the DNS console. Figure 5.8 shows the configuration.
Figure 5.8. DNS server properties showing conditional forwarder configuration.
Here's an example of how to use conditional forwarding. Let's say that you have an extranet connection to a vendor that is used for sharing database access and the occasional file transfer. The vendor's DNS domain name is vendor.com. The IP address of the vendor's DNS server is 192.168.0.30. Your clients have access to this server for purposes of submitting DNS queries.
Windows 2000 caused a bit of grief for administrators trying to configure forwarders and root hints for their DNS servers. In Windows 2000, a newly installed DNS server was automatically configured with a root domain, indicated by a folder with a dot (.) at the top of the namespace. This root domain tells a DNS server that it sits at the top of the entire DNS namespace and whatever domains it hosts are top-level domains.
This is absurd, of course. No private server can be a TLD server. At best, it can be the root server for its own domain. But as long as that root zone exists, a Windows server cannot be convinced it is anything other than the once and future king, wielder of the sacred sword, master of the Elvish rings, and so on. This means the server will not accept root hints and cannot be configured to use forwarders.
This "feature" of Windows 2000 forced administrators to delete the root zone so that they could correctly configure their DNS infrastructure. In Windows Server 2003, the root zone is not installed by default.
You can configure conditional forwarding at your DNS server so that all requests for resource records in the vendor.com domain are sent to 192.168.0.30. Your DNS server sends an iterative request to the target DNS server and forwards the response back to the clients.
Windows Server 2003 supports a special type of zone configuration called a stub zone. A stub zone is used in place of delegation records when configuring a parent DNS server to send referrals to delegated DNS servers in a child domain.
A stub zone contains the SOA record and NS (Name Server) records for a child zone along with the A records (also called glue records) corresponding to the name servers in the child zone. The stub zone server periodically updates its copy of the resource records. This simplifies delegation management.
Here's an example. Let's say you are the administrator of the company.com zone. You want to delegate the branch.company.com zone to another DNS server in your organization that is managed by another administrator.
Ordinarily, you would accomplish this by creating delegation records in the company.com zone that point at the name servers in branch.company.com. If the administrator responsible for branch.company.com adds or removes a name server, you would need to add and remove delegation records in company.com.
With stub zones, instead of creating delegation records, you create a stub zone on the company.com DNS server that points at branch.company.com. When you initially create the stub zone, it copies the SOA, NS, and glue records from the DNS server in branch.company.com.
When the company.com DNS server gets requests for resource records in branch.company.com, it uses name servers in the target domain to resolve the requests recursively. This speeds up subsequent requests because the stub zone server builds up a cache of resource records from the target zone.
If the administrator for branch.company.com adds or removes a name server, the stub zone on your DNS server picks up the changes automatically. This relieves you of the responsibility for manually updating your delegation records.
Deploying Windows DNS into an Existing Infrastructure
Many DNS administrators tend to be leery about trusting Windows DNS. If you currently use BIND or Lucent QIP or NetWare 5.x for your DNS services, you do not need to change to Windows Server 2003 simply to accommodate Active Directory. The non-Windows DNS server must support RFC 2052, "A DNS RR for Specifying the Location of Services (DNS SRV)." In addition, it should support RFC 2136, "Dynamic DNS."
As we'll see when we get to Active Directory design, Windows Server 2003 depends on DNS to provide the structure for the new generation of Windows domains. You may find it difficult to combine the namespace you want for Active Directory with your existing DNS namespace. You may need to create a separate namespace for Active Directory that is hosted on Windows DNS servers rather than BIND servers. Figure 5.9 shows an example of how such a split namespace can be achieved.
Figure 5.9. DNS configuration showing a split namespace for private and public zones with same name.
The example contains the following configuration features:
The zone for the Active Directory domain is hosted on a Windows Server 2003 running DNS to take advantage of secure dynamic updates.
The main corporate zone is hosted on a BIND server, which has a stub to the Windows zone rather than delegation records. UNIX clients in the organization obtain resource records from the Active Directory domain via referrals through the stub zone.
The Windows Server 2003 running DNS uses the BIND server as a forwarder. This permits Windows clients to obtain resource records from the main corporate zone.
The BIND server forwards out-of-zone traffic to a DNS server at an ISP. This permits both UNIX and Windows clients to resolve Internet names.
The BIND server is configured as a slave to the ISP forwarder so that it does not use root hints to get records directly from the Internet TLDs. This minimizes traffic through the firewall.
The ISP name server hosts the primary zone for the public corporate domain. This permits Internet users to resolve addresses for servers in the corporate DMZ without giving access through the firewall to the internal DNS server.
Most organizations use a hybrid of this basic configuration. For instance, an organization might want to maintain its own public DNS server in the DMZ. Or, the administrators might want the Windows DNS server to forward directly to the ISP name server and eliminate a potential single point of failure at the BIND server.
Whatever configuration you choose, if you use Windows DNS servers, make sure that Windows clients (this includes member servers and domain controllers) point at Windows DNS servers. This ensures that they see the SRV records they need to support access to vital domain controller services such as LDAP and Kerberos.
While we're on the subject of forwarding, let's take a look at a form of forwarder that has been around since NT4 DNS.
Windows servers occupy a special place because they are both TCP/IP hosts with hierarchical host name and SMB-based servers with flat NetBIOS names. In the SMB world, the servers happily register their names and services with WINS with little or no administrative intervention. In the DNS world, someone must create records for the servers in the correct zone so non-Windows clients can find them.
Rather than maintain two databases, NT4 introduced a couple of proprietary resource records, the WINS record and the WINS-R record. These records pointed a Windows DNS server at one or more WINS servers. This enabled the server to forward DNS requests for Windows servers to WINS.
Properly configured secondary servers improve reliability and reduce WAN traffic—two of the major goals for your DNS design. Another goal is to reduce administrative work, and that's where dynamic updates come into play.
Windows 2000 and Windows Server 2003 support dynamic zone updates as described in RFC 2136, "Dynamic Updates in the Domain Name System." This RFC defines a new opcode called DNS Update that can be used to add records to a zone automatically. A DNS Update message contains the type of record to add (for example, an A record for a host name or an SRV record for a domain controller service), the name of the zone where the record should be added, and any prerequisite records that must or must not be present. As a minimum, modern Windows clients register an A (host) record and a PTR (reverse lookup pointer) record with their DNS server.
Dynamic DNS clients (Windows Server 2003, XP, and Windows 2000) register their A and PTR records at boot time then refresh them every 24 hours. These dynamic updates are performed by the DHCP Client service. Do not disable this service, even if you use static IP addressing on your servers. Domain controllers refresh their DNS records every hour. This is controlled by the Netlogon service.
Non-RFC 2136 clients such as downlevel Windows clients can register their A and PTR records by proxy through Dynamic Host Configuration Protocol (DHCP). See "Configuring DHCP to Support DNS," near the end of this chapter for details.
You can force dynamic registration at Windows Server 2003, XP, and Windows 2000 clients using IPCONFIG as follows:
Certain stipulations apply when dynamically registering a resource record:
When a client attempts to register a record that does not already exist, the DNS server adds the new record updates to the zone.
If a record exists with a different name but the same IP address, the new record is added and the old record is left in place.
If a record exists with the same host name but different IP address, the original record is overwritten with the new address value.
Although the primary DNS server has the only read/write copy of the zone file, the DNS client can be configured to point at any authoritative server for the zone. The secondary servers pass the DNS Update messages from the clients up to the primary master. The primary name server notifies its secondaries of the change, and the secondaries pull an incremental zone transfer.
If the client is configured to point at a non-authoritative server such as a caching-only server, the dynamic updates are not passed on to the authoritative server and the client is not registered.
Dynamic Updates and Domain Controllers
An Active Directory domain controller (Windows Server 2003 or Windows 2000) automatically registers its A and PTR records along with its service locator (SRV) records via the Netlogon service. The records are refreshed each time the service starts (usually at boot time) and hourly thereafter.
If you make a change to a domain controller and you want to update DNS immediately, stop and start the Netlogon service. The domain controller continues to perform Kerberos authentications with Netlogon turned off but downlevel clients (Windows 9x and NT) cannot authenticate.
If a domain controller cannot find its DNS server or the DNS server does not accept dynamic updates, you will see errors in the Event log. These errors are common in a BIND Domain Name System (DNS) infrastructure where dynamic updates have been disabled at the name server.
If you want to avoid Event log errors and a constant drone of invalid request traffic to your BIND servers, you can disable automatic SRV record renewal by making a Registry change:
You will also need to delete the Netlogon.dnb file from the C:\Windows\System32\Config folder. This file contains records for automatic updating.
You can also control automatic DNS updates from clients and domain controllers using group policies. It is still necessary to delete the Netlogon.dnb file manually.
Dynamic registration carries the risk that your nice, clean DNS zone might start to look like something best described as an aftermath. To avoid this, use scavenging to clean out old and unused records.
Scavenging is not enabled by default. It can be enabled for a particular zone or for every zone on a DNS server. Scavenging only applies to primary zones and Active Directory Integrated zones. Secondary zones are read-only. If you scavenge the master zone, the secondary zones get cleaned up during the zone transfers.
Because scavenging works by including an aging value in the dynamically registered resource records, it changes the format of the zone file, making it incompatible with non-Windows name servers. Zone transfers are unaffected because the DNS service filters out the aging value, but you cannot take a copy of the .DNS file for the zone and load it onto an NT4 or BIND name server.
Scavenging uses two intervals, the non-refresh interval and the refresh interval, to determine when a particular record should be removed from the zone file. Both intervals are set for seven days by default. Here is how they work.
When a resource record is first dynamically created, DNS assigns an aging value based on the seven-day non-refresh interval. During this seven-day interval, DNS does not accept refreshes to the record. This prevents the system from being overwhelmed every morning with refreshes from thousands of machines as they are turned on.
After the initial, seven-day non-refresh interval, the record is free to be refreshed. DNS clients refresh their records at boot time and every 24 hours, if they are left on. The refresh interval lasts for another seven days. At the end of the seven-day refresh interval, if the aging value has not been refreshed, the record will be removed during scavenging.
Scavenging can be initiated manually from the PROPERTIES menu of the zone icon or by scheduling it to run periodically as part of the DNS server properties (see "Configuring Scavenging" later in this chapter).
If a user goes on vacation for more than two weeks and leaves her machine off, the DNS registration for her A and PTR records will age out and periodic scavenging will remove them from the zone. This is not a catastrophe. The user does not lose any security privileges or functionality. When the user starts up the machine after coming back from vacation and logs on, the system will re-register with DNS and build a new resource record.
A primary goal of DNS design is security. DNS security has several facets:
Limit the number of administrators who can make changes to the zone.
Prevent exposing the contents of your zones to unauthorized individuals.
Avoid potential abuse of the dynamic record registration mechanism.
Limit Administrative Access
You can control the security settings for accessing a DNS server. By default, Domain Admins, Enterprise Admins, DNS Admins, and the Administrators groups have full control. You can remove some of these groups to limit access to just members of the DNS Admins group or you can create another group for this purpose.
The DNS Admins group is created in Active Directory by default when you install DNS. The Administrator account is a member of the group. The group is given Full Control rights over any DNS server in the domain as well as Full Control rights over the DNS zone information in Active Directory for Active Directory Integrated zones.
If you define a separate group for DNS administration, be sure that you don't put the group in an OU where someone with administrator privileges can change the group membership. This defeats the purpose of the security group. Also remove the DNS Admins group from the access control list, because anyone with administrator rights in Active Directory can control the membership of this group.
When setting security configuration for a DNS server, be sure to leave the Authenticated Users group on the access control list with the special rights they are assigned by default. This permits DNS clients to read the contents of a DNS server.
Prevent Unauthorized Zone Transfers
DNS servers make particularly enticing targets for intruders. They hold the IP address of every host in your network, and that kind of information can be damaging in the wrong hands. For instructions on adding or removing a server from the list of authorized servers, see the upcoming section, "Enabling Zone Transfers and Update Notifications."
One consequence of locking down zone transfers is that you cannot use tools like Nslookup to view the contents of the zone file. This is because these tools use the same zone file transfer opcodes that a secondary server uses. This is not true for the DNSCMD utility that is installed when you install DNS on a server. If you have administrative privileges for a DNS server, you can use DNSCMD to dump the contents of a zone file.
Secure Dynamic Updates
One of the most important security measures you can take regarding dynamic updates is to control the computers that are permitted to register resource records. Without adequate controls, someone could accidentally or maliciously poison your zone file with false or misleading records. Or, they could stage a denial of service attack by registering thousands and thousands of bogus resource records.
The current Standards Track documents for controlling DNS Update security are RFC 2535, "Domain Name System Security Extensions," and RFC 2930, "Secret Key Establishment for DNS." These and other supporting RFCs combine to form the DNSSec documentation. Windows Server 2003 does not implement DNSSec transactions, but it does support the new resource record types involved in those transactions.
Windows Server 2003 permits you to restrict dynamic DNS Updates so that only authenticated computers in a domain can update their DNS information. To get this security, you must integrate the zone into Active Directory. A default group, DNS Admins, has read/write access to these DNS objects. Figure 5.10 shows an example access control list.
Figure 5.10. Access control list for Active Directory Integrated DNS zone showing DNS Admins group.
For instructions on configuring a secure update zone, see the "Managing Dynamic DNS" section later in this chapter.