http://technet.microsoft.

com

DNS
Domain Name System (DNS) is one of the industry-standard suite of protocols that comprise TCP/IP. Microsoft Windows Server 2003. DNS is implemented using two software components: the DNS server and the DNS client (or resolver). Both components are run as background service applications. Network resources are identified by numeric IP addresses, but these IP addresses are difficult for network users to remember. The DNS database contains records that map user-friendly alphanumeric names for network resources to the IP address used by those resources for communication. In this way, DNS acts as a mnemonic device, making network resources easier to remember for network users. The Windows Server 2003 DNS Server and Client services use the DNS protocol that is included in the TCP/IP protocol suite. DNS is part of the application layer of the TCP/IP reference model. DNS in TCP/IP

For more information and to view logical diagrams illustrating how DNS fits with other Windows Server 2003 technologies, see How DNS Works" in this collection. By default, Windows Server 2003 DNS is used for all name resolution in a Windows Server 2003 network. In the most typical scenario, when a Windows Server 2003 network user specifies the name of a network host or an internet DNS domain name, the DNS Client service running on the Windows Server 2003 computer of the user contacts a DNS server to resolve the name to an IP address.

Technologies That Use DNS

DNS and Active Directory
Windows Server 2003 Active Directory directory service uses DNS as its domain controller location mechanism. When any of the principal Active Directory operations is performed, such as authentication, updating, or searching, Windows Server 2003 computers use DNS to locate Active Directory domain controllers and these domain controllers use DNS to locate each other. For example, when a network user with an Active Directory user account logs in to an Active Directory domain, the users computer uses DNS to locate a domain controller for the Active Directory domain to which the user wants to log in. For more information about integrating DNS and Active Directory, see How DNS Works" in this collection.

DNS and WINS

The earlier method of name resolution for a Windows network was Windows Internet Name Service (WINS). DNS is different than WINS in that DNS is a hierarchical namespace and WINS is a flat namespace. Down-level clients and applications that rely on NetBIOS names continue to use WINS for name resolution. Since Windows Server 2003 DNS is 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. For more information about using DNS in a mixed environment, see How DNS Works" in this collection.

DNS and DHCP

For Windows Server 2003 DNS, the DHCP service provides default support to register and update information for legacy DHCP clients in DNS zones. Legacy clients typically include other Microsoft TCP/IP client computers that were released prior to Windows 2000. The Windows Server 2003 DNSDHCP integration enables a DHCP client that is unable to dynamically update DNS resource records directly to have this information updated in DNS forward and reverse lookup zones by the DHCP server.

DNS Architecture
DNS architecture 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.

DNS originated in the early days of the Internet when the Internet was a small network established by the United States 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 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. Because the DNS database is distributed, its potential size is unlimited and performance is not degraded when more servers are added. The original DNS was based on Request for Comment (RFC) 882 (Domain Names: Concepts and Facilities) and RFC 883 (Domain NamesImplementation and Specification), which were superseded by RFC 1034 (Domain NamesConcepts and Facilities), and RFC 1035 (Domain Names Implementation and Specification). Additional RFCs that describe DNS security, implementation, and administrative issues later augmented the original design specifications. 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 became a part of the operating system in Microsoft 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 RFCs used in Microsoft Windows 2000 and Windows Server 2003 operating systems are 1034, 1035, 1886, 1996, 1995, 2136, 2308, and 2052.

DNS Domain Names

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 namespace. Domain names consist of individual labels separated by dots, for example: mydomain.microsoft.com.

A Fully Qualified Domain Name (FQDN) uniquely identifies the hosts position within the DNS hierarchical tree by specifying a list of names separated by dots in the path from the referenced host to the root. The next 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.

Understanding the DNS Domain Namespace

The DNS domain namespace, as shown in the following figure, is based on the concept of a tree of named domains. Each level of the tree can represent either a branch or a leaf of the tree. A branch is a level where more than one name is used to identify a collection of named resources. A leaf represents a single name used once at that level to indicate a specific resource. DNS Domain Name Hierarchy

The previous figure shows how Microsoft is assigned authority by the Internet root servers for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers use queries as the fundamental method of resolving names in the tree to specific types of resource information. This information is provided by DNS servers in query responses to DNS clients, who then extract the information and pass it to a requesting program for resolving the queried name. In the process of resolving a name, keep in mind that DNS servers often function as DNS clients, querying other servers in order to fully resolve a queried name.

How the DNS Domain Namespace Is Organized

Any DNS domain name used in the tree is technically a domain. Most DNS discussions, however, identify names in one of five ways, based on the level and the way a name is commonly used. For example, the DNS domain name registered to Microsoft (microsoft.com.) is known as a second-level domain. This is because the name has two parts (known as labels) that indicate it is located two levels below the root or top of the tree. Most DNS domain names have two or more labels, each of which indicates a new level in the tree. Periods are used in names to separate labels. The five categories used to describe DNS domain names by their function in the namespace are described in the following table, along with an example of each name type. Types of DNS Domain Names

Name Type

Description

Example

Root domain

This is the top of the tree, representing an unnamed level; it is sometimes shown as two empty quotation marks (""), indicating a null value. When used in a DNS domain name, it is stated by a trailing period (.) to designate that the name is located at the root or highest level of the domain hierarchy. In this instance, the DNS domain name is considered to be complete and points to an exact location in the tree of names. Names stated this way are called fully qualified domain names (FQDNs). A name used to indicate a country/region or the type of organization using a name.

A single perio end of a name, example.micr

Top level domain

.com, whic to a business f Internet.

Second level domain

Variable-length names registered to an individual or organization for use on the Internet. These names are always based upon an appropriate top-level domain, depending on the type of organization or geographic location where a name is used. Additional names that an organization can create that are derived from the registered second-level domain name. These include names added to grow the DNS tree of names in an organization and divide it into departments or geographic locations. Names that represent a leaf in the DNS tree of names and identify a specific resource. Typically, the leftmost label of a DNS domain name identifies a specific computer on the network. For example, if a name at this level is used in a host (A) RR, it is used to look up the IP address of computer based on its host name.

microsoft.co level domain n by the Internet

Subdomain

example.mic fictitious subd for use in docu

Host or resource name

host-a.exam the first label ( name for a spe network.

DNS and Internet Domains

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/region. These domain names follow the International Standard 3166. Some of the many existing abbreviations, reserved for use by organizations, as well as two-letter and three-letter abbreviations used for countries/regions are shown in the following table: Some DNS Top-level Domain Names (TLDs)

DNS Domain Name

Type of Organization

com

Commercial organizations

edu org net gov mil arpa xx

Educational institutions Non-profit organizations Networks (the backbone of the Internet) Non-military government organizations Military government organizations Reverse DNS Two-letter country code (i.e. us, au, ca, fr)

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. This section provides information about the common structure of resource records. RRs are discussed in greater detail in Resource Records in DNS later in this document. The following table provides detailed information about structure of common RRs. Common DNS Resource Records

Description

Class

Time To Live (TTL)

Type

Data

Start of Authority

Internet (IN)

Default TTL is 60 minutes

SOA

Owner N Primary N Serial Nu Refresh I Retry Inte Expire Ti Minimum

Host

Internet (IN) Internet (IN) Internet (IN)

Record-specific TTL if present, or else zone (SOA) TTL Record-specific TTL if present, or else zone (SOA) TTL Record-specific TTL if present, or else zone (SOA) TTL

Owner N Host IP A

Name Server

NS

Owner N Name Ser

Mail Exchanger

MX

Owner N Mail Exc Preferenc

Canonical Name (an alias)

Internet (IN)

Record-specific TTL if present, or else zone (SOA) TTL

CNAME

Owner N Host DNS

Distributing the DNS 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 on 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 zones root domain. A zone contains information about all names that end with the zones 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. A name within a zone can also be delegated to a different zone that is hosted on a different DNS server. Delegation is a process of assigning responsibility for a portion of a DNS namespace to a DNS server owned by a separate entity. This separate entity could be another organization, department or workgroup within your company. Such delegation is represented by the NS resource 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. The primary reasons to delegate a DNS namespace include: 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 DNS servers to improve the name resolution performance as well as create a DNS fault tolerant environment. A need to allow for a hosts organizational affiliation by including them in appropriate domains.

The name server (NS) RRs facilitate delegation by identifying DNS servers for each zone and the NS RRs appear in all zones. Whenever a DNS server needs to cross a delegation in order to resolve a name, 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. DNS Delegation

Note If multiple NS records exist for a delegated zone identifying multiple DNS servers available for querying, the Windows Server 2003 DNS Server service 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 three types: Primary Secondary Stub

Primary is a zone to which all updates for the records that belong to that zone are made. A secondary zone is a read-only copy of the primary zone. A stub zone is a read-only copy of the primary zone that contains only the resource records that identify the DNS servers that are authoritative for a DNS domain name. Any changes made to the primary zone file are replicated to the secondary zone file. DNS servers hosting a primary, secondary or stub zone are said to be authoritative for the DNS names in the zone. As mentioned above, a DNS server can host multiple zones. A DNS server can therefore host both a primary zone (which has the writeable copy of a zone file) and a separate secondary zone (which obtains a read-only copy of a zone file). A DNS server hosting a primary zone is said to be the primary DNS server for that zone, and a DNS server hosting a secondary zone is said to be the secondary DNS server for that zone. Note

A secondary or stub zone cannot be hosted on a DNS server that hosts a primary zone for the same domain name.

Zone Transfer
The process of replicating a zone file to multiple DNS servers is called zone transfer.Zone transfer is achieved by copying the zone file from one DNS server to a second DNS server. Zone transfers can be made from both primary and secondary DNS servers. A master DNS server is the source of the zone information during a transfer. The master DNS server can be a primary or secondary DNS server. If the master DNS server is a primary DNS server, then the zone transfer comes directly from the DNS server hosting the primary zone. If the master server is a secondary DNS server, then the zone file received from the master DNS server by means of a zone transfer is a copy of the read-only secondary zone file. The zone transfer is initiated in one of the following ways: The master DNS server sends a notification (RFC 1996) to one or more secondary DNS servers of a change in the zone file. When the DNS Server service on the secondary DNS server starts, or the refresh interval of the zone has expired (by default it is set to 15 minutes in the SOA RR of the zone), the secondary DNS server will query the master DNS server for the changes.

Types of Zone File Replication

There are two types of zone file replication. The first, a full zone transfer (AXFR), replicates the entire zone file. The second, an incremental zone transfer (IXFR), replicates only records that have been modified. Zone transfer is discussed in detail later in this document. BIND 4.9.3 and earlier DNS server software, as well as Windows NT 4.0 DNS, support full zone 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 and Windows Server 2003 DNS Server service supports both types of zone transfer, but by default uses multiple records per packet. It can be configured differently for compatibility with servers that do not allow multiple records per packet, such as BIND servers versions 4.9.4 and earlier.

Querying the Database

DNS queries can be sent from a DNS client (resolver) to a DNS server, or between two DNS servers. A DNS query is merely a request for DNS resource records of a specified resource record type with a specified DNS name. For example, a DNS query can request all resource records of type A (host) with a specified DNS name. There are two types of DNS queries that may be sent to a DNS server: Recursive Iterative

A recursivequery forces a DNS server to respond to a request with either a failure or a successful response. DNS clients (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 DNS client. The recursive query is the typical query type used by a resolver querying a DNS server and by a DNS server querying its forwarder, which is another DNS server configured to handle requests forwarded to it. For more information about forwarders, see Forwarding later in this document. When a DNS server processes a recursive query and the query cannot be resolved from local data (local zone files or cache of previous queries), the recursive 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 the root DNS servers of the Internet domains. (If the DNS server is configured with a forwarder, the forwarder is used before a root server is used.) An iterative query is one in which the DNS server is expected to respond with the best local information it has, based on what the DNS server knows from local zone files or from caching. This response is also known as a referral if the DNS server is not authoritative for the name. If a DNS server does not have any local information that can answer the query, it simply sends a negative response. A DNS server makes this type of query as it tries to find names outside of its local domain(s) (when it is not configured with a forwarder). 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. DNS Query Types

As shown in the graphic above, a number of queries were used to determine the IP address for www.whitehouse.gov. The query sequence is described below: 1. 2. 3. Recursive query for www.whitehouse.gov (A resource record) Iterative query for www.whitehouse.gov (A resource record) Referral to the .gov name server (NS resource records, 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 resource record) Referral to the whitehouse.gov name server (NS resource record, for whitehouse.gov) Iterative query for www.whitehouse.gov (A resource record) Answer to the interative query from whitehouse.gov server (www.whitehouse.govs IP address) Answer to the original recursive query from local DNS server to Resolver (www.whitehouse.govs IP address)

4. 5. 6. 7. 8.

Time to Live for Resource Records

The Time to Live (TTL) value in a resource record indicates a length of time used by other DNS servers to determine how long to cache information for a record before expiring and discarding it. For example, most resource records created by the DNS Server service inherit the minimum (default) TTL of one hour from the start of authority (SOA) resource record, which prevents extended caching by other DNS servers. A DNS client resolver caches the responses it receives when it resolves DNS queries. These cached responses can then be used to answer later queries for the same information. The cached data, however, has a limited lifetime specified in the TTL parameter returned with the response data. TTL ensures that the DNS server does not keep information for so long that it becomes out of date. TTL for the cache can be set on the DNS database (for each individual resource record, 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 DNS client 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 TTL. The first is the accuracy of the cached information, and the second is the utilization of the DNS servers and the amount of network traffic. If the TTL is short, then the likelihood of having old information is reduced considerably, but it increases utilization of DNS servers and network traffic, because the DNS client must query DNS servers for the expired data the next time it is requested. 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 utilization of DNS servers and reduces network traffic because the DNS client answers queries using its cached data. 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 do not reset it based on their own TTL. Consequently, entries truly expire rather than live in perpetuity as they move from DNS server to DNS server with an updated TTL. Note In general, never configure the TTL to zero. The different between a setting of 0 or 60 is minimal to the accuracy of the record, but when the TTL is set to 0 there is a major impact on DNS server performance because the DNS server is constantly querying for the expired data.

Updating the DNS Database

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

DNS Architecture Diagrams

The following diagrams illustrate how the DNS Client and Server services work and provide additional information regarding name resolution, update, and administration operations. The first diagram illustrates the DNS Client service architecture in its name resolution and update operations. In this diagram, name resolution architecture is demonstrated using a Web browser and Microsoft Outlook and updates are represented by the DHCP client. DNS Client Service Architecture

The following diagram illustrates the DNS Server service architecture with its administration tools and the Windows Management Instrumentation (WMI) interface. DNS Server Service Architecture

DNS Protocol
The DNS protocol consists of DNS different types of DNS messages that are processed according to the information in their message fields. This section discusses the different types of DNS messages and the different fields in each message type. In this section, the following DNS message topics are discussed: Message types DNS query message format DNS query message header DNS query question entries DNS resource records

Name query message Name query response Reverse name query message DNS update message format DNS update message flags Dynamic update response message

Message Types
There are three types of DNS messages: Queries Responses Updates

Queries and responses are defined in the original DNS standard, and updates are defined in RFC 2136. All three types follow a common message format.

DNS Query Message Format

The common DNS message format has a fixed-length, 12-byte header and a variable position reserved for question, answer, authority, and additional DNS resource records. The common message format can be illustrated as follows: Standard DNS Query Message Format

DNS Message Format

DNS Header (fixed length) Question Entries (variable length) Answer Resource Records (variable length) Authority Resource Records (variable length) Additional Resource Records(variable length)

DNS Query Message Header

The DNS message header contains the following fields, in the following order: DNS Query Message Header Fields

Field Name

Description

Transaction ID

A 16-bit field identifying a specific DNS transaction. The transaction ID is cr originator and is copied by the responder into its response message. Using the client can match responses to its requests.

Flags:

A 16-bit field containing various service flags that are communicated betwee server, including: 1-bit field set to 0 to represent a name service request or set to 1 to represent

Request/response Operation code Authoritative answer Truncation

4-bit field represents the name service operation of the packet: 0x0 is a query

1-bit field represents that the responder is authoritative for the domain name i

1-bit field that is set to 1 if the total number of responses exceeded the User D datagram. Unless UDP datagrams larger than 512 bytes or EDNS0 are enable the UDP reply are returned.

Recursion desired

1-bit field set to 1 to indicate a recursive query and 0 for iterative queries. If a message with this field set to 0 it returns a list of other DNS servers that the c This list is populated from local cache data.

Recursion available

1-bit field set by a DNS server to 1 to represent that the DNS server can hand recursion is disabled, the DNS server sets the field appropriately. 3-bit field that is reserved and set to 0. 4-bit field holding the return code:
0 is a successful response (query answer is in the query response).

Reserved Return code

0x3 is a name error, indicating that an authoritative DNS server responded th

query message does not exist. For more information about return codes, se end of this document.

Question Resource Record count Answer Resource Record count Authority Resource Record count Additional Resource Record count

A 16-bit field representing the number of entries in the question section of the

A 16-bit field representing the number of entries in the answer section of the

A 16-bit field representing the number of authority resource records in the DN

A 16-bit field representing the number of additional resource records in the D

DNS Query Question Entries

The DNS messages Question Entries section contains the domain name that is being queried and has the following three fields: DNS Query Question Entry Fields

Field Name

Description

Question Name

The domain name that is being queried. DNS domain names are expressed as a series of la but in the Question Name field the domain name is encoded as a series of length-value pai that indicates the length of the value, followed by the value (the label). For example, the do expressed as 0x09microsoft0x03com0x00, where the hexadecimal digits represent the leng characters indicate the individual labels, and the final 0 indicates the end of the name.

Question Type Type value 0x01 0x02 0x05 0x0C (12) 0x0F (15) 0x21 (33) 0xFB (251) 0xFC (252) 0xFF (255) Question Class

Uses a 16-bit integer to represents the resource record type that should be returned, as expr

Record(s) Returned Host (A) record Name server (NS) record Alias (CNAME) record Reverse-lookup (PTR) record Mail exchange (MX) record Service (SRV) record Incremental zone transfer (IXFR) record Standard zone transfer (AXFR) record All records Represents the IN (Internet) question class and is normally set to 0x0001.

DNS Resource Records

The answer, authority, and additional information sections of a DNS response message can contain resource records that answer the query message question section. Resource records are formatted as follows: DNS Resource Record Message Fields

Field Name

Description

Resource record name Resource record type Resource record class Time-to-live Resource data length Resource data

The DNS domain name recorded as a variable-length field following the same f Name field. The resource record type value. The resource record class code, the Internet class, 0x0001.

The TTL expressed in seconds as a 32-bit unsigned field. 2-byte field indicating the length of the resource data. Variable-length data corresponding to the resource record type.

The Resource Record Name field is encoded in the same way as the Question Name field unless the name is already present elsewhere in the DNS message, in which case a 2-byte field is used in place of a length-value encoded name and acts as a pointer to the name that is already present.

Name Query Message

A Name Query message format is the same as the DNS message format described above. In a typical Name Query message, the DNS message fields would be set as follows: DNS Name Query Message Fields

Field Name

Description

Query identifier (Transaction ID) Flags Question count Question entry

Set to a unique number to enable the DNS client resolver to match the respo response transaction ID always matches the query request transaction ID. Set to indicate a standard query with recursion enabled. Set to 1. Set to the domain name queried and the resource record type to return.

Name Query Response

A Name Query Response message format is the same as the DNS message format described above. In a typical Name Query message, the DNS message fields would be set as follows: DNS Name Query Response Fields

Field Name

Description

Query identifier (Transaction ID) Flags Question count Question entry

Set to a unique number to enable the DNS client resolver to matc Set to indicate a standard query with recursion enabled. Set to 1.

Set to the domain name queried and the resource record type to r

Reverse Name Query Message

Reverse name query messages use the common message format with the following differences: The DNS client resolver constructs the domain name in the in-addr.arpa domain based on the IP address that is queried. A Pointer (PTR) resource record is queried rather than a host (A) resource record.

DNS Update Message Format

The DNS update message format uses a header defining the update operation to be performed and a resource record set that contains the update. The DNS update message format has the following fields: Identification. A 16-bit identifier assigned by the DNS client requestor. This identifier is copied in the corresponding reply and can be used by the requestor to match replies to outstanding requests, or by the server to detect duplicated requests from some requestor. Flags. A 16-bit DNS update message flags field. For a description of each flag, see DNS Update Message Flags below. Number of zone entries. The number of resource records in the Zone entry section. Number of prerequisite resource records. The number of resource records in the Prerequisite resource records section. Number of update resource records. The number of resource records in the Update resource records section. Number of additional resource records. The number of resource records in the Additional resource records section. Zone entry. Denotes the zone of the records being updated. All records to be updated must be in the same zone, and therefore the Zone Section is allowed to contain exactly one record. It has three values: ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is the zones class. Prerequisite resource records. Contains a set of resource record prerequisites which must be satisfied at the time the update message is received by the master DNS server. There are five possible sets of values that can be expressed: o Resource record set exists (value independent). At least one resource record with a specified name and type (in the zone and class specified by the Zone Section) must exist.

Resource record set exists (value dependent). A set of resource records with a specified name and type exists and has the same members with the same data as the resource record set specified in this section. Resource record set does not exist. No resource records with a specified name and type (in the zone and class denoted by the Zone section) exist. Name is in use. At least one resource record with a specified name (in the zone and class specified by the Zone section) exists. This prerequisite is not satisfied by empty nonterminals. Name is not in use. No resource record of any type is owned by a specified name. This prerequisite is satisfied by empty nonterminals.

Update resource records. Contains the resource records that are to be added or deleted from the zone. One of four operations are performed during the update: o o o o Add resource records to an resource records set. Delete an resource records set Delete all resource records sets from a name. Delete a resource record from an resource records set.

Additional resource records. Contains resource records which are related to the update, or to new resource records being added by the update.

DNS Update Message Flags

The DNS update message flags field uses the following flags: Request/response. 1-bit field set to 0 to represent an update request and 1 to represent an update response. Operation code. 4-bit field set to 0x5 for DNS updates. Reserved. 7-bit reserved field set to 0. Return code. 4-bit field containing codes to represent the result of the update query. The codes are as follows: DNS Update Message Flag Field Return Code Values

Result Code Value

Description

0 (NOERROR) 1 (FORMERR)

No error; successful update. Format error; DNS server did not understand the update request.

0x2 (SERVFAIL) 0x3 (NXDOMAIN) 0x4 (NOTIMP) 0x5 (REFUSED) 0x6 (YXDOMAIN) 0x7 (YXRRSET) 0x8 (NXRRSET) 0x9 (NOTAUTH) 0xA (NOTZONE)

DNS server encountered an internal error, such as a forwarding timeout A name that should exist does not exist. DNS server does not support the specified Operation code. DNS server refuses to perform the update because A name that should not exist does exist. A resource record set that should not exist does exist. A resource record set that should exist does not exist. DNS server is not authoritative for the zone named in the Zone section. A name used in the Prerequisite or Update sections is not within the zone

Dynamic Update Response Message

The dynamic update response message follows the same format as the DNS update message, with the exception of the DNS flags. The dynamic update response message header flags indicate whether or not the update is successful by including the successful response code or one of the error codes described in DNS update message flags above.

DNS Physical Structure

The logical structure of Windows Server 2003 DNS involves DNS namespace partitioning, which extends the DNS domain name hierarchy into multiple subdomains. The physical structure of DNS involves distributing the DNS database using DNS servers to host DNS zones for the subdomains of the DNS domain name hierarchy. Both the DNS Client and Server service applications manage the physical DNS data in the DNS database.

DNS Client Service

The Windows Server 2003 operating system, as well as Microsoft Windows XP and Windows 2000 include a DNS Client service. This service performs all necessary DNS lookups and provides a local cache for DNS queries that reduces DNS network traffic and speeds name resolution. This service can be stopped and started using the Services console. Computers running Windows 2000, Windows XP and Windows Server 2003 enable the DNS Client service by default. The Windows Server 2003 DNS Client service performs the following tasks: Registers its names in DNS. Name resolution. Caching responses to name resolution queries. Removes previously resolved names from the cache when it receives a negative response for the name. Negative caching.

Keeps track of transitory (Plug and Play) network connections and the DNS server lists based on their IP configurations. Maintains connection-specific domain name suffixes. Prioritizes which DNS servers it uses according to whether they respond to a query if multiple DNS server are configured on the client. Prioritizes the multiple A resource records it receives from a DNS server based on their IP address. Initiates a network failure timeout when all DNS Client service queries time out, and does not submit any queries for 30 seconds. This feature applies to every adapter separately.

Windows XP, Windows 2000 and Windows Server 2003 DNS client configuration involves the following settings in the TCP/IP properties for each computer: Domain Names. Domain names are to form the fully qualified domain name (FQDN) for DNS clients. Host names. A DNS computer or host name for each computer. For example, in the fully qualified domain name (FQDN) wkstn1.example.microsoft.com., the DNS computer name is the leftmost label client1. Primary DNS suffixes. A primary DNS suffix for the computer, which is placed after the computer or host name to form the FQDN. Using the previous example, the primary DNS suffix would be example.microsoft.com. Connection-specific names. Each network connections of a multihomed computer can be configured with a connection-specific DNS domain name NetBIOS names. NetBIOS names are used to support legacy Microsoft networking technology. DNS servers list. A list of DNS servers for clients to use when resolving DNS names, such as a preferred DNS server, and any alternate DNS servers to use if the preferred server is not available. DNS suffix search list. The DNS suffix search list or search method to be used by the client when it performs DNS query searches for short, unqualified domain names.

Domain Names
The domain name is used with the client computer name to form the fully qualified domain name (FQDN), known also as the full computer name. In general, the DNS domain name is the remainder of the FQDN that is not used as the unique host name for the computer. For example, the DNS domain name used for a client computer could be the following: If the FQDN, or Full computer name, is wkstn1.example.microsoft.com, the domain name is the example.microsoft.com portion of this name. DNS domain names have two variations a DNS name and a NetBIOS name. The full computer name (a fully qualified DNS name) is used during querying and location of named resources on your network. For earlier version clients, the NetBIOS name is used to locate various types of NetBIOS services that are shared on your network.

An example that shows the need for both NetBIOS and DNS names is the Net Logon service. In Windows Server 2003 DNS, the Net Logon service on a domain controller registers its service (SRV) resource records on a DNS server. For Windows NT Server 4.0 and earlier versions, domain controllers register a DomainName entry in Windows Internet Name Service (WINS) to perform the same registration and to advertise their availability for providing authentication service to the network. When a client computer is started on the network, it uses the DNS resolver to query a DNS server for SRV records for its configured domain name. This query is used to locate domain controllers and provide logon authentication for accessing network resources. A client or a domain controller on the network optionally uses the NetBIOS resolver service to query WINS servers, attempting to locate DomainName [1C] entries to complete the logon process. Your DNS domain names should follow the same standards and recommended practices that apply to DNS computer naming described in the previous section. In general, acceptable naming conventions for domain names include the use of letters A through Z, numerals 0 through 9, and the hyphen (-). The use of the period (.) in a domain name is always used to separate the discrete parts of a domain name, commonly known as labels. Each label corresponds to an additional level defined in the DNS namespace tree. For most computers, the primary DNS suffix configured for the computer can be the same as its Active Directory domain name, although the two values can be different.

Host Names
Computers using the underlying TCP/IP protocol of a Windows-based network use an IP address, a 32-bit numeric value (in the case of IPv4) or a 128-bit numeric value (in the case of IPv6), to identify the computer network connection of network hosts. However, network users prefer to use memorable, alphanumeric names. To support this need, network resources in a Windows-based network are identified by both alphanumeric names and IP addresses. DNS and WINS are two name resolution mechanisms that enable the use of alphanumeric names, and convert these names into their respective IP addresses.

NetBIOS vs. DNS Computer Names

In networks running Windows NT 4.0 and earlier, users typically locate and access a computer on the network using a NetBIOS (Network Basic Input Output System) name. In Windows 2000, Windows XP, and Windows Server 2003 operating systems, users locate and access a computer using DNS. In this implementation of DNS, a computer is identified by its full computer name, which is a DNS fully qualified domain name (FQDN).

Primary DNS Suffixes

The full computer name is a concatenation of the single-label host name, such as hostcomputer, and a multilabel primary DNS suffix name, such as corp.example.com, which is the DNS name of the Active Directory domain to which the computer is joined. Using the host and primary DNS suffix examples, the full computer name is hostcomputer.corp.example.com. The host name is the same as the computer name specified during the installation of Windows Server 2003 and is listed in System Properties. The primary DNS suffix name is the same as the domain name specified during installation of Windows Server 2003 and is listed in System Properties. The full computer name is also listed in System Properties. In addition, connection-specific DNS suffixes can be applied to the separate network adapter connections used by a multihomed computer. Connection-specific DNS suffixes identify the host when it is connected to separate networks that use different domain names. When using connectionspecific DNS suffixes, a full computer name is also a concatenation of the host name and a connection-specific DNS suffix. Using its host name and DNS suffixes, a single computer can have its full computer name configured using two possible methods: A primary full computer name, which applies as the default full computer name for the computer and all of its configured network connections.

A connection-specific full computer name, which can be configured as an alternate DNS domain name that applies only for a single network adapter installed and configured on the computer.

Note that when using Active Directory, by default, the primary DNS suffix portion of a computers full computer name must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Connection-specific Names
As shown in the following figure, a multihomed server computer named host-a can be named according to both its primary and connection-specific DNS domain names. Connection-specific DNS Names

In this example, the server computer host-a attaches to two separate subnets Subnet 1 and Subnet 2 which are also linked at redundant points using two routers for additional paths between each subnet. Given this configuration, host-a provides access as follows through its separately named local area network (LAN) connections: The name host-a.public.example.microsoft.com provides access using LAN connection 1 over Subnet 1, a lower-speed (10 megabit) Ethernet LAN, for normal access to users who have typical file and print service needs. The name host-a.backup.example.microsoft.com provides access using LAN connection 2 over Subnet 2, a higher-speed (100 megabit) Ethernet LAN, for reserved access by server applications and administrators who have special needs, such as troubleshooting server networking problems, performing network-based backup, or replicating zone data between servers.

In addition to the connection-specific DNS names, the computer can also be accessible using either of the two LAN connections by specifying its primary DNS domain name, host a.example.microsoft.com. When configured as shown, a computer can register resource records in DNS according to its three distinct names and sets of IP addresses, as shown in the following table: DNS Names

DNS Name

IP Addresses

Description

host-a.example.microsoft.com

10.1.1.11, 10.2.2.22

Primary DNS name for computer. The computer records for all configured IP addresses under thi example.microsoft.com zone.

hosta.public.example.microsoft.com

10.1.1.11

Connection-specific DNS name for LAN connec PTR resource records for IP address 10.1.1.11 in public.example.microsoft.com zone.

hosta.backup.example.microsoft.com

10.2.2.22

Connection-specific DNS name for LAN connec PTR resource records for IP address 10.2.2.22 in backup.example.microsoft.com zone.

When a computer changes between connections to different networks hosting different DNS domains, the host name does not need to be changed unless there is a host in the new DNS domain with the same host name. The primary DNS suffix for the computer can be changed from the old domain name to the new domain and the computer will register the new full computer name in DNS.