Dns Configuration

Editor's Notes

• #5: Overview The product development group responsible for name resolution has made some significant improvements in Windows .NET DNS over Windows 2000 DNS. Many of the changes were driven by feedback from customers and PSS; it was recognized that DNS was a new technology to many customers who were deploying Active Directory. In order to decrease PSS call volume and make DNS more transparent to the customer, product development has created a number of features that will make it easier for administrators to configure DNS when deploying Active Directory. In addition to incorporating new features into DNS, a handful of well-known problems that hinder functionality in Windows 2000 DNS have now been fixed in Windows .NET DNS. Disjoint Namespace Problem The disjointed namespace problem has been fixed so that when a customer upgrades a Windows NT 4.0 server to Windows .NET server and specifies an Active Directory name that is different than the previous NT 4.0 primary suffix, the current primary suffix of the fully qualified domain name (FQDN) will always match the Active Directory domain name. No longer will the primary suffix be different than the Active Directory domain name, regardless of the previously configured primary domain suffix. See Knowledge Base Article Q257623, “Domain Controller's DNS Suffix Does Not Match Domain Name” for more information regarding the Disjoint Namespace problem in Windows 2000. Root Zone Problem The root zone seen as a “.” zone in DNS forward lookup zones will never be added automatically in Windows .NET Server DNS. In Windows 2000, the root zone was added if the DNS server could not prime any of the Root Hint servers that are located on the internet when the DNS service was initialized for the first time. Having this zone present will prevent you from using the external Root Hint servers or configuring forwarders. An administrator can manually create a root “.” zone under Windows.NET Server DNS if needed. Island Server Problem In domains where multiple DC’s exist, each DC can locate the other DC’s by querying for the DC’s DsaGuid._msdcs.<forestname> CNAME record which is dynamically registered by netlogon. In some scenarios, it is possible that each DC may be configured to point only to itself for DNS resolution. Because the DsaGuid._msdcs.<forestname> CNAME record will only be registered locally, DC’s will only be able to resolve their own DsaGuid._msdcs.<forestname> CNAME record and not find any other DC’s in the domain (hence the name, ‘island server’). This problem has been fixed in Windows .NET server by enhancing the DNS Update API’s. When a special flag is set in the API call, a DC will now attempt to locate other DC’s that are running DNS and are authoritative for the <forestname> zone. It does this by querying for the NS records of <forestname> at the top of the authoritative zone. With each NS record that is returned, the DC will then query for the SOA record directly to the DNS server specified in the NS record. If the name in the SOA record matches the name in the NS record, a dynamic update for DsaGuid._msdcs.<forestname> is attempted with the server specified in the NS/SOA record. The end result is that a DNS Server will register it’s DsaGuid._msdcs.<forestname> record with each DNS server that is a member of the domain.
• #6: Overview Active Directory deployment requires the existence of the appropriate DNS infrastructure. However, setting up DNS can be a difficult task for an inexperienced customer. To help customers through the process, the Active Directory installation wizard (DcPromo) in Windows 2000 enabled customers to install and configure a local DNS server. Unfortunately, PSS calls and recent usability studies demonstrate that customers do not realize that even when they choose to install and configure a DNS server during DcPromo, they still need to manually configure the DNS client service (TCP/IP DNS settings) to use a local server for DNS services. A common misconception is to continue to use the ISP’s DNS servers as the preferred and alternate DNS servers. This will cause the DC to fail to register its DC locator DNS records and problems such as domain replication and domain joining will occur. In Windows .NET Server, the DcPromo wizard contains a number of enhancements, including a modification that automates the configuration of the DNS client settings on the DC. The result will be a DC configured to use itself as the primary DNS server when the option to install and configure DNS is selected during DcPromo. The DNS client configuration process employed by DcPromo is described in the next section.
• #7: DNS Auto Configuration Process DcPromo will configure DNS under the following circumstances: If a server has a single network connection. If the set of preferred and alternate DNS servers on all network connections are the same. If the preferred DNS servers are specified only on one connection. In this case: Update the Root Hints by querying a DNS server currently specified as the preferred (and, if necessary, alternate) DNS server(s) of a DC. Configure the local DNS server to forward to the DNS server currently specified as the preferred and alternate DNS servers of a DC. Configure each network connection of the DC with the following ordered list of DNS server IP addresses: 127.0.0.1, and then all preferred and alternate DNS servers on that network connection that were previously listed. In the case of multiple adapters and none of the above clauses are true: Query the preferred and alternate DNS servers on all network connections to update the Root Hints. Set the Root Hints to the largest set of the Root Hints returned from among all the connections (in case of a tie, choose the set returned from the preferred adapter). Configure the local DNS server to forward to the DNS servers currently specified as the preferred and alternate DNS servers of a DC on all the network connections. Configure each network connection of the DC with the following ordered list of DNS server IP addresses: 127.0.0.1, and then all preferred and alternate DNS servers on that network connection that were previously listed.
• #8: If during the attempt to update the Root Hints none are returned on any adapter, DcPromo will not modify the client and will log the following warning: The DNS server could not configure network connections of this computer with the DNS server running on the computer as their preferred DNS server, because this computer is connected to the networks with different DNS namespaces. Manual configuration of the local DNS server to perform name resolution on one or more of the namespaces is required before one may modify the preferred DNS servers (part of the TCP/IP configuration) of the network connections. If the network connections of this computer are not configured with the DNS server running on the computer as their preferred DNS server, this computer may not be able to dynamically register DC locator DNS records in DNS. Absence of these records in DNS may prevent other Active Directory domain members and domain controllers from locating this domain controller. User Action: Ensure that DC locator DNS records enumerated in the %WinRoot%./System32/config/netlogon.dns file are registered on the local DNS server. If these records are not registered in DNS: Add to a parent DNS zone a delegation to this server for the zone matching the name of the Active Directory domain OR Configure local DNS server with appropriate root hints and forwarders (if necessary), and configure network connections of this computer with the DNS server running on the computer as their preferred DNS server. Notice though that other computers using other DNS servers as their preferred or alternate DNS servers may not be able to locate this domain controller, unless the DNS infrastructure is properly configured. Note This warning states that the customer needs to set the preferred DNS server to be the same IP address that is assigned to the network adapter. Furthermore, the customer needs to check DNS and make sure a zone exists that matches the <domainname> and that the contents of netlogon.dns exist in that zone. If the auto configuration was successful, the DNS server will log this Informational event: The DNS server successfully autoconfigured: %1 Where %1 is a string containing one more of these items: DNS server root hints DNS server forwarders DNS resolver
• #9: Overview A partition is a data structure within Active Directory used to distinguish data for different replication purposes. Every domain controller contains the following three directory partitions: configuration, schema, and domain. A directory partition is also called the “ naming context ”. Domain controllers in the same forest but in different domains share the same configuration and schema data, but they do not share the same domain data. In Windows 2000, if the DNS server is configured to use Active Directory Integrated zones, then the DNS zone data is stored in the domain naming context (DNC) partition of Active Directory. Conversely, in Windows .NET server, application directory partitions enable storage and replication of the DNS zones stored in the non-domain naming context (NDNC) partition of Active Directory. Every object created in the domain naming context, which includes DNS zones and nodes (DNS names, e.g., microsoft.com), are replicated to all the GC’s in the domain. By using application directory partitions to store the DNS data, essentially all DNS objects are removed from the GC. This is a significant reduction in the number of objects that are normally stored in the GC.. Furthermore, when the DNS zone data is stored under the domain naming context of Active Directory (such as in Windows 2000), it is replicated to all DC’s in the domain irrespective of whether a DNS server is configured to run on the DC or not. This is an instance where full domain-wide replication is an over-kill. It would be preferable to redefine the scope of replication of the DNS zone data to only the subset of DC’s in the domain that actually run DNS. This can be done with domain-wide application directory partitions. Additionally, an application directory partition that is replicated to all DNS servers in the forest can be used for zones like _msdcs.<forestname> which should be visible to the entire forest. This is ideal because all DC’s register their DsaGuid CNAME resource record in the _msdcs.<forestname> zone.
• #10: Zone Replication Options There are four replication options for Active Directory-integrated DNS zones. These can be selected when the zone is created or when the administrator wants to change the storage method for an existing zone. When deciding which replication option to choose, consider that the broader the replication scope, the greater the network traffic caused by replication. For example, if the administrator chooses to have Active Directory-integrated DNS zone data replicated to all DNS servers in the forest, this will produce greater network traffic than replicating the DNS zone data to all DNS servers in a single Active Directory domain in that forest. The following table describes zone replication options. Replication OptionDescription All DNS servers in the Active Directory forestThe zone data is replicated to all the DNS servers running on domain controllers in all domains of the Active Directory forest. All DNS servers in a specified Active Directory domainThe zone data is replicated to all DNS servers running on domain controllers in the specified Active Directory domain. This option is the default setting for Active Directory-integrated DNS zone replication.All domain controllers in the Active Directory domainThe zone data is replicated to all domain controllers in the specified Active Directory domain regardless of whether there are DNS servers running on the domain controllers in the domain. If the administrator wants to have Windows 2000 Server DNS servers load an Active Directory-integrated DNS zone, this replication scope setting must be selected for that DNS zone.All domain controllers specified in the replication scope of an application directory partitionThe zone data is replicated to all the domain controllers specified in the replication scope of the application directory partition. Forest-Wide Replication Given any scenario one might be able to argue that replicating DNS zone data to every DNS server in the forest might cause excessive traffic. However, the trade off is extreme ease of administration and deployment. Especially in smaller organizations where an IT department may not exist, configuring DNS for Active Directory can be difficult for most. In these situations, the best solution should be the easiest solution. Therefore, using forest-wide replication for any DNS zone is considered the best option. If every zone is replicated to all DNS servers in the forest, then a customer should not need to use stub zones, secondary zones, or forwarders when configuring internal DNS resolution when using Active Directory. Default DNS Application Directory Partitions Before an administrator can use any of the forest or domain wide application partition replication options, the DNS application directory partitions must be created within Active Directory. By default, when the DNS Server service is started, it will attempt to locate and create (if necessary) the default DNS application directory partitions (ForestDnsZones .DnsForestName and DomainDnsZones. DnsDomainName) in Active Directory. However, if the DNS Server service is unable to do this, an Enterprise Administrator can manually create the DNS application directory partitions as discussed below. Note Enterprise Admin credentials are required to create an application directory partition. While it would be ideal to make a DNS server use the credentials of the administrator to create the DNS application partitions during the installation and configuration of DNS in DcPromo, it is impossible since Active Directory is not yet available until the computer is rebooted. To workaround this problem the following solution has been implemented (this is also true if the DNS service is installed on a computer that is already a DC): When on startup a DNS server detects that the forest- and/or domain-wide application partitions do not exist, the DNS server attempts to create the DNS application partitions. If it fails (which is usually the case since DNS does not have the appropriate credentials) when the first user logs in, a separate executable (waiting for the user to log in) will notify the DNS server that the user is logged in and will provide the DNS server with the credentials of the logged in user. Next, the DNS server will check again whether the forest- and/or domain-wide application partitions exist. If at least one of them does not exist, then DNS will attempt to create the missing application directory partitions corresponding to the domain and forest of the DNS server using the user’s credentials. Note In the event that an administrator does not want DNS to create the default application directory partitions automatically, they will need to disable the following registry key. Name: EnableDirectoryPartitions Key: HKLMSystemCurrentControlSetServicesDNSParameters Type: REG_DWORD Value: 0x0 Valid Range: 0x0 (disable) and 0x1 (enable) Creating DNS Application Directory Partitions To create the DNS application partitions, an administrator can either right-click on the DNS server listed in the DNS manager and choose the option “Create Default Application Directory Partitions” or use the Dnscmd.exe support tool: dnscmd ServerName /CreateBuiltinDirectoryPartitions  {/Domain|/Forest|/AllDomains} ValueDescription dnscmdSpecifies the name of the command-line tool.ServerNameRequired. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)./CreateBuiltinDirectoryPartitionsRequired. Creates a default application directory partition.{/Domain|/Forest|/AllDomains}Required. Specifies which default application directory partition to create. Do one of the following: To create a default domain-wide DNS application directory partition for the Active Directory domain where the specified DNS server is located, type /Domain. To create a default forest-wide DNS application directory partition for the Active Directory forest where the specified DNS server is located, type /Forest. To create a default domain-wide DNS application directory partitions on a DNS server in each domain in the Active Directory forest where the user running this command is logged on, type /AllDomains.The ServerName parameter is ignored for /AllDomains. The computer on which this command is run must be joined to a domain in the forest where you want to create all of the default domain-wide application directory partitions. Creating Specific Application Directory Partitions While DNS does have the option to store zone data in an application directory partition other than ForestDnsZones .DnsForestName and DomainDnsZones. DnsDomainName , it is beyond the scope of this document to explain how they are completely deployed in an Active Directory environment. The following section describes how to create, remove and view application directory partitions and how to add or remove specific servers to the replica scope in the event that one might need to replicate DNS zone data via a non-DNS specific application directory partition. A DC that is configured to replicate a directory partition is said to be part of the “replica scope”. To create or delete an application directory partition: Open a command prompt Type: ntdsutil At the ntdsutil command prompt, type: domain management At the domain management command prompt, type: connection At the connection command prompt, type: connect to server ServerName At the connection command prompt, type: quit At the domain management command prompt, do one of the following: To create an application directory partition, type: create nc  ApplicationDirectoryPartition DomainController To delete an application directory partition, type: delete nc  ApplicationDirectoryPartition ValuesDescription ServerNameThe DNS name of the domain controller on which to create or delete the application directory partition.ApplicationDirectoryPartitionThe distinguished name of the application directory partition that you want to create or delete. For example, the distinguished name of the application directory partition test.microsoft.com is dc=test, dc=Microsoft, dc=com.DomainControllerThe DNS name of the domain controller on which to create or delete the application directory partition. Type NULL to create the application directory partition on the domain controller to which you are currently connected.The value for the DomainController parameter of the create nc command must either be the DNS name of a domain controller or (if you are creating the application directory partition on the domain controller to which you are currently connected) use the NULL variable. To add or remove an application directory partition replica: Open a command prompt Type: ntdsutil At the ntdsutil command prompt, type: domain management At the domain management command prompt, type: connection At the connection command prompt, type: connect to server  DomainController At the connection command prompt, type: quit At the domain management command prompt, do one of the following: To add an application directory partition replica, type: add nc replica  ApplicationDirectoryPartition DomainController To remove an application directory partition replica, type: remove nc  replica ApplicationDirectoryPartition ValueDescription DomainControllerThe DNS name of the domain controller on which to add or remove the replica of the application directory partition.ApplicationDirectoryPartitionThe distinguished name for the application directory partition of which you want to add or remove a replica. For example, the distinguished name of the application directory partition test.microsoft.com is dc=test, dc=microsoft, dc=com. The value NULL can be used for the DomainController parameter of the add nc replica and remove nc replica commands if you are adding or removing the application directory partition replica on the domain controller to which you are currently connected. Note Using the commands above, an administrator could remove the default DNS application partitions from a specific DNS server. To display application directory partition information: Open a command prompt Type: ntdsutil At the ntdsutil command prompt, type: domain management At the domain management command prompt, type: connection At the connection command prompt, type: connect to server  DomainController At the connection command prompt, type: quit At the domain management command prompt, type: list ValueDescription DomainControllerThe DNS name of the domain controller for which you want to display application directory partition information. Zone Loading and Polling When the DNS service starts, if it is configured to load from the AD (default configuration), then it loads all DNS zones stored in the application directory partitions that are locally available. After the DNS server has started and loaded the zone from the application directory partitions, the server continues to periodically pull updates from the AD once every 5 minutes. The DNS server also searches for the new zones in the application directory partitions every time it pulls the updates from the AD. Root Hint Storage By default, the Root Hints must be stored in the domain directory partition if the domain version is Windows 2000 and in the DomainDnsZones. DnsDomainName application directory partition if the OS is Windows .NET or later. When a DNS server is configured to load zone data from the AD, it will try to load the Root Hints from the DomainDnsZones. DnsDomainName application directory partition. However, if that partition is not available, then DNS will load the Root Hints from the domain directory partition.
• #12: Overview A stub zone is a read-only copy of a zone that contains only those resource records necessary to identify the authoritative DNS servers for the actual zone. A stub zone is used to keep a parent zone aware of the authoritative DNS servers for a delegated zone and thereby maintain DNS name resolution efficiency. For example, a customer who is running Windows 2000 (that has both a parent and child domain) will typically create a delegation record in the parent zone for the child domain, thus enabling the child DNS server to host the primary zone for the child domain. As new DNS servers are added to the child domain, the delegation record must be updated manually on the parent DNS server to reflect those new child DNS servers. Alternatively, with stub zones, the parent DNS server can host a stub zone for the child domain and become aware of new child DNS servers automatically when the stub zone is loaded or reloaded. Stub zones are not limited to use in a parent-child domain topology; they also can be used to resolve resource records in other domains in the forest and, theoretically, for other forests as well. Figure 1 shows a stub zone viewed from DNS manager. Note The administrator cannot modify a stub zone's resource records. Any changes the administrator wants to make to the resource records in a stub zone must be made in the original, primary zone from which the stub zone is derived. Unlike secondary zones, stub zones can be stored in Active Directory. Figure 1: A stub zone viewed from DNS manager A stub zone is composed 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. Note The primary restriction for a stub zone is that it may not be hosted on a DNS server that is authoritative for the same zone. For example, the stub zone for child . widgets.microsoft.com cannot be hosted on a DNS server that already contains a primary zone for child . widgets.microsoft.com . If the zone widgets . microsoft.com contained a delegation to child.widgets.microsoft.com , then the DNS server hosting widgets.microsoft.com could then host a stub zone for child . widgets.microsoft.com . 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 stub zone's resource records to resolve the query. The DNS server sends an iterative query to the authoritative 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 server in its stub zone, the DNS server hosting the stub zone attempts standard recursion using the root hint servers. If the DNS client query was an iterative query, the DNS server returns a referral of the name servers specified in the stub zone to the DNS client. The DNS server will store the resource records it receives from a stub zone's authoritative servers in its cache. However, 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. This record is created during the creation of the stub zone and updated during transfers to the stub zone from the original, primary 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 SOA resource record's Refresh interval determines when the DNS server hosting the stub zone will attempt a zone transfer (update). Should an update fail, the SOA resource record's Retry interval determines when the update is retried. Once the Retry interval has expired without a successful update, the expiration time as specified in the SOA resource record's Expires field determines when the DNS server stops using the stub zone data. Stub zone update choices: ReloadReload the stub zone from the local storage of the DNS server hosting the stub zone.Transfer from masterHave the DNS server that is hosting the stub zone determine if the serial number in the stub zone’s SOA resource record has expired and then perform a zone transfer from the stub zone's master server.Reload from masterPerform a zone transfer from the stub zone's master server regardless of the serial number in the stub zone's SOA resource record
• #13: Note: Only contains the SOA, NS and A records
• #14: Using the Local List of Masters Master servers are DNS servers that the stub zone will contact to retrieve the necessary resource records. It is comparable to the list of servers defined when creating a secondary zone (i.e.. the list of servers from which the zone is transferred). When more than one server appears in the list and a zone update is requested, the list of master servers is used and the servers are prioritized by the order in which they appear in the list. When Active Directory-integrated stub zones are replicated into different physical sites, it is recommended that they be updated using a local list of master servers in each site. For example, an Active Directory-integrated stub zone, widgets.microsoft.com , was loaded in a site in Seattle and replicated to a site in Boston. Master servers for the stub zone exist in each of these sites. When the stub zone in Boston is updated, the domain controller may contact both master servers for resource records in widgets.microsoft.com . However, because of network traffic, the administrator may want the domain controller in Boston to use only the master server in Boston and not the master server in Seattle. To force the domain controller in Boston to use only the master server in Boston, the administrator can specify that the stub zone in Boston be updated using a local list of master servers. See Figure 2. Figure 2. Master server list in the stub zone properties dialog box Note To use a local list of masters, enable the checkbox “Use the list above as a local list of master” on the General tab of the stub zone properties. This option will only be available if the zone is stored in Active Directory. Stub zones that are not stored in active directory will only use the list of masters that are specified in the stub zone properties. New Registry Keys Name: LocalMasterServers Key: HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDNS Serverones<zonename> Type: REG_SZ Valid Range: space-separated, IP list of masters to be used by this DNS server Note When the DNS server loads a stub zone it checks the value of LocalMasterServers for that zone. If it is empty or doesn’t exist, then the server uses (and stores in memory) the Master servers specified in the AD. Otherwise, the server uses the Master servers specified in LocalMasterServers. Name: MasterServers Key: HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDNS Serverones<zonename> Type: REG_SZ Valid Range: The list of Master servers used by all DNS servers Automatic Update of the Master Servers In theory, as the stub zone is updated and new NS resource records are added and removed, the master server list could also be updated. It simplifies the administration task (i.e., if the IP address of a master server changes, the administrator doesn’t have to change it on all stub DNS servers). At the same time, the administrator looses the control of which DNS servers the server (containing the stub zone) should send the queries to. A more serious problem is that the DNS queries are non-secure, meaning that an attacker could spoof the queries returned to the stub zone when the data is updated. If the list of the IP addresses of the master servers is modified, then the server could eventually not be able to update the zone correctly. Because of the inherent security risks involved, automatic updates of the master servers is not a feature that will be included with Windows .NET DNS, even though customers have requested it. This feature maybe implemented once a secure DNS query mechanism is in place.
• #15: Note To use a local list of masters, enable the checkbox “Use the list above as a local list of master” on the General tab of the stub zone properties. This option will only be available if the zone is stored in Active Directory. Stub zones that are not stored in active directory will only use the list of masters that are specified in the stub zone properties.
• #16: Overview Conditional forwarding allows a DNS server to forward queries to other DNS servers based on the DNS domain names in the queries. With conditional forwarding, a DNS server could be configured to forward all the queries it receives for names ending with widgets.microsoft.com to a specific DNS server's IP address, or to the IP addresses of multiple DNS servers. For example, when two companies (example1.com and example2.com) merge or collaborate, they may want to allow clients from the internal namespace of one company to resolve the names of the clients from the internal namespace of another company. The administrators from one organization (e.g., example1.com) may inform the administrators of the other organization (e.g., example2.com) about the set of DNS servers that they can use to send DNS queries to for the name resolution within the internal namespace of the first organization. In this case the DNS servers within the example2.com organization will be configured to forward all queries for names ending with “example1.com.” to the designated DNS servers. Note Authoritative DNS servers cannot forward queries according to domain names for which they are authoritative. For example, the authoritative DNS server for the zone widgets.microsoft.com cannot forward queries according to the domain name widgets.microsoft.com . If the DNS server were allowed to do this, it would nullify the server's ability to respond to queries for the domain name widgets.microsoft.com . The DNS server authoritative for widgets.microsoft.com can forward queries for DNS names that end with hr.widgets.microsoft.com , if hr.widgets.microsoft.com is delegated to another DNS server. See Figure 3. Figure 3: Forwarders tab in DNS server properties The conditional forwarder setting consists of the following: The domain names for which the DNS server will forward queries One or more DNS server IP addresses for each domain name specified Forwarding Sequence Each domain name used for forwarding on a DNS server is associated with the IP addresses of one or more DNS servers. A DNS server configured for forwarding will use its forwarders list after it has determined that it cannot resolve a query using its authoritative data (primary or secondary zone data) or cached data. If the server cannot resolve a query using forwarders, it may attempt recursion to the root hint servers. The order of the IP addresses listed determines the sequence in which the IP addresses are used. After the DNS server forwards the query to the forwarder with the first IP address associated with the domain name, 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 associated with the domain name. It continues this process until it receives an affirmative answer from a forwarder. Note Unlike conventional client 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. Domain Name Length When a DNS server configured to use conditional forwarding receives a query for a domain name, it will compare that domain name with its list of domain name conditions and use the longest domain name condition that corresponds to the domain name in the query. For example (using Figure 3), the DNS server receives a query for www.testcenter.research.example.com . It compares that domain name with both example.com and research.example.com . The DNS server determines that research.example.com is the domain name that more closely matches the domain name query. The DNS server forwards the query to the DNS server with the IP address 192.168.200.1, which is associated with research.example.com . Forward-only Server A DNS server can be configured to not perform recursion after the forwarders fail; if it does not get a successful query response from any of the servers configured as forwarders, then it sends a negative response to the DNS client. The option to prevent recursion can be set for each conditional forwarder in Windows .NET Server. For example, a DNS server can be configured to perform recursion for the domain name research.example.com , but not to perform recursion for the domain name example.com . Warning If you disable recursion on the Advance tab in DNS server properties, you will not be able to use forwarders on the same server. New Registry Keys This key toggles recursion for a particular domain: Key: HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDNS Serverones<zone name> Name: ForwarderSlave Type: REG_DWORD Valid Range: 0x0 (recursion) and 0x1 (no recursion) This key sets the forwarder timeout for a particular domain: Key: HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDNS Serverones<zone name> Name: ForwarderTimeout Type: REG_DWORD Valid Range: any number (seconds) This key lists the order of forwarders a domain will use: Key: HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDNS Serverones<zone name> Name: MasterServers Type: REG_SZ Valid Range: spaced list of IP addresses used in order
• #18: Overview Configuration of Windows 2000 DNS clients in a large organization is a notorious problem since there is no tool that enables centralized configuration of such clients. For example, configuring a DNS suffix search list or preventing a client from dynamically updating its resource records must be done on a per-computer basis; this is obviously an inconvenience to any network administrator. Windows .NET server resolves this problem by including a group policy to configure DNS clients with parameters such as: Configuring a list of DNS servers for the client to use. Enabling/disabling dynamic registration of the DNS records by a client. Devolution of the primary DNS suffix in a name resolution process. Configuring DNS suffix search list of the clients. What Group Policy Supercedes Group policy always supersedes any local configuration as well as DHCP configuration. This means that when a group policy is used to specify a DNS client parameter, any service that uses the value of such a parameter will use the value specified by the group policy instead of locally or DHCP configured values. The only exception to this rule addresses the common scenario when an administrator wants to disable dynamic DNS registration for all the clients except, for example, DC's. In this case, an administrator can specify the following registry key: Name: DoNotUseGroupPolicyForDisableDynamicUpdate Key: HKLMSYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid Range: 0x0 (use group policy) and 0x1 (use local) Default: 0x0
• #20: Policy Descriptions The following paragraphs describes what each setting does, the registry key which is modified on the client, and the valid values for the policy and registry key. Primary DNS Suffix This setting lets you specify a primary DNS suffix for a group of computers and prevents users, including administrators, from changing it. Note To make changes to this setting effective, you must restart Windows 2000 on all computers affected by the setting. Dynamic Update This policy setting determines if dynamic update is enabled. Computers configured for dynamic update automatically register and update their DNS resource records with a DNS server. Name: RegistrationEnabled Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0x0 (disable) and 0x1 (enable) DNS Suffix Search List Group policy support for the DNS suffix search list is considered a strategic feature, which will be required in a transition to the NetBIOS-less environment. With this setting enabled, when a user submits a query for a single-label name (such as ‘widgets’) a local DNS client attaches a suffix (such as ‘microsoft.com’) resulting in the query ‘widgets.microsoft.com’, prior to sending the query to a DNS server. Name: SearchList Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_SZ Valid Range: comma separated strings of DNS suffixes Primary DNS Suffix Devolution This policy setting determines whether the DNS client performs primary DNS suffix devolution in a name resolution process. When a user submits a query for a single-label name (such as ‘test’) a local DNS client attaches a suffix (such as ‘microsoft.com’) resulting in the query test.microsoft.com’, prior to sending the query to a DNS server. The primary DNS suffix is devolved until the query is successful or the DNS suffix has two labels (e.g., ‘microsoft.com’). The primary DNS suffix cannot be devolved to less than two labels. For example, queries would be submitted in the following order: test.lab.research.microsoft.com, test.research.microsoft.com, test.microsoft.com Name: UseDomainNameDevolution Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0x0 (disable) and 0x1 (enable) Register PTR Records This policy setting determines whether the registration of PTR resource records is enabled for the computers to which this policy is applied. By default, DNS clients configured to perform dynamic DNS registration attempt PTR resource record registration only if they successfully registered the corresponding A resource record. To enable this policy, select Enable and choose one of the following values: OptionDescription Do not registercomputers never attempt PTR resource records registration.Registercomputers attempt PTR resource records registration regardless of the success of the A records registration.Register only if A record registration succeedscomputers attempt PTR resource records registration only if they successfully registered the corresponding A resource records. Name: RegisterReverseLookup Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0x0 (disabled), 0x1 (enabled) Registration Refresh Interval This policy setting specifies the Registration Refresh Interval of A and PTR resource records for computers to which this setting is applied. This setting may be applied to computers using dynamic update only. If the DNS resource records are registered in zones with scavenging enabled, the value of this setting should never be longer than the Refresh Interval configured for these zones. Setting the Registration Refresh Interval to longer than the Refresh Interval of the DNS zones may result in the undesired deletion of A and PTR resource records. Name: RegistrationRefreshInterval Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: larger than or equal to 1800 (seconds) Replace Addresses in Conflicts This policy setting determines whether a DNS client that attempts to register its A resource record should overwrite an existing A resource record(s) containing conflicting IP address(es). During dynamic update of a zone that does not use Secure Dynamic Update, a DNS client may discover that an existing A resource record associates the client’s host DNS name with an IP address of a different computer. According to the default configuration, the DNS client will attempt to replace the existing A resource record with an A resource record associating the DNS name with the client’s IP address. Name: RegistrationOverwritesInConflict Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0x0 (disable) and 0x1 (enable) Register DNS Records with Connection-Specific DNS Suffix This policy setting determines if a computer performing dynamic registration may register it’s A and PTR resource records with a [a1]concatenation of it’s Computer Name and a connection-specific DNS suffix, in addition to registering these records with a concatenation of its Computer Name and the Primary DNS suffix. Note If dynamic DNS registration is disabled on a computer (or is disabled on a specific network connection to which this setting is applied), a computer will not attempt dynamic DNS registration of it’s A and PTR records regardless of this policy setting. Name: RegisterAdapterName Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0x0 (disable), 0x1 (enable) TTL Set in the A and PTR Records This policy setting specifies the value for the Time-To-Live (TTL) field in A and PTR resource records registered in the computers to which this setting is applied. Name: RegistrationTTL Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0-4294967200 (seconds) Default: 600 Update Security Level This policy setting specifies whether the computers to which this setting is applied use secure dynamic update or standard dynamic update for registration of DNS records. To enable this setting, select Enable and choose one of the following values: OptionDescription Unsecure followed by secureIf this option is chosen then computers send secure dynamic updates only when non-secure dynamic updates are refused.Only UnsecureIf this option is chosen then computers send only non-secure dynamic updatesOnly SecureIf this option is chosen then computers send only secure dynamic updates Name: UpdateSecurityLevel Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Valid Range: 0 (UnsecureFollowedBySecure), 16 (OnlyUnsecure), 256 (OnlySecure) Update Top Level Domain Zones This policy setting specifies whether the computers to which this policy is applied may send dynamic updates to the zones named with a single label name (also known as Top Level Domain zones, e.g., “com”). By default, a DNS client configured to perform dynamic DNS update will send dynamic updates to the DNS zone(s) authoritative for its DNS resource records, unless the authoritative zone(s) is a top level domain and a root zone. If this policy is enabled, then computers to which this policy is applied will send dynamic updates to any zone authoritative for the resource records that the computer needs to update, except the root zone. Name: UpdateTopLevelDomainZones Key: HKLMSoftwarePolicesMicrosoftWindows NTDNSClient Type: REG_DWORD Value: 0x0 (Disable) and 0x1 (Enable)
• #22: Overview The Windows .NET Server DNS server provides basic support of DNS Security Extensions (DNSSEC) protocol as defined in RFC 2535. This allows Windows .NET Server DNS servers to perform as secondary DNS servers for existing DNSSEC–compliant secure zones. The DNS protocol is open, simple, and vulnerable to attack. The DNSSEC extensions, described in RFC 2535, provide a cryptographically secure DNS environment in which an administrator can digitally sign the contents of a zone with a private key. The signature and the associated public keys are added to the zone. DNSSEC uses the KEY record to hold the public key and the SIG record to hold the digital signature. DNSSEC–aware clients can use these resource records to verify the authenticity of answers returned from a DNS server. DNSSEC also provides a secure method (through the use of the NXT record) for a DNS server to inform a client that a domain does not exist. Storage of DNSSEC Resource Records Windows .NET Server supports the storage of the following three DNSSEC resource record types: TypeNameDescription KEYPublic key resource recordContains a public key that is associated with a zone or domain.SIGSignature resource recordThe SIG record is used to hold a signature associated with a resource records set and validity intervalNXTNext resource recordThe NXT record enables the DNS server to inform a client that a particular domain does not exist in the zone As noted earlier, the Windows .NET Server DNS server does not sign zones or records. However, it securely responds to the queries directed to the zones that have been signed on other DNS servers (e.g., if the Windows .NET DNS server is a secondary server for a signed zone). Additionally, an organization could develop a signing agent running on the Windows .NET Server DNS server that signs the zone records. In DNSSEC, each zone has its own public and private key used to encrypt and decrypt digital signatures included in the SIG records. The private key is used to create the SIG records. DNSSEC–aware clients can then retrieve and use the KEY record to validate the signatures. DNS administrators can use the zone’s private key to sign each resource record set (known as an RRset) in the zone. This provides each resource record set in the zone with a digital signature, contained in the SIG resource record. Server Processing of DNSSEC records The Windows .NET Server processes DNSSEC records by performing the following steps. When loading a zone containing DNSSEC resource records, the Windows .NET Server DNS server loads DSNSEC records along with all other types of resource records contained in the zone. This occurs regardless of the zone storage type. When receiving a zone transfer containing DNSSEC resource records (e.g., SIG, KEY, NXT), the Windows .NET Server DNS server writes these records to the zone file, along with all other resource records. When receiving a response containing DNSSEC resource records, it does not verify the digital signatures, but caches the response and uses it for ensuing queries. When responding to a query for a RRset in an authoritative zone, the DNS server returns the DNSSEC resource records associated with the RRset. The DNS server does not suppress the retrieval of the CNAME resource record and does not return a SIG resource record for the canonical name; rather, it returns the SIG resource record for the alias name. Configuring DNSSEC If a DNS server performing recursive resolution receives a response containing a DNSSEC record, it includes or removes those records from the response based on this registry value. Name: EnableDNSSEC Key: HKLMSYSTEMCurrentControlSetServicesDNSParameters Type: REG_DWORD Valid Range: 0x0, 0x1, 0x2 Default: 0x1 or blank ValueDescription 0x0no DNSSEC records are included in the response, unless the query was requesting an RRset of the DNSSEC record type0x1DNSSEC records are included in response only if the original client query contained the OPT RR, as described in RFC 2671. If a query was requesting an RRset of the DNSSEC record type, the DNS server will respond with such records (if available) regardless of whether the original query contained the OPT RR.0x2DNSSEC records are included in the response according to the RFC 2535. Client Processing of DNSSEC Records The Windows .NET Server DNS Client does not use or process any of the DNSSEC resource records when it receives a returned query. It neither reads or stores KEY records, nor authenticates or verifies the digital signatures returned in SIG records. Thus, if the DNS client receives a SIG record, it does not perform a query to get the associated KEY record. If a Windows .NET Server DNS client receives a query response that contains DNSSEC resource records, it returns those responses to the calling program as for all resource records. The DNS Client also caches them in the DNS client cache.
• #24: OPT Resource Record As described in RFC 2671, EDNS0 uses an OPT pseudo-RR that is added to the additional data section of either a DNS request or a DNS response to indicate the sender’s ability to handle the extended DNS protocols. The OPT is called a pseudo-RR because it pertains to a particular transport level message and not to any actual DNS data. OPT RR’s are never cached, forwarded, or stored in (or loaded from) zone files. [a1]S clients that do not know how to interpret the OPT RR ignore the RR. The immediate benefit of EDNS0 is that the DNS client and server can advertise their maximum UDP payload size, which can be larger than 512 bytes. In Windows 2000 or Windows NT 4.0, when the DNS server responds to a query, it assumes that the maximum client’s UDP payload size is 512 octets. This means that when a packet to be sent by a server to a client is longer than 512 octets, the DNS server: sends only those records that fit within a 512 octets UDP packet and sets the truncation bit to indicate to a client that the entire response didn’t fit into a single 512 octets UDP packet. In order to receive a complete response, the DNS client repeats the previous query, but sends it using TCP instead of UDP. This causes a DNS server to respond using TCP transport. This increases network load and slows average name resolution process. With EDNS0, a computer sending out a DNS query can include the OPT RR, effectively proving the computer’s ability to support EDNS0. If the response indicates that the server does support EDNS0, this fact is cached in a special EDNS0 cache. You can set the maximum cache lifetime using Dnscmd as described below.
• #25: Overview The DNS protocol, defined in RFC 1035 and subsequently updated by a number of RFC’s, specifies a message format that is used by DNS clients and servers to communicate. Within these DNS messages there are standard formats for encoding options, reporting errors, and for name compression. However, many of these formats are now too small or are in need of updating. For example, one restriction is that the maximum allowable size of a DNS message, when sent over UDP, is fixed at 512 bytes. Although TCP can be used for larger DNS messages, this is inefficient. A solution to these limits is to extend DNS. RFC 2671 sets out a basic approach to the extensions, known as Extended DNS (EDNS). RFC 2671 also defines a base extension, referred to as EDNS0. Windows .NET Server DNS server supports this extension to the DNS protocol to be compatible with other implementations of the DNS servers and clients. Note Windows .NET DNS clients will not support ENDS0 until the second release of Windows .NET. The immediate benefit of EDNS0 is that the DNS client and server can advertise their maximum UDP payload size, which can be larger than 512 bytes. In Windows 2000 or Windows NT 4.0, when the DNS server responds to a query, it assumes that the maximum client’s UDP payload size is 512 octets. This means that when a packet to be sent by a server to a client is longer than 512 octets, the DNS server: sends only those records that fit within a 512 octets UDP packet and sets the truncation bit to indicate to a client that the entire response didn’t fit into a single 512 octets UDP packet. In order to receive a complete response, the DNS client repeats the previous query, but sends it using TCP instead of UDP. This causes a DNS server to respond using TCP transport. This increases network load and slows average name resolution process. With EDNS0, a computer sending out a DNS query can include the OPT RR, effectively proving the computer’s ability to support EDNS0. If the response indicates that the server does support EDNS0, this fact is cached in a special EDNS0 cache. You can set the maximum cache lifetime using Dnscmd as described below. Server Support for EDNS0 When a Windows .NET Server DNS server receives a query containing OPT RR, it does not truncate a UDP response unless the response’s size is larger than the limit specified in the OPT RR. If the response’s size is larger than the limit specified in the OPT RR, then the server: sends the UDP response containing as many RRsets that fit in the maximum size of the UDP packet specified by the requester in the OTP RR and sets the truncation bit. When a Windows .NET Server DNS server receives a query that does not contain an OPT RR, it assumes the requester does not support the EDNS0 and responds to the requester assuming that it does not accept UDP packets longer than 512 octets. If a Windows .NET Server DNS server sends a query to another DNS server, it attaches the OPT RR in the Additional Data field of the DNS message, as specified in the RFC 2671. The Maximum UDP Packet Size may be specified in the following registry key: Name: MaximumUdpPacketSize Key: HKLM/SYSTEM/CurrentControlSet/Services/Dns/Parameters Type: REG_DWORD Valid Range: 512-16384 Default: 4000 Exists by default: no Note If the value is set through the registry editor, the DNS server must be restarted in order for the new value to take effect. If a DNS server that does not support EDNS0 receives a DNS query with an OPT RR, it indicates that it does not support EDNS0 by sending one of the following error responses to the client. NameValueDescription FORMERR1Format Error. The name server did not interpret the OPT resource record.SERVFAIL2Server Failure. The name server did not process the query because of a problem with the name server.NOTIMPL4Not Implemented. The name server does not support the kind of query requested. If the DNS server does not support EDNS0, the Windows .NET Server DNS server caches this information and subsequently does not set the OPT RR when sending queries to this DNS server. The lifetime of this cache can be specified in the following registry key: Name: EDNSCacheTimeout Key: HKLM/SYSTEM/CurrentControlSet/Services/Dns/Parameters Type: REG_DWORD Valid Range: 3600-15724800 (seconds) Default: 25200 Note If the value is set through the registry editor, the DNS server must be restarted in order for the new value to take effect. If the value is set through Dnscmd, the server does not need to be restarted. The administrator can set the EDNS cache timeout using Dnscmd by specifying the EDNSCacheTimeout parameter as shown in the following example. This example sets the timeout to one week for the DNS server ns1.widgets.microsoft.com: DNSCMD ns1.widgets.microsoft.com /config /EDNSCacheTimeout  604800 The administrator can configure Windows .NET Server DNS server to respond to a query with a response containing the OPT resource record only if an OPT record was included in the original query. This setting will cause the DNS server to not include “unsolicited” OPT records into queries to other servers unless the DNS server has previously cached the information that another server supports EDNS. To do this, the administrator would set the following registry key. Name: EnableEDnsProbes Key: HKLM/SYSTEM/CurrentControlSet/Services/Dns/Parameters Type: REG_DWORD Value: 0x0 Valid Range: 0x0 (disable) and 0x1 (enable) Exists by default: no Note If the value is set through registry editor DNS server must be restarted in order for new value to take effect. If the value is set through Dnscmd, the server does not need to be restarted. The administrator can set the value for EnableEDnsProbes using Dnscmd by specifying the EnableEDnsProbes parameter as shown in the following example. To configure Windows .NET Server DNS server to use ENDS only if an OPT record was included in the original query, use the following command: DNSCMD ns1.widgets.microsoft.com /Config /EnableEDnsProbes 0 To configure Windows .NET Server DNS server to always use ENDS (the default configuration) use the following command: DNSCMD ns1.widgets.microsoft.com /Config /EnableEDnsProbes 1   [a1] Should this be DNS clients?
• #26: Debug Logging Even though many of the logging options have not changed since Windows 2000, the GUI has been updated to make it much easier to configure logging for troubleshooting purposes. Figure 5 shows Debug logging options. Figure 5: Debug logging options in DNS server properties Enable filtering based on the IP address [a1] To provide additional filtering of the packets to be logged (i.e., those packets that are sent from some specific IP addresses to the DNS server or from the DNS server to some specific IP addresses), check the “Filter packets by IP address” checkbox and press the Filter button to display the Filter dialog box shown in Figure 6. If this checkbox is unchecked, the DNS server will log all packets regardless of the IP address. Figure 6: IP filter option in debug logging settings Event Logging Tab See Figure 7. Administrators can now control the level of event logs for Windows .NET DNS. This will make it easier to keep unnecessary “warnings” from appearing in the event log. In addition, it makes it possible to suppress all DNS errors if the administrator expects a long duration of known events to occur. Figure 7: Event Logging tab as viewed from DNS server properties   [a1] Changed names of check box and button to match Figure 5. Is this correct?
• #28: Restricting Round-Robin Rotation for Selected RR types By default, DNS uses round robin rotation to rotate the order of RR data returned in query answers where multiple RR’s of the same type exist for a queried DNS domain name. You can now specify that certain RR types are not to be round-robin rotated in the registry. There is a registry entry called DoNotRoundRobinTypes with a string value containing a list of RR types. By modifying this entry, you can turn off round-robin rotation for specific RR types. Name: DoNotRoundRobinTypes Key: HKLMSystemCurrentControlSetServicesDNSParameters Type: REG_DWORD Valid Range: any RR type For example, to prevent round-robin rotation for A, PTR, SRV, and NS records, you would enter the following value for the registry entry: a ptr srv ns Note Restriction of Round-Robin rotation is per record type. It is not possible to set a restriction for individual resource records.
• #29: During the Active Directory domain rename process, the rendom.exe tool goes through several steps to verify the integrity of the domain. This feature includes the ability to verify the presence or absence of DC Locator resource records on authoritative DNS servers. This tool will assist the administrator in ensuring that, after the domain rename, authentication and replication will be functional for the domain. During domain rename, the DC Locator records associated with the new name are pre-published in the authoritative DNS servers by the netlogon service running on the domain controllers of the domain. For DC location to be functional after domain rename, there are a subset of records whose presence at the authoritative DNS servers is critical for domain authentication and replication to take place. While the possibility exists that the domain rename process could result in an error, it will indicate which DC locator resource records are missing, thus making it easy for the administrator to troubleshoot the problem. None the less, it is important to understand which records the rendom.exe tool is publishing and verifying. The resource records that are listed below are the RR’s that rendom.exe is pre-publishing and verifying.
• #31: CNAME<DsaGuid>._msdcs.<DnsForestName>There must be one CNAME record associated with every domain controller in all authoritative DNS servers. This ensures that replication will take place from that DC. SRV_ldap._tcp.pdc._msdcs.<DnsDomainName>There must be one SRV record pertaining to the PDC on all authoritative DNS servers. This ensures the functioning of authentication of users and computers. SRV_ldap._tcp.gc._msdcs.<DnsForestName> There must be at least one record pertaining to at least one GC on all authoritative DNS servers. This ensures the functioning of authentication of users and computers. For example, one DNS server may contain a record of this type registered by one GC, while other DNS servers may contain the records of this type registered by other GCs. It is sufficient temporarily, if there is at least one record of this type present on all authoritative DNS servers. The other records will eventually replicate to all authoritative DNS servers. SRV_ldap._tcp.dc._msdcs.<DnsDomainName>There must be at least one record pertaining to at least one DC on all authoritative DNS servers. This ensures the functioning of authentication of users and computers. For example, one DNS server may contain a record of this type registered by one DC, while other DNS servers may contain the records of this type registered by other DC’s. It is sufficient (temporarily) if there is at least one record of this type present on all authoritative DNS servers. The other records will eventually replicate to all authoritative DNS servers. There are two more records that are also required for authentication. They are: An SRV record owned by _kerberos._tcp.dc._msdcs.<DnsDomainName> An A record owned by _gc._msdcs.<DnsForestName>. However, since these records are closely linked with the GC and the DC SRV records described in the table, we can assert that if the GC and DC SRV records are present, the KDC and GC IP Address records will also be present.