DNS DNS stands for Domain Name System; DNS is one of the industry-standard suite of protocols that comprise

TCP/IP. Network resources are identified by numeric IP addresses, but these IP addresses are difficult for network users to remember. The DNS database contains records that map user-friendly alphanumeric names for network resources to the IP address used by those resources for communication. In this way, DNS acts as a mnemonic device, making network resources easier to remember for network users.DNS is part of the application layer of the TCP/IP reference model. DNS is implemented using two software components: the DNS server and the DNS client (or resolver). Both components are run as background service applications. Technologies That Use DNS: DNS and Active Directory Active Directory uses DNS as its domain controller location mechanism. When any Active Directory operations are performed, such as authentication, updating, or searching, Windows Server 2003 computers use DNS to locate Active Directory domain controllers and these domain controllers use DNS to locate each other. For example, when a network user with an Active Directory user account logs in to an Active Directory domain, the users computer uses DNS to locate a domain controller for the Active Directory domain to which the user wants to log in. DNS and WINS The earlier method of name resolution for a Windows network was Windows Internet Name Service (WINS). DNS is different than WINS in that DNS is a hierarchical namespace and WINS is a flat namespace. Down-level clients and applications that rely on NetBIOS names continue to use WINS for name resolution. Since Windows Server 2003 DNS is WINS-aware, a combination of both DNS and WINS can be used in a mixed environment to achieve maximum efficiency in locating various network services and resources. DNS and DHCP For Windows Server 2003 DNS, the DHCP service provides default support to register and update information for DHCP clients in DNS zones. The Windows Server 2003 DNS-DHCP integration enables a DHCP client that is unable to dynamically update DNS resource records directly to have this information updated in DNS forward and reverse lookup zones by the DHCP server. DNS Zones Overview A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server has authority. A zone is a portion of a namespace. It is not a domain. A domain is a branch of the DNS namespace. A DNS zone can contain one or more contiguous domains. A DNS server can be authoritative for multiple DNS zones. A non-contiguous namespace cannot be a DNS zone. A zone contains the resource records for all of the names within the particular zone. Zone files are used if DNS data is not integrated with Active Directory. The zone files contain the DNS database resource records that define the zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory. The different types of zones used in DNS are listed below:

Primary Zone: A master copy of a forward or reverse lookup zone, the server hosting this zone is authoritative for the domain name. When the zone is created, a file with the suffix .dns is created in the %windir%\System32\dns subdirectory of the DNS server. Secondary zone: A secondary zone is a read-only copy of the zone that was copied from the master server during zone transfer. Active Directory-integrated zone: An Active Directory-integrated zone is a zone that stores its zone data in Active Directory. DNS zone files are not needed. This type of zone is an authoritative primary zone. Zone data of an Active Directory-integrated zone is replicated during the Active Directory replication process.

An Active Directory-integrated zone can be defined as an improved version of a primary DNS zone because it can use multimaster replication and the security features of Active Directory. The zone data of Active Directory-integrated zones are stored in Active Directory. Active Directory-integrated zones are authoritative primary zones. A few advantages that Active Directory-integrated zone implementations have over standard primary zone implementations are: Active Directory replication is faster, which means that the time needed to transfer zone data between zones is far less. The Active Directory replication topology is used for Active Directory replication, and for Active Directory-integrated zone replication. There is no longer a need for DNS replication when DNS and Active Directory are integrated. Active Directory-integrated zones can enjoy the security features of Active Directory. The need to manage your Active Directory domains and DNS namespaces as separate entities is eliminated. This in turn reduces administrative overhead. When DNS and Active Directory are integrated; the Active Directory-integrated zones are replicated, and stored on any new domain controllers automatically. Synchronization takes place automatically when new domain controllers are deployed. Stub zone: A stub zone is a new Windows Server 2003 feature. Stub zones only contain those resource records necessary to identify the authoritative DNS servers for the master zone. You can use stub zones to:

Keep delegated zone information current. By updating a stub zone for one of its child zones regularly, the DNS server that hosts both the parent zone and the stub zone will maintain a current list of authoritative DNS servers for the child zone.

Improve name resolution. Stub zones enable a DNS server to perform recursion using the stub zone's list of name servers, without having to query the Internet or an internal root server for the DNS namespace. Simplify DNS administration. By using stub zones throughout your DNS infrastructure, you can distribute a list of the authoritative DNS servers for a zone without using secondary zones. However, stub zones do not serve the same purpose as secondary zones, and they are not an alternative for enhancing redundancy and load sharing. There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

The list of master servers from which the DNS server loads and updates a stub zone. A master server may be a primary or secondary DNS server for the zone. In both cases, it will have a complete list of the DNS servers for the zone.

The list of the authoritative DNS servers for a zone. This list is contained in the stub zone using name server (NS) resource records. When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the master servers, which can be in different locations, for the necessary resource records of the authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may contain a single server or multiple servers, and it can be changed anytime.

Understanding Forward Lookups and Reverse Lookups

Forward lookup zone contains a mapping between host names and IP addresses. When a computer requests an IP address
by providing a host name (which is easier to use), forward lookup zone is queried to locate the IP address of the given host name.

Reverse lookup zone has a mapping that links IP addresses to host names. When a computer asks for a domain name by providing an IP address, the reverse lookup zone is challenged to find the host name to IP address given. For example, if a customer wants to see the host name corresponding to IP

What is the difference between Forward Lookup and Reverse Lookup Zone? The main difference between forward lookup zone and the reverse lookup zone is that forward lookup zone is used to resolve the Host names (Friendly Name) to IP addresses whereas the reverse lookup zone is used to resolve the IP addresses to Host names . Forward lookup zone holds records A type resource records that can show an IP address for a provided hostname. The reverse lookup zone contains PTR records that can show a host name for a given IP address. DNS Record types:

1. A - Address record allowing a computer name to be translated into an IP address. Each computer must have this record for
its IP address to be located. These names are not assigned for clients that have dynamically assigned IP addresses, but are a must for locating servers with static IP addresses. 2. AAAA Host resource record for IPv6 protocol. 3. AFDSB - Andrew File System Database resource record 4. ATMA - Asynchronous Transfer Mode resource record. 5. CNAME - Canonical name allowing additional names or aliases to be used to locate a computer. 6. HINFO - Host information record with CPU type and operating system. 7. ISDN - Integrated Services Digital Network resource record. 8. MB - Mailbox resource record. 9. MG - Mail group resource record. 10. MINFO - Mailbox mail list information resource record. 11. MR - Mailbox renamed resource record. 12. MX - Mail Exchange server record. There may be several. 13. NS - Name server record. There may be several. 14. PTR - Pointer resource record. 15. RP - Responsible person. 16. RT - Route through resource record for specifying routes for certain DNS names. 17. SOA - Start of Authority record defines the authoritative server and parameters for the DNS zone. These include timeout values, name of responsible person, 18. SRV - Service locator resource record to map a service to servers providing the service. Windows 2000 clients will use this record to find a domain controller. 19. TXT - Test resource record for informative text. 20. WKS - Well known service resource record. 21. X25 - To map a host name to an X.25 address. Types of DNS records There are many types of records that can be used in DNS. Here are the most common. A records - address data An A record is used to map a hostname to an IP address. This example shows that the IP for mail.example.com is 192.0.2.3 mail.example.com. IN A 192.0.2.3

MX records - mail exchange information MX records indicate which server or servers are responsible for handling mail for the domain. A numerical priority determines the order in which servers should be used. The server with the lowest priority is the primary. In this example, mail.example.com handles mail, but yarrina.connect.com.au will also accept mail if the primary is down: example.com. example.com. IN MX IN MX 10 mail.example.com. 100 yarrina.connect.com.au.

NS records - delegation information NS records indicate which nameservers are responsible for the domain. In this example, the domain is delegated to AAPT's nameservers: example.com. example.com. IN NS IN NS yarrina.connect.com.au. warrane.connect.com.au.

CNAME records - make an alias If you want a hostname to be an alias for some other domain, you can give it a CNAME record to indicate the real domain that it is aliasing. In this example, server.example is the real domain name, but ftp.example.com. is an alias for it that can also be used: ftp.example.com. IN CNAME server.example.com.

PTR records - reverse DNS data Whereas A records map hostnames to IP addresses, PTR records make it possible to start with an IP address and discover which hostname points to it. In this example, 192.0.2.3 maps back to mail.examnple.com, so it matches the A record above: 3.2.0.192.in-addr.arpa. IN PTR mail.example.com. Note that the IP address is inversed and prepended to "in-addr.arpa." to make it fit into the DNS. This is mostly used as a security and an anti-spam measure wherein most of the web servers or the email servers do a reverse DNS lookup to check if the host is actually coming from where it claims to come from. It is always advisable to have a proper reverse DNS record (PTR) is been setup for your servers especially when you are running a mail / smtp server. SOA Records: SOA records stand for Start of Authority. This is the most important record for a domain. This server indicates the start of authority for the specified domain and will have more information unlike other where there is only one specific information is provided. The SOA Record indicates the Primary Authoritative server for a Domain, a contact email address, the serial number and the various time related information. The Serial number is the key element which indicates if a Slave or a secondary server should update its information. Everytime a change was made to DNS records, this number is incremented only then when a slave DNS server contacts the primary server will know that there was a change made and hence have to update its record. For this case, the serial number is always used in the YYYYMMDDXX format where YYYYMMDD indicates the date of the day the changes were made and XX indicates the nth number of time the records were changed. SOA Record Syntax: itsyourip.com in SOA ns1.beta.timdorr.com. server.asmallorange.com. 2006011501 ; Serial14400 ; Refresh 7200 ; Retry 3600000 ; Expire 86400 ) ; Minimum Where, IN indicates Internet SOA indicates Start of Authority record ns1.beta.timdorr.com is the Primary Name Server Server.(@)asmallorange.com is the contact email Serial indicates the Serial Number Refresh indicates the time in which it should contact the Primary server for changes in the DNS records (Serial Number) Retry indicates the time in which the slave server should retry in the event a connection was refused by the Primary Server. Expire indicates when the local information that the slave server holds becomes invalid in the event it cannot refresh from the Primary server. Minimum indicates how long other DNS servers should hold this domains information in its cache.

The authoritative server field shows the primary DNS server authoritative for the zone. The responsible person field shows the e-mail address of the administrator responsible for the zone. It uses a period (.) instead of an at symbol (@). The serial number field shows how many times the zone has been updated. When a zone's secondary server contacts the master server for that zone to determine whether it needs to initiate a zone transfer, the zone's secondary server compares its own serial number with that of the master. If the serial number of the master is higher, the secondary server initiates a zone transfer. The refresh field shows how often the secondary server for the zone checks to see whether the zone has been changed. The retry field shows how long after sending a zone transfer request the secondary server for the zone waits for a response from the master server before retrying.

The expire field shows how long after the previous zone transfer the secondary server for the zone continues to respond to queries for the zone before discarding its own zone as invalid. The minimum TTL field applies to all the resource records in the zone whenever a time to live value is not specified in a resource record. Whenever a resolver queries the server, the server sends back resource records along with the minimum time to live. Negative responses are cached for the minimum TTL of the SOA resource record of the authoritative zone.

Service (SRV) Resource Records Service (SRV) resource records are typically used by Active directory to locate domain controllers, LDAP servers, and global catalog servers. The SRV records define the location of specific services in a domain. They associate the location of a service such as a domain controller or global catalog server with details on how the particular service can be contacted. The fields of the service (SRV) resource record are explained below:

Service name The protocol used The domain name associated with the SRV records The port number for the particular service The Time to Live value The class The priority and weight The target specifying the FQDN of the particular host supporting the service

The format of an SRV record is as follows: _Service._Proto.Name TTL Class SRV Priority Weight Port Target

The _ Service field specifies the name of the service, such as http or telnet. Some services are defined in the standards, and others can be defined locally. The _ Proto field specifies the protocol, such as TCP or UDP. The Name field specifies the domain name to which the resource record refers. The TTL and Class fields are the same as the fields defined earlier in this chapter. The Priority field specifies the priority of the host. Clients attempt to contact the host with the lowest priority. The Weight field is a load balancing mechanism. When the priority field is the same for two or more records in the same domain, clients should try records with higher weights more often, unless the clients support some other load balancing mechanism. The Port field shows the port of the service on this host. The Target field shows the fully qualified domain name for the host supporting the service.

The following example shows SRV records for Web servers: _http._tcp.reskit.com. IN SRV 0 0 80 webserver1.noam.reskit.com. _http._tcp.reskit.com. IN SRV 10 0 80 webserver2.noam.reskit.com. Note This example does not specify a TTL. Therefore, the resolver uses the minimum TTL specified in the SOA resource record. If a computer needs to locate a Web server in the reskit.com DNS domain, the resolver sends the following query: _http._tcp.www.reskit.com. The DNS server replies with the SRV records listed above. The resolver then chooses between WebServer1 and WebServer2 by looking at their priority values. Because WebServer1 has the lowest priority value, the DNS server chooses WebServer1. Note

If the priority values had been the same, but the weight values had been different, the client would have chosen a Web server randomly, except that the server with the highest weight value would have had a higher probability of being chosen. Next, the resolver requests the A record for webserver1.reskit.com, and the DNS server sends the A record. Finally, the client attempts to contact the Web server. For more information about SRV records, see the Internet Engineering Task Force (IETF) link on the Web Resources page. Windows 2000 supports the Internet Draft titled "A DNS RR for specifying the location of services (DNS SRV)." DNS Queries Overview The naming system used by DNS is a hierarchical namespace, called the DNS namespace. The DNS namespace has a unique root. The root can contain numerous subdomains. Each subdomain also can contain multiple subdomains. Each domain registered in DNS is connected to a DNS name server. The DNS server of a domain provides authoritative replies to queries for that particular domain. Three query types exist for querying a DNS server for name resolution:

Iterative queries Recursive queries Inverse queries

A DNS client queries a DNS server to resolve a host name into an IP address. The query contains the following important information:

The DNS domain name in the FQDN format. The query type The class for the DNS domain name

When a DNS server is queried it can do one of the following:

Respond to the request directly by providing the requested information. Provide a pointer (referral) to another DNS server that can assist in resolving the query Respond that the information is unavailable Respond that the information does not exist

The different query response types which can be returned from the DNS server are:

Authoritative answer: This is a positive response which is returned to a client. The authority bit set in the DNS message indicates that the reply was received from a DNS server that has direct authority for the name queried in the message. Positive answer: This response type returns the queried resource record that corresponds to the name and record type queried in the original query. Referral answer: A referral response is returned if the DNS server does not support recursion. A referral contains additional resource records for resolving the request. Negative answer: A negative answer is returned to the client when the following events occur: o The name queried does not exist in the DNS namespace. This information is obtained from an authoritative server.

The authoritative server indicated that the name queried does exist in the DNS namespace. However, there are no resource records of this type present for the requested name.

If a DNS server cannot find the queried name in its zone information, or in its cache; the DNS server performs recursion to resolve the name. This is the default configuration for DNS servers. Recursion is the process whereby which the DNS server queries other DNS servers for the client. By the initial DNS server querying the other DNS servers, recursion actually ends up making the initial DNS server a DNS client! In order to perform recursion, root hints assist the DNS server in determining where in the DNS namespace it should commence searching for the queried name. Root hints is a collection of resource records which the DNS Server service utilizes to locate DNS servers who are authoritative for the root of the DNS domain namespace structure. If you are using Windows Server 2003 DNS, a preconfigured root hints file named Cache.dns already exists. The file can be found in the WINDOWSSystem32Dns directory. Cache.dns contains the addresses of root servers in the Internet DNS namespace, and is preloaded to memory when the DNS Server service initiates. If however recursion is disabled for the DNS server, and the DNS server cannot find a match for the queried name in its zone information, or in its cache; the client begins to perform iterative queries. The root hint referrals from the DNS server are used for iterative queries. When a client performs iterative queries, the client sends repeated requests to different DNS servers to resolve the queried name. The process that occurs to resolve a name requested in a query is outlined below: 1. 2. 3. 4. 5. 6. 7. 8. 9. The resolver sends a recursive DNS query to its local DNS server, to request the IP address of a particular name. Because the local DNS server cannot refer the resolver to a different DNS server, the local DNS server attempts to resolve the requested domain name. The local DNS server checks its zones. If it finds no zones for the requested domain name, the local DNS server sends an iterative query for the requested name to the root DNS server. The root DNS server is authoritative for the root domain. It responds with an IP address of a name server for the specific toplevel domain. The local DNS server next sends an iterative query for the requested name to this name server who in turn replies with the IP address of the particular name server servicing the requested domain name. The local DNS server then sends an iterative query for the requested name to the particular name server servicing the particular domain. The name server responds with the requested IP address. The IP address is returned to the resolver.

Understanding Recursive Queries When a client sends a recursive query to a DNS server, the DNS server has to return either of the following responses.

The resource record containing the IP address that is associated with the host name that was requested. An error message can also be returned to the client, stating that the host name or domain does not exist. When the DNS server does not find the queried name in its zone information, it starts querying other DNS servers. The error is only returned to the client when it cannot obtain the required information from any of the other DNS servers.

You can use the DNS console to disable recursive queries for a specific DNS server. In this case, the DNS server will only be able to use iterative queries. Understanding Iterative Queries When a client sends an iterative query to a DNS server, the DNS server returns the best answer which it can to the client. The response can be either of the following:

The requested resolved name. A referral to a different DNS server that could provide the information which the client requested.

Referrals are just pointers to a DNS server that has authority for a lower portion of the DNS namespace. Understanding Inverse Queries In an inverse query, the DNS resolver sends a request to a DNS server to resolve the host name associated with a known IP address. Only a thorough search of all domains would provide the correct answer. DNS resolvers are programs that use DNS queries to request

information from the DNS servers. In Windows Server 2003, the DNS Client service performs the function of the DNS resolver. A DNS resolver can communicate and issue name queries to remote DNS servers, or to the DNS server running locally.

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. The zone transfer methods are:

Full transfer: When the user configures a secondary DNS server for a zone and starts the secondary DNS server, the secondary DNS server requests a full copy of the zone from the primary DNS server. A full transfer of all the zone information is performed. Full zone transfers tend to be resource intensive. This disadvantage of full transfers has led to the development of incremental zone transfers.

Incremental zone transfer: With an incremental zone transfer, only those resource records that have since changed in a zone are transferred to the secondary DNS servers. During zone transfer, the DNS database is on the primary. DNS server and the secondary DNS server are compared to determine whether there are differences in the DNS data. If the primary and secondary DNS servers data are the same, zone transfer does not take place. If the DNS data of the two servers are different, transfer of the delta resource records starts. This occurs when the serial number on the primary DNS server database is higher than that of secondary DNS server. For incremental zone transfer to occur, the primary DNS server has to record incremental changes to its DNS database. Incremental zone transfers require less bandwidth than full zone transfers.

Active Directory transfers: These zone transfers occur when Active Directory-integrated zones are replicated to the domain controllers in a domain. Replication occurs through Active Directory replication.

DNS Notify: is a mechanism that enables a primary DNS server to inform secondary DNS servers when its database has been updated. DNS Notify informs the secondary DNS servers when they need to initiate a zone transfer so that the updates of the primary DNS server can be replicated to them. When a secondary DNS server receives the notification from the primary DNS server, it can start an incremental zone transfer or a full zone transfer to pull zone changes from the primary DNS servers.

Reverse DNS

Reverse DNS is the process of using DNS to translate IP addresses to hostnames. It is the opposite of forward DNS, which is used to translate hostnames to IP addresses. A special PTR-record type is used to store reverse DNS entries. The name of the PTR-record is the IP address with the segments reversed + ".in-addr.arpa". For example the reverse DNS entry for IP 1.2.3.4 would be stored as a PTR-record for "4.3.2.1.in-addr.arpa". Reverse DNS is also different from forward DNS in who points the zone (domain name) to your DNS server. With forward DNS, you point the zone to your DNS server by registering that domain name with a registrar. With reverse DNS, your Internet connection provider (ISP) must point (or "sub-delegate") the zone ("....in-addr.arpa") to your DNS server. Without this sub-delegation from your ISP, your reverse zone will not work.

Reverse DNS is mostly used by humans for such things as tracking where a web-site visitor came from, or where an e-mail message originated etc. It is typically not as critical in as forward DNS - visitors will still reach your web-site just fine without any reverse DNS for your web-server IP or the visitor's IP.

However reverse DNS is important for one particular application. Many e-mail servers on the Internet are configured to reject incoming e-mails from any IP address which does not have reverse DNS. So if you run your own e-mail server, reverse DNS must exist for the IP address that outgoing e-mail is sent from. It does not matter what the reverse DNS record for your IP address points to as long as it is there. If you host multiple domains on one e-mail server, just setup reverse DNS to point to whichever domain name you consider primary. (E-mail servers checking for reverse DNS do recognize that it is normal to host many domains on a single IP address and it would be impossible to list all those domains in reverse DNS for the IP). Reverse DNS Delegation When someone registers a domain name with a domain registrar, he/she usually becomes responsible for that Forward DNS domain. In DNS terms, the domain is delegated to the person who registers the domain name. However, this person is not responsible for his/her reverse records. His/her Reverse DNS records are still most likely the responsibility of your hosting facility or ISP. To change the Reverse DNS PTR records, contact the company where the IP address came from, usually a hosting facility or an ISP. Alternatively, the ISP or hosting company may delegate a range of IP addresses to the user, in which case the user must configure Reverse DNS and PTR records in his/her DNS server. Is Reverse DNS Necessary? Some junior DNS administrators configure forward DNS and forget to configure reverse DNS. When they do this, some things work fine. Internet web browsing, for example, works great. However, not everything works. Reverse DNS is required by some Internet protocols and by extensions to some other Internet protocols. Without reverse DNS, users will experience trouble with r-commands, IRC, some SMTP servers, most enterprise management systems, and many network backup systems. Troubleshooting problems that faulty or non-existent reverse DNS cause can take considerable time and effort. It is much better to ensure that reverse DNS is configured correctly from the beginning. Caching Only Servers All DNS Servers cache the results of their queries. However, some DNS Servers are put into place to provide only this caching function. The Caching-only DNS server does not contain zone information or a zone database file. The Caching-only server only contains information based on the results of queries that it has already performed. In this case, the cache takes the place of the zone database file. These Caching-only DNS Servers can be set up quickly, and are an important ally in your network and Internet security design. All DNS servers have a cache.dns file that contains the IP addresses of all Internet root servers. The Windows 2000 cache.dns file is also referred to as the root hints file. The caching only server uses this list to begin building its cache. It adds to the cache as it issues iterative queries when responding to client requests to resolve Fully Qualified Domain Names to IP addresses. After the FQDNs are resolved to IP addresses, this information is stored in the DNS Server cache. Caching only servers are valuable because:

They do not participate in zone transfer, and therefore there is no zone transfer traffic They can be placed on the far side of a slow WAN link and provide host name resolution for remote offices that do not require a high level of host name resolution support They can be implemented to provide secure host name resolution when configured as Forwarders

Remote offices are often connected to the main office via slow WAN links. These locations benefit from Caching-only servers because:

1. There is no zone transfer traffic. For large corporate intranets with small remote offices, eliminating zone transfer traffic can 2.
be very beneficial since zone transfer traffic could have a negative effect on their slow link. There is a reduction in the amount of DNS query traffic that traverses the WAN to the corporate DNS Servers.

Question: What does a domain controller register in DNS? Answer: The Netlogon service registers all the SRV records for that domain controller. These records are displayed as the _msdcs, _sites, _tcp, and _udp folders in the forward lookup zone that matches your domain name. Other computers look for these records to find Active Directory-related information. Question: If I remove the ISP's DNS server settings from the domain controller, how does it resolve names such as Microsoft.com on the Internet? Answer: As long as the "." zone does not exist under forward lookup zones in DNS, the DNS service uses the root hint servers. The root hint servers are well-known servers on the Internet that help all DNS servers resolve name queries. Question: What is the "." zone in my forward lookup zone? Answer: This setting designates the Windows 2000 or Windows Server 2003 DNS server to be a root hint server and is usually deleted. If you do not delete this setting, you may not be able to perform external name resolution to the root hint servers on the Internet. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 229840 DNS server's root hints and forwarder pages are unavailable Question: Do I need to configure forwarders in DNS? Answer: No. By default, Windows 2000 DNS uses the root hint servers on the Internet; however, you can configure forwarders to send DNS queries directly to your ISP's DNS server or other DNS servers. Most of the time, when you configure forwarders, DNS performance and efficiency increases, but this configuration can also introduce a point of failure if the forwarding DNS server is experiencing problems. The root hint server can provide a level of redundancy in exchange for slightly increased DNS traffic on your Internet connection. Windows Server 2003 DNS will query root hints servers if it cannot query the forwarders. Question: Should I point the other Windows 2000-based and Windows Server 2003-based computers on my LAN to my ISP's DNS servers? Answer: No. If a Windows 2000-based or Windows Server 2003-based server or workstation does not find the domain controller in DNS, you may experience issues joining the domain or logging on to the domain. A Windows 2000-based or Windows Server 2003-based computer's preferred DNS setting should point to the Windows 2000 or Windows Server 2003 domain controller running DNS. If you are using DHCP, make sure that you view scope option #15 for the correct DNS server settings for your LAN. Question: Do I need to point computers that are running Windows NT 4.0 or Microsoft Windows 95, Microsoft Windows 98, or Microsoft Windows 98 Second Edition to the Windows 2000 or Windows Server 2003 DNS server? Answer: Legacy operating systems continue to use NetBIOS for name resolution to find a domain controller; however it is recommended that you point all computers to the Windows 2000 or Windows Server 2003 DNS server for name resolution. Question: What if my Windows 2000 or Windows Server 2003 DNS server is behind a proxy server or firewall? Answer: If you are able to query the ISP's DNS servers from behind the proxy server or firewall, Windows 2000 and Windows Server 2003 DNS server is able to query the root hint servers. UDP and TCP Port 53 should be open on the proxy server or firewall. Question: What should I do if the domain controller points to itself for DNS, but the SRV records still do not appear in the zone? Answer: Check for a disjointed namespace, and then run Netdiag.exe /fix. You must install Support Tools from the Windows 2000 Server or Windows Server 2003 CD-ROM to run Netdiag.exe. For more information about how to check for a disjointed namespace, click the following article number to view the article in the Microsoft Knowledge Base:

257623 The DNS suffix of the computer name of a new domain controller may not match the name of the domain after you install upgrade a Windows NT 4.0 Primary domain controller to Windows 2000 Question: How do I set up DNS for a child domain? Answer: To set up DNS for a child domain, create a delegation record on the parent DNS server for the child DNS server. Create a secondary zone on the child DNS server that transfers the parent zone from the parent DNS server. Note Windows Server 2003 has additional types of zones, such as Stub Zones and forest-level integrated Active Directory zones, that may be a better fit for your environment. Set the child domain controller to point to itself first. As soon as an additional domain controller is available, set the child domain controller to point to this domain controller in the child domain as its secondary. SRV Records Missing After Implementing Active Directory and Domain Name System This behavior occurs when the following conditions exist:

The DNS server is configured as a Dynamic Host Configuration Protocol (DHCP) client. The DNS zone has a name other than your Active Directory domain name. The zone is not enabled to allow dynamic updates.

To resolve this issue, verify that all of the following conditions exist:

Configure your DNS server to use a static Internet Protocol (IP) address. Create a forward lookup zone named after your Active Directory. Enable your domain zone to allow dynamic updates.

NOTE: If all of these conditions exist and you still do not see your SRV records, stop and start the Netlogon service. This action forces the domain controller to re-register the appropriate SRV records. Using the netdiag /fix command on the domain controller will verify that all SRV records that are in the Netlogon.dns file are registered on the primary DNS server. 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 clients 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 primarytype 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. Caution

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/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. Aging/scavenging terminology The following table indicates new or revised terms that have been introduced to help specifically when discussing aging and scavenging. Term Resource record (RR) time stamp Current server time No-refresh interval Description A date and time value used by the DNS server to determine removal of the resource record when it performs aging and scavenging operations. The current date and time on the DNS server. This number can be expressed as an exact numeric value at any point in time. An interval of time, determined for each zone, as bounded by the following two events:

1. 2.

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 7 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. An interval of time, determined for each zone, as bounded by the following two distinct events: 1. Refresh interval 2. 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 7 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. Start scavenging A specific time, expressed as a number. This time is used by the server to determine when a zone becomes available time for scavenging. For more information, see Understanding aging and scavenging. When automatic scavenging is enabled at the server, this period represents the time between repetitions of the Scavenging automated scavenging process. The default value for this is 7 days. To prevent deterioration of DNS server period performance, the minimum allowed value for this is 1 hour. 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: 1. 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. 3. 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 refresh

2.

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: 1. Record update 2. 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.

3. 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 ZoneResetScavengeServers parameter for the zone. This can be done using the dnscmd command, a command-line based tool for administering Windows DNS servers. For more information, see Server administration using Dnscmd. When scavenging can start Once all prerequisites for enabling the use of scavenging are met, it 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 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 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/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. 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 "hosta.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.

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 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. 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 directoryintegrated "example.microsoft.com" zone.

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.

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. If the query cannot be resolved using this local data, then it will forward the query to the DNS server designated as a forwarder.

2.

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. Delegating zones Updated: January 21, 2005 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 Delegating zones DNS provides the option of dividing up the namespace into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. When deciding whether to divide your DNS namespace to make additional zones, consider the following reasons to use additional zones:

A need to delegate management of part of your DNS namespace to another location or department within your organization. A need to divide one large zone into smaller zones for distributing traffic loads among multiple servers, improve DNS name resolution performance, or create a more fault-tolerant DNS environment. A need to extend the namespace by adding numerous subdomains at once, such as to accommodate the opening of a new branch or site.

If, for any of these reasons, you could benefit from delegating zones, it might make sense to restructure your namespace by adding additional zones. When choosing how to structure zones, you should use a plan that reflects the structure of your organization. When delegating zones within your namespace, be aware that for each new zone you create, you will need delegation records in other zones that point to the authoritative DNS servers for the new zone. This is necessary both to transfer authority and to provide correct referral to other DNS servers and clients of the new servers being made authoritative for the new zone.

When a standard primary zone is first created, it is stored as a text file containing all resource record information on a single DNS server. This server acts as the primary master for the zone. Zone information can be replicated to other DNS servers to improve fault tolerance and server performance. When structuring your zones, there are several good reasons to use additional DNS servers for zone replication: 1. Added DNS servers provide zone redundancy, enabling DNS names in the zone to be resolved for clients if a primary server for the zone stops responding. Added DNS servers can be placed so as to reduce DNS network traffic. For example, adding a DNS server to the opposing side of a low-speed WAN link can be useful in managing and reducing network traffic. Additional secondary servers can be used to reduce loads on a primary server for a zone.

2.

3.

Example: Delegating a subdomain to a new zone As shown in the following figure, when a new zone for a subdomain (example.microsoft.com) is created, delegation from the parent zone (microsoft.com) is needed.

In this example, an authoritative DNS server computer for the newly delegated example.microsoft.com subdomain is named based on a derivative subdomain included in the new zone (ns1.na.example.microsoft.com). To make this server known to others outside of the new delegated zone, two RRs are needed in the microsoft.com zone to complete delegation to the new zone. These RRs include:

An NS RR to effect the delegation. This RR is used to advertise that the server named ns1.na.example.microsoft.com is an authoritative server for the delegated subdomain. An A RR (also known as a glue record) is needed to resolve the name of the server specified in the NS RR to its IP address. The process of resolving the host name in this RR to the delegated DNS server in the NS RR is sometimes referred to as glue chasing.

Note

When zone delegations are correctly configured, normal zone referral behavior can sometimes be circumvented if you are using forwarders in your DNS server configuration. For more information, see Directing queries through forwarders.