Inside Windows Server 1002003 [Electronic resources] نسخه متنی

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:

• Zone replication




• Using forwarders




• Deploying into an existing DNS infrastructure




• WINS forwarding




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

Zone Replication

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.

Update Notification

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.

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

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

2. The secondary name servers respond to the DNS Notify message by returning a standard update request for the SOA record.

3. From this point forward, the zone transfer proceeds in a traditional fashion.

Incremental Zone Transfers

A