Microsoft Server windows 2000 DNS User Manual

Operating System

Windows 2000 DNS

White Paper

Abstract

This paper describes the Microsoft® Windows® 2000 operating system Domain Naming System (DNS), including design, implementation, and migration issues. It discusses new features of the Windows 2000 implementation of DNS, provides examples of DNS implementations, and describes the architectural criteria that network architects and administrators should consider when designing a DNS namespace for the Active Directory® service to provide reliable network naming services.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, Active Directory, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 1099

CONTENTS

WHITE PAPER ..............................................................................1

CONTENTS....................................................................................3

INTRODUCTION............................................................................5

Name Services in Windows 2000.......................................................................2

Standards and Additional Reading.....................................................................2

DNS FUNDAME N T A L S ... .... .... .... .... .... .... .... .... .... .... .... .... .... ............1

History of DNS....................................................................................................3

The Structure of DNS..........................................................................................4

The Hierarchy of DNS: Domain Names...................... ....................................4

DNS and Internet.............................. .. .. .. .. .. .. .. ................................................ 5

Resource Records..........................................................................................5

Distributing the Database: Zone Files and Delegation...................................6

Replicating the DNS database............................................................................7

Querying the Database.......................................................................................8

NEW FEATURES OF THE WINDOWS 20 00 DNS ........... .. ...............8

Time to Live for Resource Records..............................................................10

Updating the DNS Database............................ .. .. .. .. .........................................1 0

Active Directory Storage and Replication Integration................ . .......................11

The Active Directory Service Storage Model................................................11

The Replication Model..................................................................................13

Zone Type Conversions...............................................................................13

Controlling Access to Zones.........................................................................13

Incremental Zone Transfer................................................................................14

Protocol Description.....................................................................................14

IXFR and DS Integration............................. .. .. .. .. .. .. .....................................15

Dynamic Update...............................................................................................15

Protocol Description.....................................................................................16

Update Algorithm..........................................................................................16

Dynamic Update of DNS Records ............................ .. .. .. .... .. .. .. .. .. .. .. .. .. .. .. .. .1 6

Secure Dynamic Update...............................................................................18

Controlling Update Access to Zones and Names.........................................21

Aging and Scavenging......................................................................................22

Aging and Scavenging Parameters................ ..............................................23

Record Life Span..........................................................................................26

Scavenging Algorithm..................................................................................27

Configuring Scavenging Parameters............................................................27

Unicode Character Support..............................................................................28

Interoperability Considerations.....................................................................28

The Domain Locator.........................................................................................29

IP/DNS Compa t i b le Locator................................. .. .. .. .. .. .. ............................31

Caching Resolver..............................................................................................36

Name Resolution..........................................................................................37

Name Resolution Scenarios.........................................................................40

DNS Server List Management ................................ .. .. .. .... .. .. .. .. .. .. ...............4 1

Negative Caching.........................................................................................41

Disabling the Caching Resolver...................................................................42

Administrative Tools.................. .. .. .. .. .. .. .. .. .. ...................................................... 4 2

DNS Manager.......................... .. .. .. .. .. .. .. .. .. .. .. ............................................... 42

WMI Support for DNS Server Administration...............................................42

Interoperability Issues.......................................................................................43

Using WINS and WINSR Records...............................................................43

Using UTF-8 Characters Format..................................................................43

Receiving Non-RFC Compliant Data............................................................44

DNS Server Performance ................................................................................44

DESIGNING A DNS NAMESPACE FOR THE ACTIVE DIRECTORY.. . 43

Server Capacity Planning.................................................................................45

Choosing Names..............................................................................................46

Internet Access Considerations....................................................................46

Characters in Names.............................. .. .. .. .. .. .. .......................................... 5 5

Computer Names.........................................................................................55

Integrating ADS with Existing DNS Structu r e..................... .. .. .. .. ..................57

Deploying DNS to Support Active Directory......................................................60

Partitioning, and Replication (Choosing your Zones)...................................60

Using Automatic Configuration.....................................................................61

WINS Referral..............................................................................................61

SUMMARY...................................................................................60

For More Information........................................................................................63

GLOSSARY..................................................................................61

DNS FUNDAMENTALS

The designers of the Microsoft ® Windows® 2000 operating system chose the Domain Name System (DNS) as the name service for the operating system. Windows 2000 Server includes an IETF standard-based Domain Name System Server. Because it is RFC compliant it is fully compatible with any other RFC compliant DNS servers. Use of the Windows 2000 Domain Name System server is not mandatory. Any DNS Server implementation supporting Service Location Resource Records (SRV RRs, as described in an Internet Draft “A DNS RR for specifying the location of services (DNS SRV)”) and Dynamic Update (RFC2136) is

sufficient to provide the name service for Windows 2000–based computers

. However, because this implementation of DNS is designed to fully take advantage of the Windows 2000 Active Directory® service, it is the recommended DNS server for any networked organization with a significant investment in Wi ndows or extranet partners with Windows-based systems. For example, while conventional DNS Servers use single-master replication, Windows 2000 DNS can be integrated into Active Directory service, so that it uses the Windows 2000 multi-master replication engine. (Note that the Active Directory supports multi-master replication.) In this way, network managers can simplify system administration by not having to maintain a separate replication topology for DNS.

DNS in Windows 2000 provides a unique DNS Server implementation that is fully interoperable with other standards-based implementations of DNS Server. Some special interoperability issues are discussed later in this paper.

The purpose of this document is to assist network architects and administrators in planning the Windows 2000 Active Directory service DNS deployment strategy. It covers the design, implementation, and migration issues that need to be considered when rolling out a scalable and robust DNS solution as a global name service.

While this paper assumes familiarity with DNS, it provides a quick overview of the DNS basics in ”DNS Fundamentals”. The Windows 2000 implementation of DNS supports various new features (as compared to Windows NT® 4.0 operating system) described in ”New Features of the Windows 2000 DNS.” It includes the description of Active Directory integration and incremental zone transfer (IXFR), dynamic (including secure) update and Unicode character support, enhanced Domain Locator, caching resolver service and DNS Manager. It provides the detailed overview of the name resolution process. It also describes the support for secure DNS management. It includes an overview of the various issues associated with designing namespace for the Active Directory. It includes integration of Active Directory with existing DNS structure and migration to the Windows 2000 implementation of DNS, design of the private namespaces and necessary DNS support.

Berkeley Internet Name Domain - BIND 8.1.1 DNS Server implementation supports both SRV RRs and Dynamic Update, but it dumps core when Windows 2000-based clients send certain updates to it. 8.1.2 is the first BIND version that works reliably.

Windows 2000 White Paper

Name Services in Windows 2000

DNS is the name service of Windows 2000. It is by design a highly reliable, hierarchical, distributed, and scalable database. Windows 2000 clients use DNS for name resolution and service location, includi ng locating domain controllers for logon.

Downlevel clients (Windows NT 3.5 and 3.51, Windows NT 4.0, Windows 95, and Windows 98), however, rely on NetBIOS which can use NBNS (WINS), broadcast or flat LmHosts file. In particular, the NetBIOS name service is used for domain controller location.

Since DNS as implemented in Windows 2000 is Windows Internet Name Services (WINS)-aware, a combination of both DNS and WINS can be used in a mixed environment to achieve maximum efficiency in locating various network services and resources. Additionally, WINS in a legacy or mixed environment plays an important interoperability role while also preserving current investment. Windows NT 4.0–based clients can register themselves in Windows 2000 WINS and Windows 2000–based clients can register in Windows NT 4.0 WINS.

Standards and Additional Reading

The following documents are of interest in the context of the Windows 2000 DNS Server implementation. They are combined in two categories. A RFC—Request For Comments—is a standard document, while Draft is work in progress that can become a standard.

RFCs:

• 1034 Domain Names—Concepts and Facilities

• 1035 Domain Names—Implementation and Specification

• 1123 Requirements for Internet Hosts—Application and Support

• 1886 DNS Extensions to Support IP Version 6

• 1995 Incremental Zone Transfer in DNS

• 1996 A Mechanism for Prompt DNS Notification of Zone Changes

• 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)

• 2181 Clarifications to the DNS Specification

• 2308 Negative Caching of DNS Queries (DNS NCACHE)

Drafts:

• Draft-ietf-dnsind-rfc2052bis-02.txt (A DNS RR for Specifying the Location of

Services (DNS SRV))

• Draft-skwan-utf8-dns-02.txt (Using the UTF-8 Character Set in the Domain

Name System)

• Draft-ietf-dhc-dhcp-dns-08.txt (Interaction between DHCP and DNS)

• Draft-ietf-dnsind-tsig-11.txt (Secret Key Transaction Signatures for DNS

(TSIG))

• Draft-ietf-dnsind-tkey-00.txt (Secret Key Establishment for DNS (TKEY RR))

Windows 2000 White Paper 2

• Draft-skwan-gss-tsig-04.txt (GSS Algorithm for TSIG (GSS-TSIG) )

For more information on these documents, go to http://www.ietf.org/

In addition to the listed RFCs and Drafts the implementation of the ATMA DNS records is based on the “ATM Name System Specification Version 1.0”.

Additional reading:

• Microsoft DNS and Windows NT 4.0 White Paper

(http://www.microsoft.com/windows/downloads/bin/nts/DNSWP.e xe

)

• Designing the Active Directory Structure chapter in the Deployment

Planning Guide

• Active Directory papers

http://www.microsoft.com/windows2000/library/technologies/activedirectory/def ault.asp

• ”DNS and BIND” (Cricket Liu) published by O'Reilly and Associates, 3rd Edition

ISBN: 1-56592-512-2 The Domain Name System is a hierarchical distributed database and an associated set of protocols that define:

• A mechanism for querying and updating the database

• A mechanism for replicating the information in the database among servers

• A schema of the database

History of DNS

DNS began in the early days of the Internet when the Internet was a small network established by the Department of Defense for research purposes. The host names of the computers in this network were managed through the use of a single HOSTS file located on a centrally administered server. Each site that needed to resolve host names on the network downloaded this file. As the number of hosts on the Internet grew, the traffic generated by the update process increased, as well as the size of the HOSTS file. The need for a new system, which would offer features such as scalability, decentralized administration, support for various data types, became more and more obvious.

The Domain Name System (DNS) introduced in 1984, became this new system. With DNS, the host names reside in a database that can be distributed among multiple servers, decreasing the load on any one server and providing the ability to administer this naming system on a per-partition basis. DNS supports hierarchical names and allows registration of various data types in addition to host name to IP address mapping used in HOSTS files. By virtue of the DNS database being distributed, its size is unlimited and performance does not degrade much when adding more servers.

The original DNS was based on RFC 882 (Domain names: Concepts and facilities) and RFC 883 (Domain Names–Implementation and Specification), which were

Windows 2000 White Paper

superceded by RFC 1034 (Domain Names–Concepts and Facilities), and RFC 1035 (Domain Names–Implementation and Specification). RFCs that describe DNS security, implementation, and administrative issues later augmented these.

The implementation of DNS—Berkeley Internet Name Domain (BIND)—was originally developed for the 4.3 BSD UNIX operating system.

The Microsoft implementation of DNS Server became a part of the operating system in Windows NT Server 4.0. The Windows NT 4.0 DNS Server, like most DNS implementations, has its roots in RFCs 1034 and 1035.

The latest version of the Windows 2000 operating system includes a new version of DNS. The RFCs used in this version are 1034, 1035, 1886, 1996, 1995, 2136, 2308 and 2052.

The Structure of DNS

The Domain Name System is implemented as a hierarchical and distributed database containing various types of data including host names and domain names.

The names in a DNS database form a hierarchical tree structure called the domain name space.

The Hierarchy of DNS: Domain Names

Domain names consist of individual labels separat ed by dots. For example:

mydomain.microsoft.com.

A Fully Qualified Domain Name (FQDN) uniquely identifies the host’s position within the DNS hierarchical tree by specifying a list of names separated by dots on the path from the referenced host to the root. The following figure shows an example of a DNS tree with a host called mydomain within the microsoft.com. domain. The FQDN for the host would be mydomain.microsoft.com.

Windows 2000 White Paper 4

Managed by

Registration

uthorit

int/net/org

com

edu gov mil

microsoft

whitehouse

mit

mydomain

army

Managed by

Microsoft

DNS and Internet

The Internet Domain Name System is managed by a Name Registration Authority on the Internet, responsible for maintaining top-level domains that are assigned by organization and by country. These domain names follow the International Standard

3166. Existing abbreviations, reserved for use by organizations, as well as twoletter and three-letter abbreviations used for countries, are shown in the following table.

DNS Domain Name Type of Organization

com Commercial organizations edu Educational institutions org Non-profit organizations net Networks (the backbone of the I nternet) gov Non-military government organizations

DNS Domain Name Type of Organization

mil Military government organizations num Phone numbers arpa Reverse DNS xx Two-letter country code

Resource Records

A DNS database consists of resource records (RRs). Each RR identifies a particular resource within the database. There are various types of RRs in DNS.

The following table provides detailed information on structure of common RRs (Note: this is not an exhaustive list of RRs).

Windows 2000 White Paper

Description Class TTL Type Data

Start of Authority Internet (IN) Default TTL is

60 minutes

Host Internet (IN) Zone (SOA)

TTL

Name Server Internet (IN) Zone (SOA)

TTL

Mail Exchanger Internet (IN) Zone (SOA)

TTL

Canonical Name (an alias)

Internet (IN) Zone (SOA)

TTL

SOA Owner Name,

Primary Name Server DNS Name, Serial Number,

Refresh Interval, Retry Interval, Expire Time, Minimum TTL

A Owner Name (Host DNS

Name), Host IP Address

NS Owner Name,

Name Server DNS Name

MX Owner Name,

Mail Exchange Server DNS Name, Preference Number

CNAME Owner Name (Alias

Name), Host DNS Name

Distributing the Database: Zone Files and Delegation

A DNS database can be partitioned into multiple zones. A zone is a portion of the DNS database that contains the resource records with the owner names that belong to the contiguous portion of the DNS namespace. Zone files are maintained o n DNS servers. A single DNS server can be configured to host zero, one or multiple zones.

Each zone is anchored at a specific domain name referred to as the zone’s root domain. A zone contains information about all names that end with the zone’s root domain name. A DNS server is considered authoritative for a name if it loads the zone containing that name. The first record in any zone file is a Start of Authority (SOA) RR. The SOA RR identifies a primary DNS name server for the zone as the best source of information for the data within that zone and as an entity processing the updates for the zone.

Names within a zone can also be delegated to other zone(s). Delegation is a process of assigning responsibility for a portion of a DNS namespace to a separate entity. This separate entity could be another organization, department or workgroup within your company. In technical terms, delegating means assigning authority over portions of your DNS namespace to other zones. Such delegation is represented by the NS record that specifies the delegated zone and the DNS name of the server authoritative for that zone. Delegating across multiple zones was part of the original design goal of DNS. Following are the main reasons for the delegation of a DNS namespace:

Windows 2000 White Paper 6

• A need to delegate management of a DNS domain to a number of

organizations or departments within an organization

• A need to distribute the load of maintaining one large DNS database among

multiple name servers to improve the name resolution performance as well as

create a DNS fault tolerant environment

• A need to allow for host’s organizational affiliation by including them in

appropriate domains

The NS RRs facilitate delegation by identifying DNS servers for each zone. They appear in all forward and reverse look-up zones. Whenever a DNS server needs to cross a delegation, it will refer to the NS RRs for DNS servers in the target zone.

In the figure below, the management of the microsoft.com domain is delegated across two zones, microsoft.com. and mydomain.microsoft.com.

com edu gov

...

microsoft

mydomain

mydomain.microsoft.com

Zone

ftp

...

ntserver

microsoft.com

Zone

microsoft.com Domain

Note: If multiple NS records exist for a delegated zone identifying multiple DNS servers available for querying, the Windows 2000 DNS server will be able to select the closest DNS server based on the round trip intervals measured over time for every DNS server.

Replicating the DNS database

There could be multiple zones representing the same portion of the namespace. Among these zones there are two types:

• Primary

• Secondary

Primary is a zone to which all updates for the records that belong to that zone are made. A secondary zone is represented by a read-only copy of the primary zone.

Windows 2000 White Paper

NEW FEATURES OF THE WINDOWS 2000 DNS

The changes made to the primary zone file are then replicated to the secondary zone file.

As mentioned above, a name server can host multiple zones. A server can therefore be primary for one zone (it has the master copy of the zone file) and secondary for another zone (it gets a read-only copy of the zone file).

The process of replicating a zone file to multiple name servers is called zone transfer. Zone transfer is achieved by copying the zone file information from the master server to the secondary server.

A master server is the source of the zone information. The master server can be primary or secondary. If the master is primary, then the zone transfer comes directly from the source. If the master server is secondary, the file received from the master server by means of a zone transfer is a copy of the read-only zone file.

The zone transfer is initiated in one of the following ways:

• The master server sends a notification (RFC 1996) to the secondary server(s)

of a change in the zone.

• When the seconda ry server’s DNS service starts or the secondary server’s

refresh interval has expired (by default it is set to 15 minutes in the SOA RR), it

will query the primary server for the changes.

There are two types of zone file replication. The first, full zone transfer (AXFR), replicates the entire zone file. The second, incremental zone transfer (IXFR), replicates only the changed records of the zone. The IXFR protocol is discussed in “Incremental Zone Transfer."

BIND 4.9.3 DNS ser v ers, as well as Windows NT 4.0 DNS, suppo r t f u ll zon e transfer (AXFR) only. There are two types of the AXFR: one requires single record per packet, the other allows multiple records per packet. The Windows 2000 DNS server supports both, but by default uses multiple records per packet, unless is configured differently for compatibility with BIND versions 4.9.4 and earlier, that do not allow multiple records per packet. The Windows 2000 DNS server supports incremental zone transfer (IXFR).

Querying the Database

DNS queries can be sent from a client (resolver) to a DNS server (a name server), or between two name servers.

A query is merely a request for records of a specified type with a specified name. For example, a query can request all host RRs with a particular name.

There are two types of queries that can be made to a DNS server:

• Recursive

• Iterative

Windows 2000 White Paper 8

A recursive query forces a DNS server to respond to a request with either a failure

or a successful response. Resolvers typically make recursive queries. With a recursive query, the DNS server must contact any other DNS servers it needs to resolve the request. When it receives a successful response from the other DNS Server(s), it then sends a response to the client. The recursive query is typical for a resolver querying a name server and for a name server querying its forwarder (another name server configured to handle requests forwarded to it).

When a DNS server processes a recursive query and a query can not be resolved from local zone files, the query must be escalated to a root DNS server. Each standards-based implementation of DNS includes a cache file (or root server hints) that contains entries for Root Servers of the Internet domains. The latest version of the named cache file can be downloaded from InterNIC at

ftp://rs.internic.net/domain/named.cache

An iterative query is one in which the name server is expected to prov ide the best information (also known as referral if the server is not authoritative for the name) based on what the server knows from local zone files or from caching. If a name server doesn’t have any information to answer the query, it simply sends a negative response. A non-forwarding DNS server makes this type of query as it tries to find names outside its local domain(s). It may have to query a number of outside DNS Servers in an attempt to resolve the name.

The following figure shows an example of both types of queries.

Name Server

Resolver

2 3

4 5

6 7

client asks for IP

address for

www.whitehouse.gov

Name Server

(root-server)

gov

Name Server

whitehouse.gov

Name Server

iterative queries

recursive query

gov

whitehouse

www

In the provided example the following queries are used to determine IP address for

Windows 2000 White Paper

www.whitehouse.gov:

• Recursive query for www.whitehouse.gov (A RR)

• Iterative query for www.whitehouse.gov (A RR)

• Referral to the gov name server (NS RRs, for gov); for simplicity iterative A

queries by the DNS server (on the left) to resolve the IP addresses of the Host

names of the name servers returned by other DNS servers have been omitted.

• Iterative query for www.whitehouse.gov (A RR)

• Referral to the whitehouse.gov name server (NS RR, for whitehouse.gov)

• Iterative query for www.whitehouse.gov (A RR)

• Answer from whitehouse.gov server (the IP address for www.whitehouse.gov)

• Answer from local DNS server to Resolver (the IP address for

www.whitehouse.gov)

Time to Live for Resource Records

A resolver caches the information it receives when it resolves queries. These cached responses can then be used to answer subsequent queries for the same information. The cached data, however, has a limited lifetime specified in the Time To Live (TTL) parameter returned with the data. TTL makes sure the DNS Server doesn’t keep information for so long that it becomes out of date. TTL for the cache can be set on the DNS database (per individual RR by specifying the TTL field of the record and per zone through the minimum TTL field of the SOA record) as well as on the resolver side by specifying the maximum TTL the resolver allows to cache the resource records.

There are two competing factors to consider when setting the time to live. One is the accuracy of the cached information, the other is the DNS server’s utilization and the network traffic. If the TTL is short, then the likelihood of having old information goes down considerably, but increases the DNS servers utilization and the network traffic. If the TTL is long, the cached responses could become outdated, meaning the resolver could give false answers to queries. At the same time a long TTL decreases the DNS server’s utilization and the network traffic. If a query is answered with an entry from cache, the TTL of the entry is also passed with the response. This way the resolvers that receive the response know how long the entry is valid. The resolvers honor the TTL from the responding server; they don’t set it again based on their own TTL. Thus entries truly expire rather than live in perpetuity as they move from server to server with an updated TTL.

Updating the DNS Database

Since the RRs in the zone files are subjected to changes, they must be updated. The implementation of DNS in Windows 2000 supports both static and dynamic updates of the DNS database. The details of the dynamic update are discussed later in the paper.

The new features of Windows 2000 DNS include:

• Active Directory service Integration

Windows 2000 White Paper 10

• Incremental Zone Transfer (IXFR)

• Dynamic Update and Se cure Dynamic Update

• Unicode Character Support

• Enhanced Domain Locator

• Enhanced Caching Resolver Service

• Enhanced DNS Manager

Active Directory Storage and Replication Integration

In addition to supporting a conventional way of maintaining and replicating DNS zone files, the implementation of DNS in Wi ndows 2000 has the option of using the Active Directory services as the data storage and replication engine. This approach provides the following benefits:

• DNS replication will be performed by Active Directory service, so there is no

need to support a separate replication topology for DNS servers.

• Active Directory service replication provides per-property replication granularity.

• Active Directory service replication is secure.

• A primary DNS server is eliminated as a single point of failure. Original DNS

replication is single-master; it relies on a primary DNS server to update all the

secondary servers. Unlike original DNS replication, Active Directory service

replication is multi-master; an update can be made to any domain controller in

it, and the change will be propagated to other domain controllers. In this way if

DNS is integrated into Active Directory service the replication engine will

always synchronize the DNS zone information.

Thus Active Directory service integration significantly simplifies the administration of a DNS namespace. At the same time standard zone transfer to other servers (non Windows 2000 DNS servers and previous versions of the Microsoft DNS servers) is still supported.

The Active Directory Service Storage Model

The Active Directory service is an object-oriented X.500-compliant database, which organizes resources available on your network in a hierarchical tree-like structure. This database is managed by the set of Domain Controllers (DC). The portion of the Active Directory service database for which a specific DC is authoritative is physically located on the same computer where the DC is. Every resource in Active Directory service is represented by an object. There are two distinct types of objects supported by Active Directory service:

• Containers–objects that can contain other container and leaf objects

• Leafs–objects representing a specific resource within the Active Directory

service tree

Windows 2000 White Paper

Each Active Directory service object has attributes associated with it that define particular characteristics of the object.

The classes of objects in the Active Directory service database as well as each object’s attributes are defined in the Active Directory service schema. In other words, the schema contains definitions for each class object available in Active Directory service. The following are examples of the Active Directory service class objects:

• User

• Group

• Organizational Unit

• DnsZone

• DnsNode

In DS integrated DNS, each DNS zone becomes an Active Directory service container object (DnsZone). The DnsZone object will contain a DnsNode leaf object for every unique name within that zone. The DnsNode object will have a DnsRecord multi-valued attribute with an instance of a value for every record associated with the object’s name.

Windows 2000 White Paper 12

In the screen shot above, the object mail.mydomain.microsoft.com may have the A attribute containing the IP address for mail.mydomain.microsoft.com. and the MX attribute containing the mail exchange server information for mail.mydomain.microsoft.com.

Note: Only DNS servers running on domain controllers can load DS integrated zones.

The Replication Model

Since DNS zone information is now stored in Active Directory service, whenever an update is made to a DNS server, it simply writes the data to Active Directory and continues performing its usual functions. Active Directory service is now responsible for replicating the data to other domain controllers. The DNS servers running on other DCs will poll the updates from the DS.

Because Active Directory service uses the multi-master replication model, DNS updates can be written to any DS integrated DNS server, and the data will automatically be replicated across all the domain controllers. The multi-master replication model, however, does have some caveats that are worth discussing. The ability to write to Active Directory service from multiple domain controllers at the same time can create a conflicting situation where the changes are made to the same object on two different DNS servers. The conflict will eventually be resolved in favor of the last update made to the object based on the timestamps of the updates. The same rule is applied in the case where two or more nodes with the same name are created on two or more DNS servers. Until the conflict is resolved and the DNS server, containing invalid update, polls the valid data from the DS, it is possible that requests for the same object made to two different DNS servers will be resolved differently. This is why the ADS database is called loosely consistent.

Note: This subsection described the replication model b etween different copies of the DS integrated zones only. There are implemented two other replication models corresponding to the zone transfer between non-DS-integrated primary and secondary zone files and between DS integrated primary and secondary zone files, described below in the sections on “Protocol Description” and “IXFR and DS Integration” respectively.

Zone Type Conversions

It is possible to convert any type of existing DNS zone to any other type. The issues surrounding the primary zone conversions are of the most interest.

If a DS integrated zone is converted to an original (non-DS-integrated) primary zone file, the DNS server loading the new primary zone must become the single primary of the zone for the update. Therefore, the converted zone has to be deleted from Active Directory service (namely from all DC databases previously authoritative for this zone) so that the outdated or incorrect information is not being replicated.

Controlling Access to Zones

Active Directory service integration provides another valuable feature—the Secure Dynamic DNS Updates. The DS maintains the Acc ess Control Lists (ACL) specifying groups or users who are allowed to modify the DS-integrated zones.

Windows 2000 White Paper

Note that only DNS server supports the Secure Dynamic Updates for the DSintegrated zones. Windows 2000 implementation provides even finer granularity allowing per-name ACL specification. More details we consider ACLs and specific Administrative groups later in “Controlling Update Access to Zones and Names.”

Incremental Zone Transfer

To reduce latency in propagation of changes to a DNS database, an algorithm has to be employed that actively notifies name servers of the change. This is accomplished by the NOTIFY extension of the DNS. The NOTIFY packet, which is sent by a Master server, does not contain any zone changes information. It merely notifies the other party that some changes have been made to a zone and that a zone transfer needs to be initiated.

The full zone transfer mechanism (AXFR) is not an efficient means to propagate changes to a zone, as it transfers the entire zone file. Incremental transfer (IXFR) is a more efficient mechanism, as it transfers only the changed portion(s) of the zone. The IXFR protocol is defined in RFC 1995.

Protocol Description

When a slave name server capable of IXFR (IXFR client) initiates a zone transfer, it sends an IXFR message containing the SOA serial number of its copy of the zone.

A master name server responding to the IXFR request (IXFR server) keeps a record of the newest version of the zone and the differences between that copy and several older versions. When an IXFR request with an older serial number is received, the IXFR server sends only the changes required to make the IXFR client’s version current. In some cases, however, a full zone transfer may be chosen instead of an incremental transfer:

• The sum of the changes is larger than the entire zone.

• Only a limited number of recent changes to the zone are kept on the server for

performance reasons. If the client’s serial number is lower than the one the

server has in its delta changes, a full zone transfer will be initiated.

• If a name server responding to the IXFR request, does not recognize the query

type, the IXFR client will automatically initiate an AXFR instead.

Windows 2000 White Paper 14

The following diagram details the incremental transfer mechanism.

Master DNS

Server

Serial Number 12

changes

Serial Number 11

Slave DNS

Server 1

Serial Number 11

changes

Zone Log File

Serial Number 10

changes

Serial Number 8

Serial Number 10

Slave DNS

Server 2

Slave DNS

Server 3

IXFR and DS Integration

As was mentioned above, IXFR is an order-based protocol, which will send the zone changes based on differences in the zone serial numbers. In a DS integrated multi-master environment, changes to a DNS zone can be applied to any master server. Therefore, different master servers will contain the zone changes applied in a different order. This can cause problems in situations where a master IXFR server that provided the zone changes to an IXFR client the last time is not available. If the IXFR client selects another master server with zone changes applied in a different order, the integrity of the IXFR client’s zone may be compromised after the incremental transfer. In this case the server initiating a zone transfer will request AXFR.

In summary, the DNS server could be a Slave and a Master with respect to the same zone at the same time. This can happen if the zone is replicated from the Master, server1, to the Slave, server2, and further from the Master, server2, to the Slave, server3. (This chain could continue further, but regardless of its length it obeys the rules described in this Section.) In this scenario the server2 will support IXFR to the server3 as long as it receives IXFR from the server1.

Dynamic Update

In a conventional DNS implementation, if the authoritative information must be changed, the network administrator has to edit the appropriate zone file manually. The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone’s primary master file.

The advent of dynamic, automated IP addressing using DHCP and related

Windows 2000 White Paper

+ 49 hidden pages