Designing DNS Domains
Now that you know the components of DNS and how they function, you're ready to design your own DNS system. Like all distributed network functions, your major goals are unbroken continuity of service, fast performance, minimum network traffic across the WAN, strong security, and a reasonably small need for administrative attention. We've already seen how primary and secondary DNS servers can be distributed to provide fault tolerance. This section covers these additional DNS features:
Deploying into an existing DNS infrastructure
Dynamic zone updates
Automated database scavenging
Active Directory integration
Secure DNS Updates
We'll take a look at each of these features from the viewpoint of fitting them into the design architecture. Then we'll see how to configure them using the DNS Management console.
A secondary name server obtains a copy of a zone file either from the primary name server or another secondary via a mechanism called a zone transfer.
Classic DNS zone transfers require the secondary server to poll its feeder server at regular intervals and copy the entire zone file if a change occurred. This method has a couple of weaknesses. First, polling mechanisms are an inefficient use of bandwidth. Second, copying an entire zone file takes an inordinate amount of bandwidth and CPU time.
Windows 2000 and Windows Server 2003 incorporate two RFC-based provisions, update notification and incremental zone transfers, designed to improve classic DNS zone transfers. In addition, zone information can be stored in Active Directory, eliminating the need for specialized zone transfer mechanisms entirely.
In a standard zone transfer, the secondary name server polls its master periodically to see whether the zone has changed. The polling interval is set by a Refresh Interval in the Start of Authority (SOA) record. Figure 5.6 shows an example SOA record.
Figure 5.6. Zone Properties window showing Start of Authority (SOA) tab. The Refresh interval determines the polling time between zone transfers.
When a secondary server reaches the end of its refresh interval, it asks its master for a copy of its SOA record. This record contains a serial number, which is a sequence number incremented each time the zone is updated. If the serial number in the SOA record held by the secondary is lower than the serial number in the SOA record polled from the master, the secondary initiates a zone transfer.
Windows Server 2003 and Windows 2000 DNS implements the provisions of RFC 1996, "A Mechanism for Prompt Notification of Zone Changes." This RFC defines a new DNS opcode (operations code, one of the commands understood by DNS servers and clients) called DNS Notify. Procedure 5.4 shows how it works.
Procedure 5.4 Functional Description of Standard Polled Zone Transfer
When an update is made to the zone at the master name server, the server sends out a DNS Notify message to its secondary name servers. It must be configured with the IP addresses of these servers.
The secondary name servers respond to the DNS Notify message by returning a standard update request for the SOA record.
From this point forward, the zone transfer proceeds in a traditional fashion.
NT4 DNS implemented the DNS Notify opcode, but the administrator was required to manually initiate the notification by selecting UPDATE SERVER DATA FILE from the zone's PROPERTY menu. This was required because NT4 DNS used standard zone transfers, which copied the entire zone file.
Windows Server 2003 and Windows 2000 support incremental zone transfers, so notification is done automatically and the updates are copied as quickly as the secondaries can pull them down.
Incremental Zone Transfers
A standard DNS zone transfer involves copying the entire zone file from the primary name server to its secondaries and from secondary to secondary in a tiered structure. Windows Server 2003 and Windows 2000 avoid this sometimes lengthy file transfer by implementing the provisions of RFC 1995, "Incremental Zone Transfer in DNS."
In an incremental transfer, the secondary server supplies the serial number from its copy of the SOA record when it requests a zone transfer. The master server sends only those updates that have been made subsequent to that serial number.
If a Windows Server 2003 or Windows 2000 name server is a secondary to a master that does not support incremental transfers, it falls back to using full zone transfers.