Microsoft windows 2000 DNS manual Update Algorithm, Dynamic Update of DNS Records

Page 22

protocols, rendered manual updating of DNS information insufficient and unusable. No human administrator can be expected to keep up with dynamic address assignments even in a medium size network environment. It was clear that automatic assignment of addresses had to be integrated with dynamic DNS updates. This capability, known as Dynamic Update, is defined in RFC 2136.

Protocol Description

The Windows 2000 DNS service supports Dynamic DNS (DDNS) as covered in RFC 2136. The RFC introduces a new opcode or message format called UPDATE. The update message can add and delete RRs from a specified zone as well as test for prerequisite conditions. Update is atomic, that is, all prerequisites must be satisfied or else no update operation will take place.

As in any conventional DNS implementation, the zone update must be committed on a primary name server for that zone. If an update is received by a secondary server, it will be forwarded up the replication topology until it reaches the primary server. Note that in the case of a DS integrated zone, an update for a record in that zone may be sent to any DNS server running on a domain controller whose DS contains the zone.

A zone transfer process will always lock a zone so that a secondary server gets a consistent zone view while transferring the zone data. When the zone is locked it can no longer accept dynamic updates. If the zone is large and being locked very often for the zone transfer purposes, it will starve dynamic update clients, and system can become unstable. The Windows 2000 DNS server queues the update requests that arrived during the zone transfer and processes them after the zone transfer is completed.

Update Algorithm

The update sequence consists of the following steps:

A client, using an SOA query, locates primary DNS server and zone authoritative for the record to be registered.

The client sends to the located DNS server an assertion or prerequisite-only update to verify an existing registration. If the registration does not exist, the client will send the appropriate dynamic update package to register the record.

If the update fails the client will attempt to register the record with other primary DNS server if the authoritative zone is multimaster. If all primary DNS servers failed to process the dynamic update it will be repeated after 5 minutes and, if fails again, after another 10 minutes. If registration still failed, the described pattern of the registration attempts will be repeated after 50 minutes after the last retry.

Dynamic Update of DNS Records

Every computer running Windows 2000 attempts the registration of its A and PTR records. The service that actually generates the DNS dynamic updates is the DHCP client. The DHCP client service runs on every machine regardless of whether it is configured as DHCP client or not.

Windows 2000 White Paper

16

Image 22
Contents Windows 2000 DNS Microsoft Corporation. All rights reserved Contents Designing a DNS Namespace for the Active Directory Summary Page DNS Fundamentals Name Services in Windows Standards and Additional ReadingHistory of DNS Draft-skwan-gss-tsig-04.txt GSS Algorithm for Tsig GSS-TSIGStructure of DNS Hierarchy of DNS Domain NamesMit Mydomain Int/net/orgCom Edu Gov Mil Army Microsoft DNS and InternetTTL Distributing the Database Zone Files and DelegationReplicating the DNS database Microsoft My domain ftp NtserverNEW Features of the Windows 2000 DNS Querying the DatabaseName Server Resolver Root-server Gov Whitehouse.gov Updating the DNS Database Time to Live for Resource RecordsActive Directory Service Storage Model Active Directory Storage and Replication IntegrationWindows 2000 White Paper Replication Model Controlling Access to ZonesZone Type Conversions Incremental Zone Transfer Protocol DescriptionMaster DNS Server Dynamic UpdateZone Log File Slave DNS Server Ixfr and DS IntegrationUpdate Algorithm Dynamic Update of DNS RecordsMixed Environment Dhcp ClientRAS Client Statically Configured ClientSecure Dynamic Update Client ReregistrationEstablishing a security context by passing security tokens Secure Dynamic Update Policy DnsUpdateProxy Group Controlling Update Access to Zones and NamesDNS Admins Group Aging and ScavengingAging and Scavenging Parameters DefaultEnableScavenging Description Scavenging PeriodRecord Life Span Configuring Scavenging Parameters Scavenging AlgorithmUnicode Character Support Interoperability ConsiderationsDomain Locator Finish DNS Record Registration and Resolver Requirements IP/DNS Compatible LocatorLdap.tcp.dc.msdcs.DnsDomainName Kerberos.tcp.dc.msdcs.DnsDomainName IP/DNS DC Locator Algorithm Discovering Site specific DCs FinishCaching Resolver Name Resolution Fully-Qualified QueryUsing Global Suffix Search Order Unqualified Single-Label QueryUsing Primary and Per-adapter Domain Names Unqualified Multi-Label QueryName Resolution Scenarios Unqualified Single-Label Query ScenariosDNS Server List Management Fully-Qualified Query ScenariosMicrosoft Implementation of Negative Caching Negative CachingWMI Support for DNS Server Administration Administrative ToolsDNS Manager Using Wins and Winsr Records Interoperability IssuesUsing UTF-8 Characters Format Receiving Non-RFC Compliant Data DNS Server PerformanceUtilization Server Capacity Planning Hardware components SizingInternet Access Considerations Choosing NamesWindows 2000 White Paper Windows 2000 White Paper Windows 2000 White Paper VPN Com Yyy.com Zzz.com Windows 2000 White Paper Primary Zone YYY corporation ZZZ corporation VPN Firewall Characters in Names Computer NamesFull computer name Per-Adapter NamingIntegrating ADS with Existing DNS Structure Domain name and sites. Active Directory domain name Migration to Windows 2000 DNS DNSDeploying DNS to Support Active Directory Partitioning, and Replication Choosing your ZonesUsing Automatic Configuration Wins ReferralIxfr For More Information IxfrWindows 2000 White Paper