The only time DNS data is stored in Active Directory is if you have a zone that is AD integrated. When using standard primary and secondary zones that are not AD integrated, the DNS data is stored locally in the filesystem of each DNS server in zone files. If you have an AD integrated zone configured for legacy compatibility, a container is created in the following location: cn=<ZoneName>,cn=MicrosoftDNS,cn=System,<DomainDN>, where <ZoneName> is the name of the zone.

You can also use application partitions to store DNS data in an alternate location. By default, there are three replication options for DNS zones stored in Active Directory:

The default location for the second option is dc=DomainDNSZones,<DomainDN>; for the third option, it is dc=ForestDNSZones,<ForestDN>. These two locations are actually application partitions that are replicated only to the domain controllers that are DNS servers in the domain or forest, respectively.

Inside the MicrosoftDNS container is a dnsZone object for each AD integrated zone. Inside the dnsZone container are dnsNode objects that store all resource records associated with a particular node. In the following text representation of an A record, the dc1.adatum.com name is considered a node (generally the left side of the resource record):

dc1.adatum.com. 600 IN A 6.10.57.21

There could be multiple resource records associated with the dc1.adatum.com name, so Microsoft decided to implement each distinct name as a dnsNode object. The dnsNode object has a dnsRecord attribute, which is multivalued and contains all of the resource records associated with that node. Unfortunately, the contents of that attribute are stored in a binary format and are not directly readable.

Table 13-1 and Table 13-2 contain some of the interesting attributes that are available on dnsZone and dnsNode objects.

You want to create a forward lookup zone. A forward lookup zone maps FQDNs to IP addresses or other names.

Creating a Reverse Lookup Zone for creating a reverse lookup zone; “Add a Forward Lookup Zone”; MSDN: DNS WMI Provider; MSDN: CreateZone Method of the MicrosoftDNS_Zone Class

You want to create a reverse lookup zone. A reverse lookup zone maps IP addresses to names.

Creating a reverse zone is very similar to creating a forward zone. See Creating a Forward Lookup Zone for more information.

“Add a Reverse Lookup Zone”; MSDN: CreateZone Method of the MicrosoftDNS_Zone Class

You want to view the zones on a server.

MSDN: MicrosoftDNS_Zone

You want to convert a standard primary zone to an AD integrated zone. This causes the contents of the zone to be stored and replicated in Active Directory instead of in a text file on the local server.

See this chapter’s Introduction; Moving AD Integrated Zones into an Application Partition, and Active Directory, Fifth Edition by Brian Desmond et al. (O’Reilly) for more on AD integrated zones.

“Configure AD Integrated Zones”; MSDN: ChangeZoneType Method of the MicrosoftDNS_Zone Class

You want to move AD integrated zones into an application partition.

Application partitions are user-defined partitions that can be configured to replicate with any domain controller in a forest. This provides flexibility for how you store and replicate your AD integrated zones. You could, in fact, have a few domain controllers from each domain act as DNS servers for all of your AD domains.

Chapter 17 for more information on application partitions

You want to enable zone transfers to specific secondary name servers.

Depending on your environment, your DNS implementation may require that you create secondary zones to allow for load balancing for busy DNS servers or remote sites connected by slow links. In this situation, you want to allow zone transfers to occur between your AD integrated DNS servers and your secondary servers, but you want to restrict which hosts can initiate zone transfers with your AD integrated name servers. Allowing anyone to initiate a zone transfer with your domain controllers could provide an attacker with information for mapping out your network; it is therefore critical that you limit which hosts can pull zone transfers from your servers.

If you are using only Active Directory−integrated zones, the Name Servers tab will be automatically populated with a list of all name servers that are authoritative for the selected zone, and this is the recommended choice when you have a large network with many name servers deployed. If any of your name servers are using standard zone files, however, you will need to populate this tab manually for any secondary name servers you deploy.

Specifying a list of IP addresses for hosts that can initiate zone transfers may be more secure since it is more specific, but this approach has the trade-off of creating the additional management overhead of keeping track of the IP addresses of all name servers on your network, so you should follow this approach only if your network is small and you have relatively few name servers deployed. Another disadvantage of this approach is that if you forget to add some IP addresses of name servers to your list, zone information stored on those servers could become stale, causing name resolution to fail for some of your clients. This could result in some of your users experiencing difficulties in accessing network resources.

DNS is secured, by default, because in the case of file-based zones, it is configured to allow zone transfers only with servers listed on the Name Servers tab of a zone. In the case of Active Directory integrated zones, DNS is configured to disallow zone transfers entirely—they generally aren’t needed in an Active Directory environment because the data replicates through Active Directory replication.

“Understanding zones and zone transfer”

You want to configure forwarding to allow for name resolution outside of your corporate network.

Name servers have long supported the notion of forwarders. Rather than sending all unresolved queries to the root Internet name servers, you can use forwarders to send queries to a specific server or set of servers, perhaps hosted by your ISP or by a partner corporation. This allows you to better control the name resolution process on your network.

MS KB 304491 (Conditional Forwarding in Windows Server 2003); MS KB 811118 (Support WebCast: Microsoft Windows Server 2003 DNS: Stub Zones and Conditional Forwarding)

You want to configure forwarding for specific domain names.

With conditional forwarding, you can forward unresolved queries for specific domains to different name servers. The most common use of conditional forwarding is when you have two or more noncontiguous namespaces. Consider, for example, a merger between the adatum.com and othercorp.com corporations. Normally, for the name servers of adatum.com to resolve queries for othercorp.com, the queries would have to first be forwarded to the root Internet name servers. With conditional forwarding, you can configure the adatum.com DNS servers so that all requests for othercorp.com should be sent directly to the othercorp.com name servers and all other unresolved queries should be sent to the Internet, and vice versa. The trade-off for this feature is the additional CPU processing that’s necessary to examine each query and forward it to the appropriate server, rather than just funneling all unresolved queries to a single external server.

You want to delegate control of managing the resource records in a zone.

By default, members of the DNSAdmins group have control over DNS server and zone configuration. You can delegate control of individual AD integrated zones by modifying permissions on the zone object in AD. The solutions show examples for how to grant full control to an additional user or group over a particular zone.

MS KB 256643 (Unable to Prevent DNS Zone Administrator from Creating New Zones)

You want to create and delete resource records in a zone.

MSDN: MicrosoftDNS_ResourceRecord

You want to query resource records.

MSDN: MicrosoftDNS_ResourceRecord; RFC 1035 (Domain Names—Implementation and Specification); RFC 1700 (DNS Parameters)

You want to modify the DNS server settings.

The Microsoft DNS server supports a variety of settings to configure everything from scavenging and forwarders to logging. With the DNS Management snap-in, the settings are spread over several tabs in the Properties page. You can get a list of these settings by simply running dnscmd /config from a command line.

MSDN: MicrosoftDNS_Server

You want to scavenge old resource records. DNS scavenging is the process whereby resource records are automatically removed if they are not updated after a period of time. Typically, this applies only to resource records that were added via dynamic DNS (DDNS), but you can also scavenge manually created static records. DNS scavenging is a recommended practice so that your DNS zones are automatically kept clean of stale resource records.

The following solutions will show how to enable automatic scavenging on all AD integrated zones.

> dnscmd <DNSServerName> /config /ScavengingInterval <ScavengingMinutes>
> dnscmd <DNSServerName> /config /DefaultAgingState 1
> dnscmd <DNSServerName> /config /DefaultNoRefreshInterval <NoRefreshMinutes>
> dnscmd <DNSServerName> /config /DefaultRefreshInterval <RefreshMinutes>
> dnscmd <DNSServerName> /config ..AllZones /aging 1

Set-DnsServerScavenging -ScavengingState $True -RefreshInterval "<Value>" -ScavengingInterval "<Value>"
Start-DnsServerScavenging -Force

There are four settings that you need to be aware of before enabling scavenging. You must use caution when enabling scavenging, because an incorrect configuration could lead to resource records getting deleted by mistake.

The first setting you have to configure is the scavenging interval. This is the interval in which the DNS server will kick off the scavenging process. It is disabled by default so that scavenging does not take place unless you enable this setting. The default value is seven days.

The second setting is the default aging configuration setting for new zones. If you want all new zones to be configured for scavenging, set this to 1.

The next two settings control how records get scavenged. The no-refresh interval determines how much time must pass before a dynamically updated record can be updated again. This setting is necessary to reduce how often a DNS server has to update its timestamp of the resource record. The default value is seven days. This means that after a resource record has been dynamically updated, the server will not accept another dynamic update for the same record for another seven days. However, if the IP address or some other data for the record changes, the server will still accept the new information. Static records have a timestamp of 0 and will not get scavenged in an automated scavenging process.

The refresh interval setting is the amount of time that must pass after the no-refresh interval during which a client can update its record before it is considered old or stale. The default value for this setting is also 168 hours (seven days). If you use the default values, the combination of the no-refresh interval and refresh interval would mean that a dynamically updated record would not be considered stale for up to 14 days after its most recent update. Combine this with the default scavenging interval, and it could be up to 21 days before a record is deleted if the record became stale immediately after the last scavenge process completed: 7 days (no refresh) + 7 days (refresh) + up to 7 days (scavenge process) = up to 21 days.

The solutions in this recipe show you how to configure these settings for all zones that are hosted on a server; however, you can configure these settings for individual zones as well. In the GUI solution, you would do this by accessing the Properties sheet of an individual zone rather than the server node; in dnscmd, simply specify the zone name after /aging, /scavenginginterval, /defaultagingstate, /defaultnorefreshinterval, or /defaultrefreshinterval.

You want to clear the DNS cache. The DNS cache contains resource records that are cached by the server or workstation for a period of time in memory so that repeated requests for the same record can be returned immediately. There are two types of DNS cache. One pertains to the cache on the Windows DNS client resolver (this can refer to both server and workstation operating systems when they are requesting DNS information from a server), and the other refers to the cache used by the Microsoft DNS server software.

To flush the client resolver cache, use the following command:

> ipconfig /flushdns

To flush the client resolver cache by using PowerShell, use the following cmdlet:

Clear-DnsClientCache

To flush the DNS server cache, use any of the following solutions.

> dnscmd <DNSServerName> /clearcache

Clear-DnsServerCache -Force

The client resolver cache is populated whenever a DNS lookup is performed on a workstation or server (e.g., by visiting a website in Internet Explorer, a DNS lookup is performed and cached). It’s important to remember that this cache will store positive DNS responses as well as negative ones. For example, if lost network connectivity causes DNS queries for an external resource like a mail server to fail, those queries will continue to fail until the cache refreshes: the queries have been negatively cached.

The second type of cache is in place on Microsoft DNS servers and on some third-party DNS servers. It is a cache of all DNS requests that the server has made while processing queries from various clients. You can view this cache by browsing the Cached Lookups folder for a server in the DNS Management snap-in. This folder is not shown by default, so you’ll need to select Advanced from the View menu.

With both the client and server cache, records are removed from the cache after the record’s TTL value expires. The TTL is used to age records so that clients and servers will request an updated copy of the record at a later point in order to receive any changes that may have occurred.

You want to verify that DNS is configured correctly so that a domain controller can register its resource records, which are needed for clients to be able to locate various AD services.

With the default setup, domain controllers attempt to dynamically register the resource records necessary for them to be located by Active Directory clients and other domain controllers. Domain controllers must have their resource records populated in DNS in order to function, but it can be very tedious and error-prone to register all of the records manually. This is why allowing the domain controllers to use DDNS to automatically register and update their records can be much easier from a support standpoint.

The dcdiag command provides a RegisterInDNS switch that allows you to test whether the DC can register its records. In the solution, we showed the output if the domain controller passes the test.

Here is the output if an error occurs:

Starting test: RegisterInDNS
   This domain controller cannot register domain controller Locator DNSrecords. This is because it cannot locate a DNS server authoritative for thezone adatum.com. This is due to one of the following:

   1. One or more DNS servers involved in the name resolution of the adatum.com name are not responding or contain incorrect delegation of the DNS zones; or

   2. The DNS server that this computer is configured with contains incorrect root hints.

   The list of such DNS servers might include the DNS servers with which this computer is configured for name resolution and the DNS servers responsiblefor the following zones: adatum.com

   Verify the correctness of the specified domain name and contact yournetwork/DNS administrator to fix the problem.

   You can also manually add the records specified in the %systemroot%system32config
etlogon.dns file.

As you can see, the output of dcdiag offers some options for resolving the problem. The information provided will also vary depending on the error encountered.

Registering a Domain Controller’s Resource Records for registering a domain controller’s resource records

You want to enable DNS debug logging to troubleshoot issues related to DNS queries or updates.

With the DNS Server debug log, you can record all DNS operations received and initiated by the server, including queries, updates, zone transfers, etc. If you need to troubleshoot a particular host, you can use the LogIPFilterList setting in dnscmd or the WMI DNS Provider to restrict the log to operations performed only for or by that host.

The most important debug log setting is the log level. With the DNS snap-in, you can select from a list of available options. The DNS snap-in provides an intuitive interface for selecting the required options. Table 13-3 contains all of the event codes with their hexadecimal and decimal values for the command-line options.

DNS debug logging can come in handy if you want to look at the dynamic update requests a particular DNS server is processing. For example, if a client or DHCP server is attempting to dynamically register records, you can enable the Update Transactions log category on the DNS server you think should be processing the updates. If you don’t see any update transactions, this can indicate that another server is processing the dynamic update requests.

MSDN: MicrosoftDNS_Server

You want to manually force registration of a domain controller’s resource records. This may be necessary if you’ve made some configuration changes on your DNS servers to allow your domain controllers to start dynamically registering resource records.

With the nltest command, a /dsregdns switch allows you to force registration of the domain-controller-specific resource records. You can also force reregistration of its resource records by restarting the NetLogon service on the domain controller. The NetLogon service automatically attempts to reregister a domain controller’s resource records every hour, so if you can wait that long, you do not need to use nltest.

Verifying That a Domain Controller Can Register Its Resource Records for verifying whether a domain controller is registering its resource records

You want to manually deregister a domain controller’s resource records.

When a domain controller is demoted from a domain, it dynamically deregisters its resource records. This is a nice feature of the demotion process because it means you do not have to manually remove all of the resource records or wait for scavenging to remove them. If, however, you have a domain controller that crashes and you do not plan to bring it back online, you’ll need to remove the records manually or wait for the scavenging process to take place.

You can use the DNS Management MMC snap-in and even the dnscmd.exe utility to manually remove them one by one, or you can use nltest, as shown in the solution.

The /dsderegdns switch also has /DomGUID and /DsaGUID options if you want to delete the records that are based on the domain GUID and DSA GUID, respectively. You need to know the actual GUIDs of the domain and domain controller to use those switches, so if you don’t have them handy, it would be easier to delete them using the DNS Management MMC snap-in.

You want to prevent a domain controller from dynamically registering its resource records using DDNS. If you manually register a domain controller’s resource records, you’ll want to prevent those domain controllers from attempting to dynamically register them. If you do not disable them from sending dynamic update requests, you may see annoying error messages on your DNS servers that certain DDNS updates are failing.

By default, domain controllers attempt to dynamically register their Active Directory−related resource records every hour via the NetLogon service. You can prevent a domain controller from doing this by setting the UseDynamicDNS value to 0 under HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameters. After you set that value, you should stop the NetLogon service, remove the %SystemRoot%system32config etlogon.dnb file and then restart NetLogon. It is necessary to remove the netlogon.dnb file because it maintains a cache of the resource records that are dynamically updated. This file will get re-created when the NetLogon service restarts.

Preventing a Domain Controller from Dynamically Registering Certain Resource Records for preventing certain resource records from being dynamically registered; MS KB 198767 (How to Prevent Domain Controllers from Dynamically Registering DNS Names)

You want to prevent a domain controller from dynamically registering certain resource records. It is sometimes advantageous to prevent certain resource records from being dynamically registered. For example, if you want to reduce the load on the PDC Emulator for a domain, you can prevent some of its SRV records from being published, which would reduce the amount of client traffic the server receives.

The procedure to disable registration of certain resource records is very similar to that described in Preventing a Domain Controller from Dynamically Registering All Resource Records for preventing all resource records from being dynamically registered; however, in this case you need to create a value called DnsAvoidRegisterRecords under the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameters key. The type for DnsAvoidRegisterRecords should be REG_MULTI_SZ, and the data should be a whitespace-separated list of mnemonics. Mnemonics are used to represent various resource records that domain controllers register. The complete list of mnemonics is included in Table 13-4.

If you configure DCs not to register these domain-wide SRV records, such as in a branch office environment, your branch office clients will still fail over to DCs in your hub site if their local DC becomes unavailable. Clients will continue to use the hub site DCs until they are rebooted, even if the local DC comes back online. MS KB 939252 provides a hotfix for Windows XP and Windows Server 2003 that will improve client failover behavior in this scenario. In Windows operating systems since Windows XP, there is improvement and built-in control available. See TechNet for more details.

Preventing a Domain Controller from Dynamically Registering All Resource Records for preventing all resource records from being dynamically registered

You want to allow computers to use a domain suffix that is different from their AD domain.

Windows Server and client domain members dynamically maintain the dNSHostName and servicePrincipalName attributes of their corresponding computer object in Active Directory with their current hostname. By default, those attributes can only contain hostnames that have a DNS suffix equal to the Active Directory domain the computer is a member of.

If the computer’s DNS suffix is not equal to the Active Directory domain, as may be the case during a domain migration or a corporate merger or consolidation, 5788 and 5789 events will be generated in the System event log on the domain controllers the clients attempt to update. These events report that the dnsHostName and servicePrincipalName attributes could not be updated due to an incorrect domain suffix. You can avoid this by adding the computer’s DNS suffix to the msDS-AllowedDNSSuffixes attribute on the domain object (e.g., dc=adatum,dc=com).

MS KB 258503 (DNS Registration Errors 5788 and 5789 When DNS Domain and Active Directory Domain Name Differ)

You want to permit (i.e., authorize) a DHCP server to process DHCP requests from clients. This is necessary only if the DHCP server is a member of an Active Directory domain.