Technical Tips and Solutions 4 All: Complete DNS and features and DNS queries

· Structure Domain name space

The domain name space consists of a tree of domain names. Each node or leaf in the tree has zero or more resource records, which hold information associated with the domain name. The tree sub-divides into zones beginning at the root zone. A DNS zone may consist of only one domain, or may consist of many domains and sub-domains, depending on the administrative authority delegated to the manager.

Administrative responsibility over any zone may be divided by creating additional zones. Authority is said to be delegated for a portion of the old space, usually in the form of sub-domains, to another nameserver and administrative entity. The old zone ceases to be authoritative for the new zone.

Domain Name Syntax

The definitive descriptions of the rules for forming domain names appear in RFC 1035, RFC 1123, and RFC 2181. A domain name consists of one or more parts, technically called labels, that are conventionally concatenated, and delimited by dots, such as example.com.

The right-most label conveys the top-level domain; for example, the domain name www.example.com belongs to the top-level domain com.
The hierarchy of domains descends from right to left; each label to the left specifies a subdivision, or subdomain of the domain to the right. For example: the label example specifies a subdomain of the com domain, and www is a sub domain of example.com. This tree of subdivisions may have up to 127 levels.
Each label may contain up to 63 characters. The full domain name may not exceed a total length of 253 characters in its external dotted-label specification.^[10] In the internal binary representation of the DNS the maximum length requires 255 octets of storage.^[3] In practice, some domain registries may have shorter limits.^[^{citation needed}^]
DNS names may technically consist of any character representable in an octet. However, the allowed formulation of domain names in the DNS root zone, and most other sub domains, uses a preferred format and character set. The characters allowed in a label are a subset of the ASCII character set, and includes the characters a through z, A through Z, digits 0 through 9, and the hyphen. This rule is known as the LDH rule (letters, digits, hyphen). Domain names are interpreted in case-independent manner. Labels may not start or end with a hyphen.^[11]
A hostname is a domain name that has at least one IP address associated. For example, the domain names www.example.com and example.com are also hostnames, whereas the com domain is not.

Name Servers

The Domain Name System is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. Each domain has at least one authoritative DNS server that publishes information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers, the servers to query when looking up (resolving) a TLD.

Authoritative name server

An authoritative name server is a name server that gives answers that have been configured by an original source, for example, the domain administrator or by dynamic DNS methods, in contrast to answers that were obtained via a regular DNS query to another name server. An authoritative-only name server only returns answers to queries about domain names that have been specifically configured by the administrator.

An authoritative name server can either be a master server or a slave server. A master server is a server that stores the original (master) copies of all zone records. A slave server uses an automatic updating mechanism of the DNS protocol in communication with its master to maintain an identical copy of the master records.

Every DNS zone must be assigned a set of authoritative name servers that are installed in NS records in the parent zone.

When domain names are registered with a domain name registrar, their installation at the domain registry of a top level domain requires the assignment of a primary name server and at least one secondary name server. The requirement of multiple name servers aims to make the domain still functional even if one name server becomes inaccessible or inoperable.^[12] The designation of a primary name server is solely determined by the priority given to the domain name registrar. For this purpose, generally only the fully qualified domain name of the name server is required, unless the servers are contained in the registered domain, in which case the corresponding IP address is needed as well.

Primary name servers are often master name servers, while secondary name server may be implemented as slave servers.

An authoritative server indicates its status of supplying definitive answers, deemed authoritative, by setting a software flag (a protocol structure bit), called the Authoritative Answer (AA) bit in its responses.^[5] This flag is usually reproduced prominently in the output of DNS administration query tools (such as dig) to indicate that the responding name server is an authority for the domain name in question.^[5]

Recursive and caching name server

In principle, authoritative name servers are sufficient for the operation of the Internet. However, with only authoritative name servers operating, every DNS query must start with recursive queries at the root zone of the Domain Name System and each user system must implement resolver software capable of recursive operation.

To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-user applications, the Domain Name System supports DNS cache servers which store DNS query results for a period of time determined in the configuration (time-to-live) of the domain name record in question. Typically, such caching DNS servers, also called DNS caches, also implement the recursive algorithm necessary to resolve a given name starting with the DNS root through to the authoritative name servers of the queried domain. With this function implemented in the name server, user applications gain efficiency in design and operation.

The combination of DNS caching and recursive functions in a name server is not mandatory; the functions can be implemented independently in servers for special purposes.

Internet service providers typically provide recursive and caching name servers for their customers. In addition, many home networking routers implement DNS caches and recursors to improve efficiency in the local network.

DNS Resolvers

DNS resource records

Further information: List of DNS record types

A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), an expiration time limit, a class, and some type-specific data. Resource records of the same type define a resource record set (RRset). The order of resource records in a set, returned by a resolver to an application, is undefined, but often servers implement round-robin ordering to achieve load balancing. DNSSEC, however, works on complete resource record sets in a canonical order.

When sent over an IP network, all records use the common format specified in

RR (Resource Record) Fields:
Field	Description	Length (octets)
NAME	Name of the node to which this record pertains	(variable)
TYPE	Type of RR in numeric form (e.g. 15 for MX RRs)	2
CLASS	Class code	2
TTL	Count of seconds that the RR stays valid (The maximum is 2³¹-1, which is about 68 years.)	4
RDLENGTH	Length of RDATA field	2
RDATA	Additional RR-specific data	(variable)

NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the current domain name.

TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use. For example, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MX record specifies the mail server used to handle mail for a domain specified in an e-mail address (see also List of DNS record types).

RDATA is data of type-specific relevance, such as the IP address for address records, or the priority and hostname for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types must not (RFC 3597).

The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers, or IP addresses. In addition, the classes Chaos (CH) and Hesiod (HS) exist.^[16] Each class is an independent name space with potentially different delegations of DNS zones.

In addition to resource records defined in a zone file, the domain name system also defines several request types that are used only in communication with other DNS nodes (on the wire), such as when performing zone transfers (AXFR/IXFR) or for EDNS (OPT).

Wildcard DNS records

The domain name system supports wildcard domain names which are names that start with the asterisk label, '*', e.g., *.example.^[3]^[17] DNS records belonging to wildcard domain names specify rules for generating resource records within a single DNS zone by substituting whole labels with matching components of the query name, including any specified descendants. For example, in the DNS zone x.example, the following configuration specifies that all subdomains (including subdomains of subdomains) of x.example use the mail exchanger a.x.example. The records for a.x.example are needed to specify the mail exchanger. As this has the result of excluding this domain name and its subdomains from the wildcard matches, all subdomains of a.x.example must be defined in a separate wildcard statement.

Understanding zones and zone transfer

Domain Name System (DNS) allows a DNS namespace to be divided up into zones, which store name information about one or more DNS domains. For each DNS domain name included in a zone, the zone becomes the authoritative source for information about that domain.

Understanding the difference between zones and domains

A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain used to create the zone, these domains can either be part of the same zone or belong to another zone. Once a subdomain is added, it can then either be:

Managed and included as part of the original zone records, or
Delegated away to another zone created to support the subdomain

For example, the following figure shows the microsoft.com domain, which contains domain names for Microsoft. When the microsoft.com domain is first created at a single server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however, the microsoft.com domain needs to use subdomains, those subdomains must be included in the zone or delegated away to another zone.

In this example, the example.microsoft.com domain shows a new subdomain -- the example.microsoft.com domain -- delegated away from the microsoft.com zone and managed in its own zone. However, the microsoft.com zone needs to contain a few resource records to provide the delegation information that references the DNS servers that are authoritative for the delegated example.microsoft.com subdomain.

If the microsoft.com zone does not use delegation for a subdomain, any data for the subdomain remains part of the microsoft.com zone. For example, the subdomain dev.microsoft.com is not delegated away but is managed by the microsoft.com zone.

Why zone replication and zone transfers are needed

Because of the important role that zones play in DNS, it is intended that they be available from more than one DNS server on the network to provide availability and fault tolerance when resolving name queries. Otherwise, if a single server is used and that server is not responding, queries for names in the zone can fail. For additional servers to host a zone, zone transfers are required to replicate and synchronize all copies of the zone used at each server configured to host the zone.

When a new DNS server is added to the network and is configured as a new secondary server for an existing zone, it performs a full initial transfer of the zone to obtain and replicate a full copy of resource records for the zone. For earlier DNS server implementations, this same method of full transfer for a zone is also used when the zone requires updating after changes are made to the zone. For DNS servers running Windows Server 2003, the DNS service supports incremental zone transfer, a revised DNS zone transfer process for intermediate changes.

Incremental zone transfers

Incremental zone transfers are described in Request for Comments (RFC) 1995 as an additional DNS standard for replicating DNS zones. For more information about RFCs, see the RFC Editor Web site. When incremental transfers are supported by both a DNS server acting as the source for a zone and any servers that copy the zone from it, it provides a more efficient method of propagating zone changes and updates.

In earlier DNS implementations, any request for an update of zone data required a full transfer of the entire zone database using an AXFR query. With incremental transfer, an alternate query type (IXFR) can be used instead. This allows the secondary server to pull only those zone changes it needs to synchronize its copy of the zone with its source, either a primary or secondary copy of the zone maintained by another DNS server.

With IXFR zone transfers, differences between the source and replicated versions of the zone are first determined. If the zones are identified to be the same version -- as indicated by the serial number field in the start of authority (SOA) resource record of each zone -- no transfer is made.

If the serial number for the zone at the source is greater than at the requesting secondary server, a transfer is made of only those changes to resource records (RRs) for each incremental version of the zone. For an IXFR query to succeed and changes to be sent, the source DNS server for the zone must keep a history of incremental zone changes to use when answering these queries. The incremental transfer process requires substantially less traffic on a network and zone transfers are completed much faster.

Example: Zone transfer

A zone transfer might occur during any of the following scenarios:

When the refresh interval expires for the zone
When a secondary server is notified of zone changes by its master server
When the DNS Server service is started at a secondary server for the zone
When the DNS console is used at a secondary server for the zone to manually initiate a transfer from its master server

Zone transfers are always initiated at the secondary server for a zone and sent to their configured master servers which act as their source for the zone. Master servers can be any other DNS server that loads the zone, such as either the primary server for the zone or another secondary server. When the master server receives the request for the zone, it can reply with either a partial or full transfer of the zone to the secondary server.

As shown in the following figure, zone transfers between servers follow an ordered process. This process varies depending on whether a zone has been previously replicated, or if initial replication of a new zone is being performed.

In this example, the following sequence is performed for a requesting secondary server -- the destination server -- for a zone and its source server, another DNS server that hosts the zone.

1. During new configuration, the destination server sends an initial "all zone" transfer (AXFR) request to the master DNS server configured as its source for the zone.

2. The master (source) server responds and fully transfers the zone to the secondary (destination) server.

The zone is delivered to the destination server requesting the transfer with its version established by use of a Serial number field in the properties for the start of authority (SOA) resource record (RR). The SOA RR also contains a stated refresh interval in seconds (by default, 900 seconds or 15 minutes) to indicate when the destination server should next request to renew the zone with the source server.

3. When the refresh interval expires, an SOA query is used by the destination server to request renewal of the zone from the source server.

4. The source server answers the query for its SOA record.

This response contains the serial number for the zone in its current state at the source server.

5. The destination server checks the serial number of the SOA record in the response and determines how to renew the zone.

If the value of the serial number in the SOA response is equal to its current local serial number, it concludes that the zone is the same at both servers and that a zone transfer is not needed. The destination server then renews the zone by resetting its refresh interval based on the value of this field in the SOA response from its source server.

If the value of the serial number in the SOA response is higher than its current local serial number, it concludes that the zone has been updated and that a transfer is needed.

6. If the destination server concludes that the zone has changed, it sends an IXFR query to the source server, containing its current local value for the serial number in the SOA record for the zone.

7. The source server responds with either an incremental or full transfer of the zone.

If the source server supports incremental transfer by maintaining a history of recent incremental zone changes for modified resource records, it can answer with an incremental zone transfer (IXFR) of the zone.

If the source server does not support incremental transfer, or does not have a history of zone changes, it can answer with a full (AXFR) transfer of the zone instead.

Note

For servers running Windows 2000 and Windows Server 2003, incremental zone transfer through IXFR query is supported. For earlier versions of the DNS service and for many other DNS server implementations, incremental zone transfer is not available and only full-zone (AXFR) queries and transfers are used to replicate zones.

DNS Notify

Windows-based DNS servers support DNS Notify, an update to the original DNS protocol specification that permits a means of initiating notification to secondary servers when zone changes occur (RFC 1996). DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when it is updated. Servers that are notified can then initiate a zone transfer as described above to pull zone changes from their master servers and update their local replicas of the zone.

For secondary’s to be notified by the DNS server acting as their configured source for a zone, each secondary server must first have its IP address in the notify list of the source server. When using the DNS console, this list is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located in zone Properties.

In addition to notifying the listed servers, the DNS console permits you to use the contents of the notify list as a means to restrict or limit zone transfer access to only those secondary servers specified in the list. This can help prevent an undesired attempt by an unknown or unapproved DNS server to pull, or request, zone updates. For more information, see Create and manage a notify list for a zone.

The following is a brief summary of the typical DNS notification process for zone updates:

1. The local zone at a DNS server acting as a master server, a source for the zone to other servers, is updated. When the zone is updated at the master or source server, the serial number field in the SOA RR is also updated, indicating a new local version of the zone.

2. The master server sends a DNS notify message to other servers that are part of its configured notify list.

3. All secondary servers that receive the notify message can then respond by initiating a zone transfer request back to the notifying master server.

The normal zone transfer process can then continue as described in the previous section.

You cannot configure a notify list for a stub zone.

Important

Use DNS notification only to notify servers operating as secondary servers for a zone. For replication of directory-integrated zones, DNS notification is not needed.

This is because any DNS servers that load a zone from Active Directory automatically poll the directory (as specified by the SOA resource record's Refresh Interval) to update and refresh the zone.

In these cases, configuring a notify list can actually degrade system performance by causing unnecessary additional transfer requests for the updated zone.

Reverse lookup

In most DNS lookups, clients typically perform a forward lookup, which is a search based on the DNS name of another computer as stored in an address (A) resource record. This type of query expects an IP address as the resource data for the answered response.

DNS also provides a reverse lookup process, enabling clients to use a known IP address during a name query and look up a computer name based on its address. A reverse lookup takes the form of a question, such as "Can you tell me the DNS name of the computer that uses the IP address 192.168.1.20?"

DNS was not originally designed to support this type of query. One problem for supporting the reverse query process is the difference in how the DNS namespace organizes and indexes names and how IP addresses are assigned. If the only method to answer the previous question was to search in all domains in the DNS namespace, a reverse query would take too long and require too much processing to be useful.

To solve this problem, a special domain, the in-addr.arpa domain, was defined in the DNS standards and reserved in the Internet DNS namespace to provide a practical and reliable way to perform reverse queries. To create the reverse namespace, subdomains within the in-addr.arpa domain are formed using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses.

This reversed ordering of the domains for each octet value is needed because, unlike DNS names, when IP addresses are read from left to right, they are interpreted in the opposite manner. When an IP address is read from left to right, it is viewed from its most generalized information (an IP network address) in the first part of the address to the more specific information (an IP host address) contained in the last octets.

For this reason, the order of IP address octets must be reversed when building the in-addr.arpa domain tree. The IP addresses of the DNS in-addr.arpa tree can be delegated to companies as they are assigned a specific or limited set of IP addresses within the Internet-defined address classes.

Finally, the in-addr.arpa domain tree, as built into DNS, requires that an additional resource record (RR) type — the pointer (PTR) RR — be defined. This RR is used to create a mapping in the reverse lookup zone that typically corresponds to a host (A) named RR for the DNS computer name of a host in its forward lookup zone.

Note

The in-addr.arpa domain applies for use in all TCP/IP networks that are based on Internet Protocol version 4 (IPv4) addressing. The New Zone Wizard automatically assumes that you are using this domain when creating a new reverse lookup zone.

If you are installing DNS and configuring reverse lookup zones for an Internet Protocol version 6 (IPv6) network, you can specify an exact name in the New Zone wizard. This will permit you to create reverse lookup zones in the DNS console that can be used to support IPv6 networks, which uses a different special domain name, the ip6.arpa domain.

Additional information is available on IPv6 and DNS, including examples of how to create and use ip6.arpa domain names in Request for Comments (RFC) 3596, "DNS Extensions to support IP version 6." For more information, refer directly to this RFC, which can be obtained from the RFC Editor Web site.

Example: Reverse query (for IPv4 networks)

The following figure shows an example of a reverse query initiated by a DNS client (host-b) to learn the name of another host (host-a) based on its IP address, 192.168.1.20.

The reverse query process as shown in this figure occurs in the following steps:

1. The client, "host-b", queries the DNS server for a pointer (PTR) RR that maps to the IP address of 192.168.1.20 for "host-a".

Because the query is for PTR records, the resolver reverses the address and appends the in-addr.arpa domain to the end of the reverse address. This forms the fully qualified domain name ("20.1.168.192.in-addr.arpa.") for which to be searched in a reverse lookup zone.

2. Once located, the authoritative DNS server for "20.1.168.192.in-addr.arpa" can respond with the PTR record information. This includes the DNS domain name for "host-a", completing the reverse lookup process.

Keep in mind that if the queried reverse name is not answerable from the DNS server, normal DNS resolution (either recursion or iteration) can be used to locate a DNS server that is authoritative for the reverse lookup zone and that contains the queried name. In this sense, the name resolution process used in a reverse lookup is identical to that of a forward lookup.

Note

The DNS console provides a means for you to configure a subnetted reverse lookup "classless" zone when the Advanced view is selected. This allows you to configure a zone in the in-addr.arpa domain for a limited set of assigned IP addresses where a nondefault IP subnet mask is used with those addresses. For more information, see Managing reverse lookup zones.

Inverse queries

Inverse queries are an outdated practice, originally proposed as part of the DNS standard to look up a host name based on its IP address. They use a nonstandard DNS query operation, and their use is limited to some of the earlier versions of Nslookup, a command-line utility for troubleshooting and testing DNS service.

The DNS service recognizes and accepts inverse query messages, answering them with a fake inverse query response. For DNS servers running in Windows NT Server 4.0, this support is available by default if the server computer has been updated to Service Pack 4 (SP4) or later.

Notes

The configuration of PTR resource records and reverse lookup zones for identifying hosts by reverse query is strictly an optional part of the DNS standard implementation. You are not required to use reverse lookup zones, although for some networked applications, they are used to perform security checks.

Understanding forwarders

A forwarder is a Domain Name System (DNS) server on a network used to forward DNS queries for external DNS names to DNS servers outside of that network. You can also forward queries according to specific domain names using conditional forwarders.

A DNS server on a network is designated as a forwarder by having the other DNS servers in the network forward the queries they cannot resolve locally to that DNS server. By using a forwarder, you can manage name resolution for names outside of your network, such as names on the Internet, and improve the efficiency of name resolution for the computers in your network. For more information about forwarders and conditional forwarders, see Using forwarders.

The following figure illustrates how external name queries are directed using forwarders.

Example of a common forwarder configuration

For more information about directing external queries, see Directing queries through forwarders.

Without having a specific DNS server designated as a forwarder, all DNS servers can send queries outside of a network using their root hints. As a result, a lot of internal, and possibly critical, DNS information can be exposed on the Internet. In addition to this security and privacy issue, this method of resolution can result in a large volume of external traffic that is costly and inefficient for a network with a slow Internet connection or a company with high Internet service costs.

When you designate a DNS server as a forwarder, you make that forwarder responsible for handling external traffic, thereby limiting DNS server exposure to the Internet. A forwarder will build up a large cache of external DNS information because all of the external DNS queries in the network are resolved through it. In a small amount of time, a forwarder will resolve a good portion of external DNS queries using this cached data and thereby decrease the Internet traffic over the network and the response time for DNS clients.

A DNS server configured to use a forwarder will behave differently than a DNS server that is not configured to use a forwarder. A DNS server configured to use a forwarder behaves as follows:

1. When the DNS server receives a query, it attempts to resolve this query using the primary and secondary zones that it hosts and its cache.

2. If the query cannot be resolved using this local data, then it will forward the query to the DNS server designated as a forwarder.

3. The DNS server will wait briefly for an answer from the forwarder before attempting to contact the DNS servers specified in its root hints.

When a DNS server forwards a query to a forwarder it sends a recursive query to the forwarder. This is different than the iterative query that a DNS server will send to an other DNS server during standard name resolution (name resolution that does not involve a forwarder).

Conditional forwarders

A conditional forwarder is a DNS server on a network that is used to forward DNS queries according to the DNS domain name in the query. For example, a DNS server can be configured to forward all the queries it receives for names ending with widgets.example.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.

Intranet name resolution

A conditional forwarder can be used to improve name resolution for domains within your intranet. Intranet name resolution can be improved by configuring DNS servers with forwarders for specific internal domain names. For example, all DNS servers in the domain widgets.example.com could be configured to forward queries for names that end with test.example.com to the authoritative DNS servers for merged.widgets.example.com, thereby removing the step of querying the root servers of example.com, or removing the step of configuring DNS servers in the widgets.example.com zone with secondary zones for test.example.com.

Internet name resolution

DNS servers can use conditional forwarders to resolve queries between the DNS domain names of companies that share information. For example, two companies, Widgets Toys and TailspinToys, want to improve how the DNS clients of Widgets Toys resolve the names of the DNS clients of Tailspin Toys. The administrators from Tailspin Toys inform the administrators of Widgets Toys about the set of DNS servers in the Tailspin Toys network where Widgets can send queries for the domain dolls.tailspintoys.com. The DNS servers within the Widgets Toys network are configured to forward all queries for names ending with dolls.tailspintoys.com to the designated DNS servers in the network for Tailspin Toys. Consequently, the DNS servers in the Widgets Toys network do not need to query their internal root servers, or the Internet root servers, to resolve queries for names ending with dolls.tailspintoys.com.

Resource Records

A DNS zone contains various types of entries, called resource records . Resource records are the meat of a DNS zone, providing information about hostnames, IP addresses, and in some cases the services offered by a particular machine. There are several different classes of record types, the most common of which I'll define now.

Host (A) Records

Host records, or A records , simply map a hostname to an IP address. You generally create host records for each machine in your network.

A sample A record looks like this in a zone file:

colossus A 192.168.0.10

Using host records, you can implement a load-balancing technique known as round-robin DNS. Round-robin DNS involves entering multiple A records, all configured with the same hostname, but with different IP addresses that correspond to different machines. This way, when computers contact a nameserver for a certain hostname, they have an equally proportionate chance of receiving any one of the number of machines with A records. For example, if I have a web site at www.hasselltech.net and I have three web servers at 192.168.0.50, 192.168.0.51, and 192.168.0.52, I can configure three A records, all named "www," but with the three IP addresses mentioned earlier. Now, when client computers come to the nameserver and ask for the IP address of www.hasselltech.net, they have a 33% chance of receiving 192.168.0.50 as the web server of choice, a 33% chance of receiving 192.168.0.51, and a 33% chance of receiving 192.168.0.52. It's a poor-man's load-balancing system.

If the group of machines that serve web sites are on different subnets, the DNS system can return the "proper" address from a round-robin record set that is, the one that is closest to the client requesting it. This functionality is enabled by default. For example, if you have one A record set up for www.hasselltech.net on IP address 192.168.0.51, and another A record set up for the same hostname on IP address 10.0.0.25, a client computer located on the 10.0.0.0 subnet will receive the 10.0.0.25 A record from his request, and a client computer located on the 192.168.0.0 subnet will receive the 192.168.0.51 A record from his request.

Some advantages to round-robin DNS balancing include the following:

· The price is rightit's free with any nameserver.

· It's less complex than other, proprietary balancing systems.

· It's easy to maintain. You simply can add and delete A records in the zone file for each host as they come and go to and from production service.

The disadvantages include the following:

· It's less complex than other, proprietary balancing systems. Yes, this is an advantage and a disadvantage because a less complex system is less flexible than a proprietary solution.

· If a web server goes down, DNS isn't aware of it. It simply will continue to dole out IP addresses regardless of whether the server is available.

· It doesn't take into account the various capabilities and capacities of each systemit distributes the load fairly equally, whether your group of machines includes a Pentium 2 or a dual Pentium IV Xeon machine.

Canonical Name (CNAME) Records

CNAME, or canonical name, records allow you to give multiple host names to one IP address. Using CNAMEs, you can have a machine answering on one IP address but listening to several different hostnameswww.hasselltech.net, ftp.hasselltech.net, and mail.hasselltech.net all might be on one IP address, 192.168.1.2. CNAMEs effectively work as aliases.

However, there is a caveat to these records: you cannot have multiple identical CNAMEs. For example, if you have a record for www.secure.hasselltech.net on 192.168.1.2, you can't have another CNAME record named www-secure.hasselltech.net for a different IP address. CNAMEs are only for multiple names to one IP address, not for multiple IP addresses to one name. Note that these names are zone dependent, not server dependent.

Sometimes Windows will refer to CNAME records as aliases, in a confusing mix of technical accuracy and common parlance.

A sample CNAME record in zone file format looks like this:

ftp CNAME colossus.hasselltech.net

Mail Exchanger (MX) Records

Mail exchanger, or MX, records identify the mail server or mail servers for a specific zone or domain. Very simply, they instruct connecting computers to send all mail destined for a domain to a specific machine configured to receive Internet email.

In practice, a specific DNS zone can have multiple MX records. Each MX record also is assigned a preference number, which simply indicates what steps the respective machines listed should take when receiving Internet email. Lower preference numbers have higher priority. For example, let's say I have the following MX records:

· Hasselltech.net, MX preference 10, to mail.hasselltech.net

· Hasselltech.net, MX preference 100, to queue.perigee.net

This instructs connecting computers to send Internet email destined to hasselltech.net to the machine mail.hasselltech.net. However, if that machine isn't answering requests, connecting computers are instructed to try the machine queue.perigee.net and deliver mail there because the preference number is higher (100) than that of the first machine, which is 10. MX preference numbers provide a bit of failover protection if your organization's mail server is on a flaky or nonpermanent connection.

Entering two MX records with the same preference number distributes the load between the two hosts roughly equally, much like round-robin DNS balancing using multiple A records.

A sample MX record in zone file format is similar to this:

@ MX 10 mail.hasselltech.net

@ MX 100 queue.perigee.net

Name-server (NS) Records

Name-server (NS) records define the name-servers that can answer queries for a specific domain. They also delegate the resolution duties for various sub-domains to other zones. For example, you might configure an NS record for the "sales" sub-domain to delegate name resolution duties to the salesns.hasselltech.net machine, which handles that zone, or an NS record for the "billing" sub-domain to delegate duties to the billing-dns.hasselltech.net computer.

A sample NS record in zone file format looks like this:

@ NS colossus.hasselltech.net.

@ NS ns2.hasselltech.net.

Start of Authority (SOA) Records

The start of authority, or SOA, record for a zone names the primary name-servers that are authoritative for a particular zone and provides contact information for the primary administrator of the zone. It also controls how long a non-authoritative name-server can keep the information it retrieved in its own cache before needing to verify the data with the authoritative server again.

There are three important intervals to discuss at this point when it comes to SOA records:

Refresh interval

The refresh interval indicates to secondary name-servers how long they can keep their copies of the primary name-server's zones before being required to request a refresh of the zone.

Retry interval

The retry interval indicates how long the secondary name-server must wait before attempting to contact the primary name-server again after a failed attempt to refresh its zones after the refresh interval has lapsed.

Minimum (default) TTL

This value indicates to other name-servers how long they can use information they've previously retrieved from this authoritative name-server before being required to consult the authoritative server again for updated or refreshed information. This is, by default, 60 minutes. You also can set TTL values for individual records that override this minimum default setting for a zone.

A sample SOA record in zone file format looks like this:

     @ IN SOA colossus.hasselltech.net. admin.hasselltech.net. (

     200509171203; serial number

     100; refresh

     50; retry

     86400; expire

     3600); default TTL

Pointer (PTR) Records

Pointer (PTR) records work very similarly to A records, except they perform the function in reverse-PTR records point IP addresses to hostnames and reside in reverse lookup zones.

A sample PTR record in zone file format looks like this:

     61.130.98.66.in-addr.arpa. IN PTR alpha.enablehosting.com

Service (SRV) Records

Service (SRV) records indicate the range and availability of services in a particular zone or domain. They catalog the protocols and services running on specific ports in a zone, creating a "Yellow Pages" of sorts for connecting computers to find machines in the zone that will handle their specific types of requests. Like MX records, SRV records have a preference number, so you can perform a kind of poor man's load balancing and fault tolerance with these as well.

SRV records require a bit more explanation because they are so important to Active Directory. Here is an example SRV record in zone file format:

    _kerberos._tcp._sites.dc._msdcs 600 SRV 100 88 colossus.hasselltech.net.

The servicein this case, Kerberosis the leftmost part of the record, and the _tcprefers to whether the service operates on the TCP or UDP transmission protocols. The rightmost part of the record identifies the machine that is listening for requests for the service named in the record, in this case colossus.hasseltech.net. The first number in the middle, 600, indicates the time to live (TTL) for that record, recorded in seconds. The rightmost number, 88, refers to the port number on which the service is listening. Finally, 100 refers to the preference number for the recordthese work exactly like MX record preference numbers as described in the previous section.

Why are SRV records crucial to Active Directory? Because they indicate which domain machines are running what Active Directory services. Active Directory really looks for only four services to be advertised within SRV records:

_kerberos

To provide user and computer authentications using Kerberos Key Distribution Center (KDC) servers

_kpasswd

To provide a mechanism for changing Kerberos passwords securely

_ldap

For the Lightweight Directory Access Protocol, the way external programs communicate and exchange data with Active Directory

_gc

For the Global Catalog, which contains a subset of attributes for all the objects in an Active Directory forest

Stub Zones

In Windows Server 2003, a new zone type named stub zone has been introduced. A stub zone is a copy of a zone that contains only those resource records necessary to identify the authoritative DNS servers for that zone. A stub zone is used to resolve names between separate DNS namespaces. The need for this type of resolution can occur when a corporate merger requires that the DNS servers for two separate DNS namespaces resolve names for clients in both namespaces.

A stub zone consists of:

The start of authority (SOA) resource record, name server (NS) resource records, and the glue A resource records for the delegated zone.
The IP address of one or more master servers that can be used to update the stub zone.

The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary zone for the delegated domain name.

Stub zone resolution

When a DNS client performs a recursive query operation on a DNS server hosting a stub zone, the DNS server uses the resource records in the stub zone to resolve the query. The DNS server sends an iterative query to the authoritative DNS servers specified in the NS resource records of the stub zone as if it were using NS resource records in its cache. If the DNS server cannot find the authoritative DNS servers in its stub zone, the DNS server hosting the stub zone attempts standard recursion using its root hints.

The DNS server will store the resource records it receives from the authoritative DNS servers listed in a stub zone in its cache, but it will not store these resource records in the stub zone itself; only the SOA, NS, and glue A resource records returned in response to the query are stored in the stub zone. The resource records stored in the cache are cached according to the Time-to-Live (TTL) value in each resource record. The SOA, NS, and glue A resource records, which are not written to cache, expire according to the expire interval specified in the stub zone’s SOA record, which is created during the creation of the stub zone and updated during transfers to the stub zone from the original, primary zone.

If the query was an iterative query, the DNS server returns a referral containing the servers specified in the stub zone.

Stub zone updates

Stub zone updates involve the following conditions:

When a DNS server loads a stub zone, it queries the zone’s master server for the SOA resource record, NS resource records at the zone’s root, and glue A resource records.
During updates to the stub zone, the master server is queried by the DNS server hosting the stub zone for the same resource record types requested during the loading of the stub zone.
The Refresh interval of the SOA resource record determines when the DNS server hosting the stub zone will attempt a zone transfer (update).
If an update fails, the Retry interval of the SOA resource record determines when the update is retried.
Once the Retry interval has expired without a successful update, the expiration time as specified in the Expires field of the SOA resource record determines when the DNS server stops using the stub zone data.

Root Hints

Root hints are used to prepare servers authoritative for non-root zones so that they can learn and discover authoritative servers that manage domains located at a higher level or in other subtrees of the DNS domain namespace. These hints are essential for servers authoritative at lower levels of the namespace when locating and finding servers under these conditions.

For example, suppose a DNS server (Server A) has a zone called sub.example.microsoft.com. In the process of answering a query for a higher-level domain, such as the example.microsoft.com domain, Server A needs some assistance to locate an authoritative server (such as Server B) for this domain.

In order for Server A to find Server B, or any other servers that are authoritative for the microsoft.com domain, it needs to be able to query the root servers for the DNS namespace. The root servers can then refer Server A to the authoritative servers for the com domain. The servers for the com domain can, in turn, offer referral to Server B or other servers that are authoritative for the microsoft.com domain.

The root hints used by Server A must have helpful hints to the root servers for this process to locate Server B (or another authoritative server) as intended.

To configure and use root hints correctly, first determine how the following applies to your DNS servers:

Are you using DNS on the Internet or on a private network?
Is the server used as a root server?

By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the systemroot\System32\Dns folder on the server computer. This file normally contains the NS and A resource records for the Internet root servers. If, however, you are using the DNS Server service on a private network, you can edit or replace this file with similar records that point to your own internal root DNS servers.

Another server configuration in which root hints are treated differently is one in which a DNS server is configured to be used by other DNS servers in an internal namespace as a forwarder for any DNS queries of names managed externally (the Internet, for example). Even though the DNS server used as a forwarder can be located internally on the same network as servers using it as a forwarder, it needs hints for the Internet root servers to work properly and resolve external names.

Forwarding Sequence

The sequence in which the forwarders configured on a DNS server are used is determined by the order in which the IP addresses are listed on the DNS server. After the DNS server forwards the query to the forwarder with the first IP address, it waits a short period for an answer from that forwarder (according to the DNS server’s time out setting) before resuming the forwarding operation with the next IP address. It continues this process until it receives an affirmative answer from a forwarder.

Unlike conventional resolution, where a roundtrip time (RTT) is associated with each server, the IP addresses in the forwarders list are not ordered according to roundtrip time and must be reordered manually to change preference.

Forwarders and Delegation

A DNS server configured with a forwarder and hosting a parent zone will use its delegation information before forwarding queries. If no delegation record exists for the DNS name in the query, then the DNS server will use its forwarders to resolve the query.

Forwarders and Root Servers

A common error when configuring forwarding is to attempt to configure forwarding on the root servers of a private DNS namespace. The goal of attempting to configure forwarding on root servers for a private DNS namespace is to forward all offsite queries to Internet DNS servers. Root servers cannot be configured with standard forwarding. If a root server is queried about any domain name, then it will refer to a DNS server that can answer the question (from its local zones, cache), or it will respond with a failure (NXDOMAIN), but it cannot be configured to forward to specific servers.

Dynamic Update

Dynamic update enables DNS client computers to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use DHCP to obtain an IP address.

The DNS Client and Server services support the use of dynamic updates, as described in RFC 2136, “Dynamic Updates in the Domain Name System.” The DNS Server service allows dynamic update to be enabled or disabled on a per-zone basis at each server configured to load either a standard primary or directory-integrated zone. By default, the Windows Server 2003 DNS Client service will dynamically update host (A) resource records in DNS when configured for TCP/IP. The Windows Server 2003 DNS Server service is configured, by default, to allow only secure dynamic update. You must change this configuration if you will be using dynamic update only.

Protocol Description

RFC 2136 introduces a new opcode or message format called UPDATE. The update message can add and delete resource records from a specified zone as well as test for prerequisite conditions. Update is atomic, that is, all prerequisites must be satisfied or no update operation will take place.

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

A zone transfer process will always lock a zone so that a secondary DNS server receives 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 is locked very often for zone transfer purposes, it will starve dynamic update clients, and the system can become unstable. The Windows Server 2003 DNS Server service queues the update requests that arrived during the zone transfer and processes them after the zone transfer is completed.

How client and server computers update their DNS names

By default, computers that are statically configured for TCP/IP attempt to dynamically register host (A) and pointer (PTR) resource records for IP addresses configured and used by their installed network connections. All computers register records based on their fully qualified domain name (FQDN).

The following defaults also apply to how computers update their DNS names:

By default, the DNS client on Windows XP does not attempt dynamic update over a Remote Access Service or virtual private network connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry.
By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company.
By default, the primary DNS suffix portion of a computer’s FQDN is the same as the name of the Active Directory domain to which the computer is joined. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by modifying the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Dynamic updates can be sent for any of the following reasons or events:

An IP address is added, removed, or modified in the TCP/IP properties configuration for any one of the installed network connections.
An IP address lease changes or renews with the DHCP server any one of the installed network connections. For example, when the computer is started or if the ipconfig /renew command is used.
The ipconfig /registerdns command is used to manually force a refresh of the client name registration in DNS.
At startup time, when the computer is turned on.
A member server is promoted to a domain controller.

When one of the previous events triggers a dynamic update, the DHCP Client service (not the DNS Client service) sends updates. This is designed so that if a change to the IP address information occurs because of DHCP, corresponding updates in DNS are performed to synchronize name-to-address mappings for the computer. The DHCP Client service performs this function for all network connections used on the system, including connections not configured to use DHCP.

The update process described above assumes that installation defaults are in effect for computers running Windows 2000, Windows XP, or servers running Windows Server 2003. Specific names and update behavior is tunable where advanced TCP/IP properties are configured to use non-default DNS settings.

In addition to the full computer name (or primary name) of the computer, additional connection-specific DNS names can be configured and optionally registered or updated in DNS.

Example: How dynamic update works

Dynamic updates are typically requested when either a DNS name or IP address changes on the computer. For example, suppose a client named “oldhost” is first configured in System properties with the following names:

Computer name	oldhost
DNS domain name of computer	example.microsoft.com
Full computer name	oldhost.example.microsoft.com

In this example, no connection-specific DNS domain names are configured for the computer. Later, the computer is renamed from “oldhost” to “newhost”, resulting in the following name changes on the system:

Computer name	newhost
DNS domain name of computer	example.microsoft.com
Full computer name	newhost.example.microsoft.com

Once the name change is applied in System properties, you are prompted to restart the computer. When the computer restarts Windows, the DHCP Client service performs the following sequence to update DNS:

1. The DHCP Client service sends a start of authority (SOA) type query using the DNS domain name of the computer.

The client computer uses the currently configured FQDN of the computer (such as “newhost.example.microsoft.com”) as the name specified in this query.

2. The authoritative DNS server for the zone containing the client FQDN responds to the SOA-type query.

For standard primary zones, the primary server (owner) returned in the SOA query response is fixed and static. It always matches the exact DNS name as it appears in the SOA RR stored with the zone. If, however, the zone being updated is directory-integrated, any DNS server that is running on a domain controller for the Active Directory domain in the FQDN can respond and dynamically insert its own name as the primary server (owner) of the zone in the SOA query response.

3. The DHCP Client service then attempts to contact the primary DNS server.

The client processes the SOA query response for its name to determine the IP address of the DNS server authorized as the primary server for accepting its name. It then proceeds to perform the following sequence of steps as needed to contact and dynamically update its primary server:

o It sends a dynamic update request to the primary server determined in the SOA query response.

o If the update succeeds, no further action is taken.

o If this update fails, the client next sends an NS-type query for the zone name specified in the SOA record.

o When it receives a response to this query, it sends an SOA query to the first DNS server listed in the response.

o After the SOA query is resolved, the client sends a dynamic update to the server specified in the returned SOA record.

o If the update succeeds, no further action is taken.

o If this update fails, then the client repeats the SOA query process by sending to the next DNS server listed in the response.

4. Once the primary DNS server that can perform the update is contacted, the client sends the update request and the DNS server processes it.

The contents of the update request include instructions to add A (and possibly PTR) resource records for “newhost.example.microsoft.com” and remove these same record types for “oldhost.example.microsoft.com”, the name that was previously registered.

The DNS server also checks to ensure that updates are permitted for the client request. For standard primary zones, dynamic updates are not secured, so any client attempt to update succeeds. For Active Directory–integrated zones, updates are secured and performed using directory-based security settings. For more information, see “Secure Dynamic Updates” later in this document.

Dynamic updates are sent or refreshed periodically. By default, computers send a refresh once every seven days. If the update results in no changes to zone data, the zone remains at its current version and no changes are written. Updates result in actual zone changes or increased zone transfer only if names or addresses actually change.

Note that names are not removed from DNS zones if they become inactive or are not updated within the refresh interval (seven days). DNS does not use a mechanism to release or tombstone names, although DNS clients do attempt to delete or update old name records when a new name or address change is applied.

When the DHCP Client service registers A and PTR resource records for a computer, it uses a default caching Time to Live (TTL) of 15 minutes for host records. This determines how long other DNS servers and clients cache a computer’s records when they are included in a query response.

DNS and DHCP Clients and Servers

Windows 2000, Windows XP, and Windows Server 2003 DHCP clients are dynamic update-aware and can initiate the dynamic update process. A DHCP client negotiates the process of dynamic update with the DHCP server when the client leases an IP address or renews the lease, determining which computer updates the A and PTR resource records of the client. Depending on the negotiation process, the DHCP client, the DHCP server, or both, update the records by sending the dynamic update requests to the primary DNS servers that are authoritative for the names that are to be updated.

Clients and servers that are running versions of Windows earlier than Windows 2000 do not support dynamic update. The Windows 2000 and Windows Server 2003 DHCP Server service can perform dynamic updates on behalf of clients that do not support the DHCP Client service FQDN option (which is described in the following section). For example, clients that are running Microsoft Windows 95, Windows 98, and Windows NT do not support the FQDN option. However, this functionality can be enabled in the DNS tab of the server properties for the DHCP console. The DHCP server first obtains the name of legacy clients from the DHCP REQUEST packet. It then appends the domain name given for that scope and registers the A and PTR resource records.

In some cases, stale PTR or A resource records can appear on DNS servers when the lease of a DHCP client expires. For example, when a Windows 2000, Windows XP or Windows Server 2003 DHCP client tries to negotiate a dynamic update procedure with a Windows NT 4.0 DHCP server, the DHCP client must register both A and PTR resource records itself. Later, if the Windows 2000, Windows XP or Windows Server 2003 DHCP client is improperly removed from the network, the client cannot deregister its A and PTR resource records and they become stale.

If a stale A resource record appears in a zone that allows only secure dynamic updates, no computer is able to register any other resource record for the name in that A resource record. To prevent problems with stale PTR and A resource records, you can enable the aging and scavenging feature. For more information about the aging and scavenging feature, see “Understanding Aging and Scavenging” in this document.

To provide fault tolerance for dynamic updates, consider Active Directory integration for those zones that accept dynamic updates from Windows Server 2003 network-based clients. To speed up the discovery of authoritative DNS servers, you can configure each client with a list of preferred and alternate DNS servers that are primary for that directory-integrated zone. If a client fails to update the zone with its preferred DNS server because the DNS server is unavailable, the client can try an alternate server. When the preferred DNS server becomes available, it loads the updated, directory-integrated zone that includes the update from the client.

Dynamic Update Process for Network Connections Configured by DHCP

To negotiate the dynamic update process, the DHCP client sends its fully qualified domain name (FQDN) to the DHCP server in the DHCPREQUEST packet by using the DHCP Client service FQDN option. The DHCP server then replies to the DHCP client by sending a DHCP acknowledgment (DHCPACK) message that includes the FQDN option (option code 81).

The table below lists the fields of the FQDN option of the DHCPREQUEST packet.

Fields in the FQDN Option of the DHCPREQUEST Packet

Field	Explanation
Code	Specifies the code for this option (81).
Len	Specifies the length, in octets, of this option (minimum of 4).
Flags	Can be one of the following values: 0. Client wants to register the A resource record and requests that the server update the PTR resource record. 1. Client wants server to register the A and PTR resource records. 3. DHCP server registers the A and PTR resource records regardless of the request of the client.
RCODE1 and RCODE 2	The DHCP server uses these fields to specify the response code from the A and PTR resource records registrations performed on the client’s behalf and to indicate whether it attempted the update before sending DHCPACK.
Domain Name	Specifies the FQDN of the client.

The conditions under which DHCP clients send the FQDN option and the actions taken by DHCP servers depend on the operating system that the client and server are running and how the client and server are configured.

The client requests a dynamic update depending on whether or not it is running Windows Server 2003 operating system, Windows 2000, or earlier. It also depends on the client configuration. Clients can take any of the following actions:

By default, the Windows 2000, Windows XP and Windows Server 2003 DHCP Client service sends the FQDN option with the Flags field set to 0 to request that the client update the A resource record, and the DHCP Server service updates the PTR resource record. After the client sends the FQDN option, it waits for a response from the DHCP server. Unless the DHCP server sets the Flags field to 3, the client then initiates an update for the A resource record. If the DHCP server does not support or is not configured to perform registration of the DNS record, then no FQDN is included in the DHCP servers response and the client attempts registration of the A and PTR resource records.
If the DHCP client is running a Windows operating system earlier than Windows 2000, or if the client is Windows 2000 and it is configured not to register DNS resource records, then the client does not send the FQDN option. In this case, the client does not update either record.

Depending on what the DHCP client requests, the DHCP server can take different actions. If the DHCP client sends a DHCPREQUEST message without the FQDN option, behavior depends on the type of DHCP server and how it is configured. The DHCP server can update both records if it is configured to update records on behalf of DHCP clients that do not support the FQDN option.

In the following cases, the DHCP server does not perform any action:

The DHCP server does not support dynamic update (for example, a Windows NT 4.0 server).
The DHCP server is running Windows 2000 or Windows Server 2003 operating system and is configured not to do dynamic updates for clients that do not support the FQDN option.
The DHCP server is running Windows 2000 or Windows Server 2003 operating system and configured not to register DNS resource records.

If the Windows 2000, Windows XP or Windows Server 2003 network–based DHCP client requests that the server updates the PTR resource record but not the A resource record, behavior depends on the type of DHCP server and how it is configured. The server can perform any of the following actions:

If the DHCP server is running Windows 2000 or Windows Server 2003 operating system and is configured not to perform dynamic updates, its response does not contain the FQDN option and does not update either resource record. In this case, the DHCP client attempts to update both the A and PTR resource records, if it capable.
If the DHCP server is running Windows 2000 or Windows Server 2003 operating system and is configured to update according to the request of the DHCP client, the server attempts to update the PTR resource record. The DHCP server DHCPACK message to the DHCP client contains the FQDN option with the Flags set to 0, confirming that the DHCP server updates the PTR record. The DHCP client then attempts to update the A resource record, if it is capable.

If the DHCP server is running Windows 2000 or Windows Server 2003 operating system and is configured to always update A and PTR both records, the DHCP server attempts to update both resource records. The DHCP server DHCPACK message to the DHCP client contains the FQDN option with the Flags set to 3, notifying the DHCP client that the DHCP server updates A and PTR records. In this case, the DHCP client does not attempt to update either resource record.

Dynamic Update Process for Statically Configured and Remote Access Clients

Statically configured clients and remote access clients do not rely on the DHCP server for DNS registration. Statically configured clients dynamically update their A and PTR resource records every time they start and then every 24 hours in case the records become corrupted or need to be refreshed in the DNS database.

Remote access clients can dynamically update A and PTR resource records when a dial-up connection is made. They can also attempt to withdraw, or deregister, the A and PTR resource records when the user closes down the connection explicitly. Computers running Windows 2000 or Windows Server 2003 operating system with a remote access network connection attempt the dynamic registration of the A and PTR records corresponding to the IP address of this connection. By default, the DNS Client service on Windows XP does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network (VPN) connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry.

In all operating systems, if a remote access client does not receive a successful response from the attempt to deregister a DNS resource record, or if for any other reasons fails to deregister a resource record within four seconds, the DNS client closes the connection. In such cases, the DNS database might contain a stale record.

If the remote access client fails to deregister a DNS resource record, it adds a message to the event log, which you can view by using Event Viewer. The remote access client never deletes stale records, but the remote access server attempts to deregister the PTR resource record when the client is disconnected.

Windows 2000 dial-up networking clients attempt to register A and PTR records for the dial-up connection. By default, the Windows XP and Windows Server 2003 DNS Client service dial-up networking clients do not attempt to update A and PTR records automatically. Due to the nature of their business, it is common that ISPs do not enable dynamic updating of DNS information by their customers. If you use an ISP that does not support dynamic update, configure the connection properties to prevent the computer from performing dynamic updates.

Dynamic Update Process for Multihomed Clients

If a dynamic update client is multihomed (has more than one network connection and associated IP address), it registers the first IP address for each network connection by default. If you do not want it to register these IP addresses, you can configure the network connection to not register IP addresses.

The dynamic update client does not register all IP addresses with the DNS servers in all namespaces that the computer is connected to. For example, a multihomed computer, client1.noam.example.com, is connected to both the Internet and the corporate intranet. Client1 is connected to the intranet by adapter A, a DHCP adapter with the IP address 172.16.8.7. Client1 is also connected to the Internet by adapter B, a remote access adapter with the IP address 10.3.3.9. Client1 resolves intranet names by using a name server on the intranet, NoamDC1, and resolves Internet names by using a name server on the Internet, ISPNameServer.

Time to Live

Whenever a dynamic update client registers in DNS, the associated A and PTR resource records include the Time to Live (TTL), which by default is set to 10 minutes for records registered by the Net Logon service, and 15 minutes for records registered by the DHCP Client service. If the DNS Server service dynamically registers records for its own zones, the default TTL is 20 minutes. You can change the default setting in the registry. A small value causes cached entries to expire sooner, which increases DNS traffic but decreases the risk of cached records becoming outdated. Expiring entries quickly is useful for computers that frequently renew their DHCP leases. Long retention times are useful for computers that renew their DHCP leases infrequently.

Resolving Name Conflicts

When the DNS Client service attempts to register an A record and it discovers that the authoritative DNS zone already contains an A record for the same name but with a different IP address, by default, the DNS Client service attempts to replace the existing A record (s) with the new A record containing the IP address of the DNS client. As a result, any computer on the network can modify the existing A record unless secure dynamic update is used. Zones that are configured for secure dynamic update allow only authorized users to modify the resource record.

You can change the default setting so that the DNS Client service aborts the registration process and logs the error in Event Viewer, instead of replacing the existing A record.

Secure Dynamic Update

DNS update security is available only for zones that are integrated into Active Directory. Once you directory-integrate a zone, access control list (ACL) editing features are available in the DNS console so you can add or remove users or groups from the ACL for a specified zone or resource record. ACLs are for DNS administration access control only, and do not influence DNS query resolution.

By default, dynamic update security for DNS servers and clients are handled as follows:

DNS clients attempt to use unsecured dynamic update first. If an unsecured update is refused, clients try to use secure update.

Also, clients use a default update policy that permits them to attempt to overwrite a previously registered resource record, unless they are specifically blocked by update security.
Once a zone becomes Active Directory–integrated, DNS servers running Windows Server 2003 default to allowing only secure dynamic updates.

When using standard zone storage, the default for the DNS Server service is to not allow dynamic updates on its zones. For zones that are either directory-integrated or use standard file-based storage, you can change the zone to allow all dynamic updates which permits all updates to be accepted.

Dynamic update is a recent additional DNS standard specification, defined in RFC 2136. For more information about RFCs, see “Related Information” at the end of this document.

The dynamic registration of DNS resource records can be restricted with the use of registry entries.

How secure dynamic update works

The secure dynamic update process is described below:

To initiate a secure dynamic update, the DNS client first initiates the security context negotiation process, during which the tokens are passed between client and server using TKEY resource records. At the end of the negotiation process the security context is established.
Next, the DNS client sends the dynamic update request (containing resource records for the purpose of adding, deleting, or modifying data) to the DNS server, signed using the previously established security context and passing the signature in the TSIG resource record, included in the dynamic update packet.
The server attempts to update Active Directory using the clients credentials and sends the result of the update to the client. These results are signed using the security context and pass the signature in the TSIG resource record included in the response.

Secure dynamic update process

The secure dynamic update process is described below:

1. The DNS client queries the preferred DNS server to determine which DNS server is authoritative for the domain name it is attempting to update. The preferred DNS server responds with the name of the zone and the primary DNS server that is authoritative for the zone.

2. The DNS client attempts a standard dynamic update, and if the zone is configured to allow only secure dynamic updates (the default configuration for Active Directory-integrated zones), the DNS server refuses the non-secure update. Had the zone been configured for standard dynamic update rather than secure dynamic update, the DNS server would have accepted the DNS client’s attempt to add, delete, or modify resource records in that zone.

3. The DNS client and DNS server begin TKEY negotiation.

4. First, the DNS client and DNS server negotiate an underlying security mechanism. Windows dynamic update clients and DNS servers can only use the Kerberos protocol.

5. Next, by using the security mechanism, the DNS client and DNS server verify their respective identities and establish the security context.

6. The DNS client sends the dynamic update request to the DNS server, signed using the established security context . The signature is included in the signature field of the TSIG resource record that is included in the dynamic update request packet. The DNS server verifies the origin of the dynamic update packet by using the security context and the TSIG signature.

7. The DNS server attempts to add, delete, or modify resource records in Active Directory. Whether or not it can make the update depends on whether the DNS client has the proper permissions to make the update and whether the prerequisites have been satisfied.

8. The DNS server sends a reply to the DNS client stating whether or not it was able to make the update, signed using the established security context. The signature is included in the signature field of the TSIG resource record that is included in the dynamic update response packet. If the DNS client receives a spoofed reply, it ignores it and waits for a signed response.

Note

o DHCP clients running Windows 2000, Windows XP, or Windows Server 2003 explicitly request that the DHCP server update only pointer (PTR) resource records used in DNS for the reverse lookup and resolution of the client’s IP address to its name. These clients update their address (A) resource records for themselves.

o Clients running earlier versions of Windows cannot make an explicit request for DNS dynamic update protocol preference. For these clients, the DHCP service updates both the PTR and the A resource records.

Security for DHCP Clients That Do Not Support the FQDN Option

Windows DHCP clients that do not support the FQDN option (option 81) are not capable of dynamic updates. If you want the A and PTR resource records for these clients dynamically registered in DNS, you must configure the DHCP server to perform dynamic updates on their behalf.

However, having the DHCP server to perform secure dynamic updates on behalf of DHCP clients that do not support the FQDN option is undesirable because when a DHCP server performs a secure dynamic update on a name, that DHCP server becomes the owner of that name, and only that DHCP server can update any record for that name. This can cause problems in a few different circumstances.

For example, suppose that the DHCP server DHCP1 created an object for the name nt4host1.example.com and then stopped responding, and that later the backup DHCP server, DHCP2, tried to update a record for the same name, nt4host1.example.com. In this situation, DHCP2 is not able to update the name because it does not own the name. In another example, suppose DHCP1 added an object for the name nt4host1.example.com, and then the administrator upgraded nt4host1.example.com to a Windows 2000-based computer. Because the Windows 2000-based computer did not own the name, it would not be able to update DNS records for the name.

To solve this problem, the built-in security group called DnsUpdateProxy is provided. If all DHCP servers are added as members of the DnsUpdateProxy group, one servers records can be updated by another server if the first server fails. Also, because all objects created by the members of the DnsUpdateProxy group are not secured, the first user (that is not a member of the DnsUpdateProxy group) to modify the set of records associated with a DNS name becomes its owner. When legacy clients are upgraded, they can therefore take ownership of their name records at the DNS server. If every DHCP server registering resource records for older clients is a member of the DnsUpdateProxy group, the problems discussed earlier are eliminated.

Securing records when using the DnsUpdateProxy group

DNS domain names that are registered by the DHCP server are not secure when the DHCP server is a member of the DnsUpdateProxy group. As a result, do not use this group in an Active Directory integrated-zone that allows only secure dynamic updates without taking additional steps to allow records created by members of the group to be secured.

To protect against unsecured records, or to allow members of the DnsUpdateProxy group to register records in zones that allow only secured dynamic updates, Windows Server 2003 DHCP and DNS allow you to create a dedicated user account and configure DHCP servers to perform DNS dynamic updates with the user account credentials (user name, password, and domain). The credentials of one dedicated user account can be used by multiple DHCP servers.

The dedicated user account is a standard user account used only is supplying DHCP servers with credentials for DNS dynamic update registrations. Each DHCP server supplies these credentials when registering names on behalf of DHCP clients using DNS dynamic update. The dedicated user account is created in the same forest where the primary DNS server for the zone to be updated resides. The dedicated user account can also be located in another forest as long as the forest it resides in has a forest trust established with the forest containing the primary DNS server for the zone to be updated.

When installed on a domain controller, the DHCP Server service inherits the security permissions of the domain controller and has the authority to update or delete any DNS record that is registered in a secure Active Directory-integrated zone (this includes records that were securely registered by other computers running Windows 2000 or Windows Server 2003, including domain controllers). When installed on a domain controller, configure the DHCP server with the credentials of the dedicated user account to prevent the server from inheriting, and possibly misusing, the power of the domain controller.

Configure a dedicated user account and configure the DHCP Server service with the account credentials under the following circumstances:

A domain controller is configured to function as a DHCP server.
The DHCP server is configured to perform DNS dynamic updates on behalf of DHCP clients.
The DNS zones to be updated by the DHCP server are configured to allow only secure dynamic updates.

Once you have created a dedicated user account, you can configure DHCP servers with the user account credentials by using the DHCP console or by using the Netsh command (netsh dhcp server set dnscredentials).

Note

If the supplied credentials belong to an object (such as a computer) that is a member of the DnsUpdateProxy security group, the next object to register the same name record in DNS will become the record owner.
If you have specified credentials (user name, domain, and password) that the DHCP server uses when registering DHCP client computers in DNS, these credentials are not backed up with either synchronous or asynchronous backup. After a DHCP database is restored, new credentials must be configured.

Controlling Update Access to Zones and Names

Access to the DNS zones and resource records stored in Active Directory is controlled access control lists (ACLs). ACLs can be specified for the DNS Server service, an entire zone or for specific DNS names. By default, any authenticated Active Directory user can create the A or PTR resource records in any zone. Once an owner name has been created for a zone (regardless of the type of resource record), only the users or groups specified in the ACL for that name that have write permission are enabled to modify records corresponding to that name. While this approach is desirable in most scenarios, some special situations need to be considered separately.

DNSAdmins group

By default, the DNSAdmins group has full control of all zones and records in the Windows Server 2003 domain in which it is specified. In order for a user to be able to enumerate zones in a specific Windows Server 2003 domain, the user (or a group the user belongs to) must be enlisted in the DNSAdmin group.

It is possible that a domain administrator may not want to grant full control to all users listed in the DNSAdmins group. Typically, this would be the result if a domain administrator wanted to grant full control for a specific zone and read only control for other zones in the domain to a set of users. To accomplish this, the domain administrator can create a separate group for each of the zones, and add specific users to each group. Then the ACL for each zone will contain a group with full control for that zone only. At the same time, all of the groups will be included in the DNSAdmins group, which can be configured to have read permissions only. As a result of the fact that a zone’s ACL always contains the DNSAdmins group, all users enlisted in the zone-specific groups will have read permission for all the zones in the domain.

Reserving names

The default DNS Server service configuration of allowing any authenticated user to create a new name in a zone may not be sufficient for environments that require a high level of security. In such cases, the default ACL can be changed to allow for the creation of objects in a zone by certain groups or users only. Per-name administration of ACLs provides another solution to this problem. An administrator may reserve a name in a zone leaving the rest of the zone open for the creation of any new objects by all authenticated users. To accomplish this, an administrator creates a record for the reserved name and sets the appropriate list of groups or users in the ACL. As a result, only the users listed in the ACL will be able to register another record under the reserved name.

Understanding Aging and Scavenging

DNS servers running Windows Server 2003 support aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records (RRs), which can accumulate in zone data over time.

With dynamic update, RRs are automatically added to zones when computers start on the network. However, in some cases, they are not automatically removed when computers leave the network. For example, if a computer registers its own host (A) RR at startup and is later improperly disconnected from the network, its host (A) RR might not be deleted. If your network has mobile users and computers, this situation can occur frequently.

If left unmanaged, the presence of stale RRs in zone data might cause some problems. The following are examples:

If a large number of stale RRs remain in server zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.
DNS servers loading zones with stale RRs might use outdated information to answer client queries, potentially causing the client’s to experience name resolution problems on the network.
The accumulation of stale RRs at the DNS server can degrade its performance and responsiveness.
In some cases, the presence of a stale RR in a zone could prevent a DNS domain name from being used by another computer or host device.

To solve these problems, the DNS Server service has the following features:

Time stamping, based on the current date and time set at the server computer, for any RRs added dynamically to primary-type zones. In addition, time stamps are recorded in standard primary zones where aging/scavenging is enabled.
For RRs that you add manually, a time stamp value of zero is used, indicating that they are not affected by the aging process and can remain without limitation in zone data unless you otherwise change their time stamp or delete them.
Aging of RRs in local data, based on a specified refresh time period, for any eligible zones. Only primary type zones that are loaded by the DNS Server service are eligible to participate in this process.
Scavenging for any RRs that persist beyond the specified refresh period. When a DNS server performs a scavenging operation, it can determine that RRs have aged to the point of becoming stale and remove them from zone data. Servers can be configured to perform recurring scavenging operations automatically, or you can initiate an immediate scavenging operation at the server.

Note

By default, the aging and scavenging mechanism for the DNS Server service is disabled. It should only be enabled when all parameters are fully understood. Otherwise, the server could be accidentally configured to delete records that should not be deleted. If a record is accidentally deleted, not only will users fail to resolve queries for that record, but any user can create the record and take ownership of it, even on zones configured for secure dynamic update.

The server uses the contents of each RR-specific time stamp, along with other aging/scavenging properties that you can adjust or configure, to determine when it scavenges records.

Prerequisites for Aging and Scavenging

Before the aging and scavenging features of DNS can be used, several conditions must be met:

1. Scavenging and aging must be enabled both at the DNS server and on the zone.

By default, aging and scavenging of resource records is disabled.

2. Resource records must either be dynamically added to zones or manually modified to be used in aging and scavenging operations.

Typically, only those resource records added dynamically using the DNS dynamic update protocol are subject to aging and scavenging.

You can, however, enable scavenging for other resource records added through non-dynamic means. For records added to zones in this way, either by loading a text-based zone file from another DNS server or by manually adding them to a zone, a time stamp of zero is set. This makes these records ineligible for use in aging/scavenging operations.

In order to change this default, you can administer these records individually, to reset and permit them to use a current (non-zero) time stamp value. This enables these records to become aged and scavenged.

Note

In the case of changing a zone from standard primary to Active Directory–integrated, you might want to enable scavenging of all existing resource records in the zone. To enable aging for all existing resource records in a zone, you can use the AgeAllRecords command, which is available through the dnscmd command-line tool.

Aging and Scavenging Terminology

The following list indicates new or revised terms that have been introduced to help specifically when discussing aging and scavenging.

Current server time The current date and time on the DNS server. This number can be expressed as an exact numeric value at any point in time.

No-refresh interval An interval of time, determined for each zone, as bounded by the following two events:

The date and time when the record was last refreshed and its time stamp set.
The date and time when the record next becomes eligible to be refreshed and have its time stamp reset.

This value is needed to decrease the number of write operations to the Active Directory database. By default, this interval is set to seven days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.

Record refresh When a DNS dynamic update is processed for a resource record when only the resource record time stamp, and no other characteristics of the record, are revised. Refreshes generally occur for the following reasons:

When a computer is restarted on the network and, if at startup, its name and IP address information are consistent with the same name and address information it used prior to being shut down, it sends a refresh to renew its associated resource records for this information.
A periodic refresh is sent by the computer while it is running.
The Windows XP and Windows Server 2003 DNS Client service renews DNS registration of client resource records every 24 hours. When this dynamic update occurs, if the dynamic update request does not cause modification to the DNS database, then it is considered to be a refresh and not a resource record update.
Other network services make refresh attempts, such as: DHCP servers which renew client address leases, cluster servers which register and update records for a cluster, and the Net Logon service, which can register and update resource records used by Active Directory domain controllers.

Record update When a DNS dynamic update is processed for a resource record where other characteristics of the record in addition to its time stamp are revised. Updates generally occur for the following reasons:

When a new computer is added to the network and, at startup, it sends an update to register its resource records for the first time with its configured zone.
When a computer with existing records in the zone has a change in IP address, causing updates to be sent for its revised name-to-address mappings in DNS zone data.
When the Net Logon service registers a new Active Directory domain controller.

Refresh interval An interval of time, determined for each zone, as bounded by the following two distinct events:

The earliest date and time when the record becomes eligible to be refreshed and have its time stamp reset.
The earliest date and time when the record becomes eligible to be scavenged and removed from the zone database.

This value should be large enough to allow all clients to refresh their records. By default, this interval is set to seven days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.

Resource record (RR) time stamp A date and time value used by the DNS server to determine removal of the resource record when it performs aging and scavenging operations.

Scavenging period When automatic scavenging is enabled at the server, this period represents the time between repetitions of the automated scavenging process. The default value for this is seven days. To prevent deterioration of DNS server performance, the minimum allowed value for this is one hour.

Scavenging servers An optional advanced zone parameter that enables you to specify a restricted list of IP addresses for DNS servers that are enabled to perform scavenging of the zone. By default, if this parameter is not specified, all DNS servers that load a directory-integrated zone (also enabled for scavenging) attempt to perform scavenging of the zone. In some cases, this parameter can be useful if it is preferable that scavenging only be performed at some servers loading the directory-integrated zone. To set this parameter, you must specify the list of IP addresses for the servers enabled to scavenge the zone in the ScavengingServers parameter for the zone. This can be done using the dnscmd command, a command-line based tool for administering Windows DNS servers.

Start scavenging time A specific time, expressed as a number. This time is used by the server to determine when a zone becomes available for scavenging.

When Scavenging Can Start

Once all prerequisites for enabling the use of scavenging are met, scavenging can start for a server zone when the current server time is greater than the value of the start scavenging time for the zone.

The server sets the time value to start scavenging on a per-zone basis whenever any one of the following events occurs:

Dynamic updates are enabled for the zone.
A change in the state of the Scavenge stale resource records check box is applied. You can use the DNS console to modify this setting at either an applicable DNS server or one of its primary zones.
The DNS server loads a primary zone enabled to use scavenging. This can occur when the server computer is started or when the DNS Server service is started.
When a zone resumes service after having been paused.

When any of the previous events occur, the DNS server sets the value of start scavenging time by calculating the following sum:

Current server time + Refresh interval = Start scavenging time

This value is used as a basis of comparison during scavenging operations.

Example of the aging and scavenging process for a sample record

To understand the process of aging and scavenging at the server, consider the life span and successive stages of a single resource record, as it is added to a server and zone where this process is in effect and then aged and removed from the database.

1. A sample DNS host, “host-a.example.microsoft.com”, registers its host (A) resource record at the DNS server for a zone where aging/scavenging is enabled for use.

2. When registering the record, the DNS server places a time stamp on this record based on current server time.

After the record time stamp is written, the DNS server does not accept refreshes for this record for the duration of the zone no-refresh interval. It can, however, accept updates prior to that time. For example, if the IP address for “host-a.example.microsoft.com” changes, the DNS server can accept the update. In this case, the server also updates (resets) the record time stamp.

3. Upon expiration of the no-refresh period, the server begins to accept attempts to refresh this record.

Once the initial no-refresh period ends, the refresh period immediately begins for the record. During this time, the server does not suppress attempts to refresh the record for its remaining life span.

4. During and after the refresh period, if the server receives a refresh for the record, it processes it.

This resets the time stamp for the record based on the method described in step 2.

5. When subsequent scavenging is performed by the server for the “example.microsoft.com” zone, the record (and all other zone records) are examined by the server.

Each record is compared to current server time on the basis of the following sum to determine whether the record should be removed:

Record time stamp + No-refresh interval for zone + Refresh interval for zone

o If the value of this sum is greater than current server time, no action is taken and the record continues to age in the zone.

o If the value of this sum is less than current server time, the record is deleted both from any zone data currently loaded in server memory and also from the applicable DnsZone object store in Active Directory for the directory-integrated “example.microsoft.com” zone.

Pages

Thursday, 22 March 2012

Complete DNS and features and DNS queries

Authoritative name server

Recursive and caching name server

DNS Resolvers

DNS resource records

Wildcard DNS records

Understanding zones and zone transfer

Understanding the difference between zones and domains

Why zone replication and zone transfers are needed

Incremental zone transfers

Example: Zone transfer

DNS Notify

Reverse lookup

Example: Reverse query (for IPv4 networks)

Inverse queries

Understanding forwarders

Conditional forwarders

Intranet name resolution

Internet name resolution

Host (A) Records

Canonical Name (CNAME) Records

Mail Exchanger (MX) Records

Name-server (NS) Records

Start of Authority (SOA) Records

Pointer (PTR) Records

Service (SRV) Records

Stub Zones

Stub zone resolution

Stub zone updates

Root Hints

Forwarding Sequence

Forwarders and Delegation

Forwarders and Root Servers

Dynamic Update

Protocol Description

How client and server computers update their DNS names

Example: How dynamic update works

DNS and DHCP Clients and Servers

Dynamic Update Process for Network Connections Configured by DHCP

Dynamic Update Process for Statically Configured and Remote Access Clients

Dynamic Update Process for Multihomed Clients

Time to Live

Resolving Name Conflicts

Secure Dynamic Update

How secure dynamic update works

Secure dynamic update process

Security for DHCP Clients That Do Not Support the FQDN Option

Securing records when using the DnsUpdateProxy group

Controlling Update Access to Zones and Names

DNSAdmins group

Reserving names

Understanding Aging and Scavenging

Prerequisites for Aging and Scavenging

Aging and Scavenging Terminology

When Scavenging Can Start

Example of the aging and scavenging process for a sample record

No comments:

Post a Comment