DNS is a hierarchical name-resolution system. It is also the largest public directory service deployed. Virtually every company uses DNS for name-resolution services, including hostname to IP address, IP address to hostname, and hostname to alternate hostname (aliases). DNS is a well-documented standard that has been around since the early days of the Internet. The following RFCs cover some of the basics of DNS:

There are three important DNS concepts that every Active Directory administrator must understand:

Client Lookup Process

The process for a client to resolve a DNS name is relatively straightforward, but depending on the name being resolved, the number of hops involved can vary dramatically. Figure 8-1 shows the hops involved for a machine to resolve the name www.whitehouse.gov using a caching DNS server (such as from the client’s Internet service provider, or ISP).

Figure 8-1. Client lookup process

The lookup process shown in Figure 8-1 involves eight steps:

1. The client sends a request to his DNS server for www.whitehouse.gov.

2. The client’s DNS server makes a request to one of the root name servers for assistance resolving the name.

3. The root name server refers the client to the name servers for the .gov domain.

4. The client’s DNS server makes a request to the .gov name server for assistance resolving the name.

5. The .gov name server refers the client to the name servers for the whitehouse.gov domain.

6. The client’s DNS server makes a request to the whitehouse.gov name server for www.whitehouse.gov.

7. The whitehouse.gov name server returns the A record for www.whitehouse.gov.

8. The client’s DNS server returns the response to the client.

As you can see, there are a number of hops involved. The name servers that clients use to resolve Internet names are often referred to as caching DNS servers because they cache a copy of the responses they get from other DNS servers for a period of time, to make future lookups faster. The linkage between the root name server and the .gov name server and the .gov name server and the whitehouse.gov name server is called a delegation. We’ll discuss delegations more later in this chapter. In a nutshell, the delegation contains the name server (NS) records that are necessary to point the client to the name servers responsible for the delegated domain.

One of the challenges with DNS is that there is no mechanism in the base protocol to verify that responses are authentic and accurate. In between the client machine and the authoritative DNS server hosting a given zone, there are often one or more nonauthoritative caching DNS servers involved. For example, when you browse to www.whitehouse.gov on your home computer, chances are your DNS query will go to your ISP’s caching DNS servers. Your ISP’s DNS server will in turn recursively resolve the query (www.whitehouse.gov) and then return the response to you.

The problem that DNSSEC solves is what happens if your ISP’s DNS server cache is poisoned by an attacker. If the cache is poisoned, the IP address returned might not be the actual IP address. With DNS, there is no way for the client to have a level of assurance about the validity of the response returned. DNSSEC provides the extensions to DNS to ensure that DNS responses are authentic.

How Does DNSSEC Work?

DNSSEC depends on two key components. The first component is a trust chain that begins with the root DNS servers, or with trust anchors that are deployed in your internal DNS infrastructure. The root DNS name servers are globally distributed and are responsible for the first hop when you want to resolve a name on the Internet. The second component is the publication of digital signatures in DNS for individual records and the zone as a whole. Combined, these two components enable you to verify the authenticity of a given DNS response.

Verifying the authenticity of a DNS response can happen in two places. The first place this can happen is on the DNS server that your client queries to resolve a name. The second possible location is in the DNS client on the machine making the query. The Windows DNS client (beginning with Windows 7 and Windows Server 2008 R2) is DNSSEC-aware but nonvalidating. Effectively, this means that the Windows DNS client is dependent on the upstream DNS servers to support DNSSEC. If you’re thinking about DNSSEC for resolving names on the Internet, your ISP will need to support DNSSEC on its DNS servers, and the zones hosting the records you want to resolve will need to be signed. If you’re thinking about internal DNS, you can deploy Windows Server 2012 DNS servers and/or Windows Server 2012 domain controllers to take advantage of DNSSEC.

Resource records

DNSSEC uses a number of new resource record types. These record types are listed in Table 8-2.

Table 8-2. DNSSEC record types

Record Type	Description
RRSIG	Stores a digital signature for a single resource record
DNSKEY	Publishes a public key used when signing DNS data
DS	Identifies the signing key used in a delegated DNS zone
NSEC3	The next Secure response record, used for providing an authenticated response that a name is not resolvable (a negative response) in the zone

The DNSKEY record stores two types of public keys: the key signing key (KSK) and the zone signing key (ZSK). The KSK is used only to sign other keys—namely, ZSKs. ZSKs are in turn used to sign records in the zone. Over time, it is important to be able to change the keys used to sign records. Windows Server 2012 provides automatic key management, but in the case of the KSK, you will have to work with the owner of the parent zone (e.g., whitehouse.gov would need to work with the owner of .gov) to update the Delegated Signer (DS) record when the KSK changes. The DS record contains a hash of the KSK and is used to verify the authenticity of a response.

Lookup process

If you refer back to Figure 8-1 and the accompanying text, you’ll see that there are a number of hops involved in resolving a name such as www.whitehouse.gov. We’ve specifically chosen www.whitehouse.gov as an example in this chapter because the whitehouse.gov DNS zone is signed and supports DNSSEC. In fact, in Step 7 of Figure 8-1, when the whitehouse.gov name server returns the www A record, the digital signature is also returned in an RRSIG record.

The steps necessary to verify the validity of the www.whitehouse.gov A record are:

1. The caching DNS server requests the zone signing key DNSKEY record and the corresponding RRSIG record for the whitehouse.gov zone.

2. The whitehouse.gov name server returns the DNSKEY and RRSIG records.

3. The caching DNS server computes the hash of the www.whitehouse.gov A record.

4. The caching DNS server decrypts the RRSIG record for www.whitehouse.gov with the whitehouse.gov ZSK to get the RRSIG record hash.

5. The caching DNS server compares the hashes and ensures they match.

At this point, assuming everything checks out, we have validated the response received, but we have no way of guaranteeing its authenticity. If this were the end of the validation process, there would be no way of guaranteeing that the DNS server’s cache wasn’t also poisoned with invalid RRSIG and DNSKEY records. So, we continue:

6. In order to verify the authenticity of the response, the caching DNS server requests the key signing key for the whitehouse.gov zone.

7. Next, the whitehouse.gov ZSK is validated by comparing the hash of the ZSK and the ZSK’s RRSIG record.

Note

Unlike before, the RRSIG for the zone’s zone signing key is encrypted with the zone’s key signing key.

To fully authenticate the response, we need to walk the trust chain. The trust chain exists in the reverse path of the DNS resolution that took place in Figure 8-1:

8. The caching DNS server asks the .gov name server for the DS record for whitehouse.gov.

9. The .gov name server returns the DS record and the corresponding RRSIG record.

10. To validate the response from whitehouse.gov, the server compares the hash of the whitehouse.gov KSK with the data in the DS record.

This validation is reliable because the DS record in the .gov name server was provided by the administrator of the whitehouse.gov name server. Later, when we configure DNSSEC, you’ll see where you get a copy of the data necessary for the DS record. Unfortunately, we’re not done yet. We now need to validate the authenticity of the data returned from the .gov name server:

11. The caching DNS server asks the root name server for the DS (delegated signer) record for .gov.

12. The root name server returns the DS record and the corresponding RRSIG record.

13. To validate the response from .gov, the server compares the hash of the .gov KSK with the data in the DS record returned from the root name server.

Finally, you may be wondering how we validate the response from the root name server. Ultimately, we need to have a well-known trust point. If you’re familiar with public key infrastructure (PKI) and certificates, this is much like the trusted root store in Windows. DNS stores trust anchors that contain the necessary data to validate the response from the root name servers and other name servers that are not related to a trusted set of name servers.

If you want to try making a query with DNSSEC enabled, you can do so with the Resolve-DnsName PowerShell cmdlet that was added in Windows 8 and Windows Server 2012. For example, to resolve www.whitehouse.gov, you would run Resolve-DnsName www.whitehouse.gov -DnssecOk. You will get a response back similar to the following. Note the signature information contained in the response:

Name                             Type   TTL   Section    NameHost
----                             ----   ---   -------    --------
www.whitehouse.gov               CNAME  0     Answer     www.whitehouse.gov.ed…
www.whitehouse.gov.edgesuite.net CNAME  0     Answer     www.eop-edge-lb.akadns…
www.eop-edge-lb.akadns.net       CNAME  0     Answer     a1128.h.akamai.net

Name        : www.whitehouse.gov
QueryType   : RRSIG
TTL         : 2348
Section     : Answer
TypeCovered : CNAME
Algorithm   : 7
LabelCount  : 3
OriginalTtl : 3600
Expiration  : 8/15/2012 10:23:13 PM
Signed      : 8/12/2012 9:23:13 PM
Signer      : whitehouse.gov
Signature   : {34, 111, 6, 55...}


Name       : a1128.h.akamai.net
QueryType  : A
TTL        : 18
Section    : Answer
IP4Address : 23.62.63.153


Name       : a1128.h.akamai.net
QueryType  : A
TTL        : 18
Section    : Answer
IP4Address : 23.62.63.152


Name      : .
QueryType : OPT
TTL       : 32768
Section   : Additional
Data      : {}
Enforcing DNSSEC Validation

As we discussed earlier, the DNS client in Windows does not perform validation of responses locally. Instead, the client depends on its DNS server to perform the validation for it. There are one or two steps involved in configuring this. First, on the properties of the clients’ DNS servers, you must ensure that “Enable DNSSEC validation for remote responses” is checked, as shown in Figure 8-16 in the section Recipe 8.8. Next, if you want to ensure that clients are receiving validated responses for some (or all) domains, you will need to configure the client’s Name Resolution Policy Table (NRPT).

The easiest way to configure the NRPT is with Group Policy. You can access the NRPT by browsing to Computer ConfigurationPoliciesWindows SettingsName Resolution Policy. Figure 8-2 shows the NRPT with a rule requiring that DNS requests for whitehouse.gov have been validated.

Figure 8-2. Name Resolution Policy Table configuration with Group Policy

The downside to Windows not being able to perform validation in the local client is that there is a vulnerability in the last hop between the client and the client’s DNS server. It is possible that the response could be tampered with during that last hop. Thus, to truly have complete end-to-end DNS validation, you will need to secure the last hop. One possible solution to this problem is to deploy IPSEC and use it to authenticate the connection between the client and the DNS server.

Configuring DNSSEC for Active Directory DNS

Up until now, we have discussed DNSSEC in the context of resolving a name on the Internet. While the principles we discussed are identical, the implementation is slightly different for Active Directory DNS. Namely, we’ll be signing dynamic zones and we’ll deploy trust anchors to Active Directory rather than relying on the recursive process of contacting parent name servers described earlier.

Before you can complete your DNSSEC deployment, you will need to upgrade all of your DNS servers to Windows Server 2012. Windows Server 2008 R2 DNS servers support DNSSEC validation, but they don’t support Active Directory-integrated trust anchors or signing of dynamic DNS zones.

The RRSIG records are not stored in Active Directory, as they would create a substantial amount of additional Active Directory replication traffic. Instead, the records are computed at server startup (and during record update/registration) and then stored in memory. When the DNS server service is started, all of the records in the zone will need to be signed to create RRSIG records. In a large zone this could take several minutes. Depending on the hashing algorithm and key length you choose, the speed will vary greatly. Both of these factors will also affect the amount of memory used by the DNS server service to store the RRSIG records in memory.

To begin the DNSSEC signing process, right-click the zone you want to sign and click DNSSEC→Sign the Zone. You’ll first be asked whether you want to create custom signing parameters, duplicate the signing parameters of another zone, or use the defaults. We’ll create custom signing parameters.

You’ll need to select one DNS server as the key master for the zone, as shown in Figure 8-3. The key master is responsible for generating new signing keys when they are requested or when keys expire.

Figure 8-3. Nominating the DNSSEC key master for the zone

Next, you’ll be prompted to generate a key signing key, as shown in Figure 8-4. KSKs are used to sign other types of signing keys. Generally speaking, you should be able to accept the defaults unless you have specific security requirements that mandate changing the defaults. Keep in mind that using a longer key or a stronger cryptographic algorithm will increase the CPU requirements and DNS server service startup times based on the increased mathematical workload.

The parameters shown in Figure 8-4 are:

Cryptographic algorithm

This is the type of hash to compute for the signature. You can define multiple key signing keys with different algorithms if you need to support multiple algorithms.

Key length

This is the number of bits that comprise the key. Choosing the key length is a balance between cryptographic strength and computational requirements to compute the hash.

Key storage provider

This is where the key will be stored. For Active Directory DNS you must use the Microsoft Software Key Storage Provider. If you were signing a static standalone zone, you could use a hardware security module (HSM), for example, to protect the private key.

DNSKEY RRSET signature validity period

This is time period (in hours) that a signature generated with this key is valid.

Key rollover

Over time, you will want to change the key that is used for signing in order to ensure that it is not compromised by brute force. Windows Server 2012 will automatically publish a new key on a periodic basis if requested. You may need to coordinate the publication and updating of the Delegated Signer (DS) record if you roll over the KSK.

Figure 8-4. Generating a new key signing key

The next key you will need to configure is the zone signing key (ZSK), as shown in Figure 8-5. The zone signing key is used to compute digital signatures (RRSIG records) for DNS records in the zone. The parameters shown in Figure 8-5 are much the same as those in Figure 8-4. The exception is that the default recommended key length is shorter and automatic rollover is more frequent. The default key length is shorter because the ZSK is used much more often (any time a record is created or updated, or for each record on service startup). The shorter key length lessens the CPU impact. The shorter key length is compensated for with a more frequent rollover. The ZSK does not have to be published anywhere outside of the zone, so there is much less overhead involved in a ZSK rollover.

Figure 8-5. Creating a new zone signing key

Next, you will be prompted to choose between NSEC and NSEC3 records, as shown in Figure 8-6. NSEC records are used to provide an authentic response that denies a record exists. More specifically, if you request a record (such as some-record.contoso.com) and there is no record called some-record, rather than returning an error (which could be spoofed), the server returns a signed response in the form of an NSEC or NSEC3 record. Generally speaking, we recommend the use of NSEC3 over NSEC. One of the shortcomings of NSEC records was that they could enable a dictionary attack that disclosed every single record in the DNS zone.

Figure 8-6. Next Secure record configuration

Finally, you will need to decide whether or not to publish the trust anchors for the zone to Active Directory, as shown in Figure 8-7. Once you publish the trust anchors, all DNS servers will begin validating responses for the zone. By default, trust anchor distribution is disabled.

Warning

Unless you are confident in the configuration you’ve completed and the configuration of the clients and other DNS servers in the environment, you will want to perform testing with a limited set of DNS servers and clients before deploying the trust anchors.

Figure 8-7. Configuring trust anchor distribution

The wizard will provide you with a copy of the information that will need to be stored in the DS record in the parent zone on the subsequent screen. If you do not own the parent zone, and this was for a public DNS zone, you will need to provide the DS record data to the owner of the parent zone (often your domain registrar).

Finally, the wizard will provide a progress screen as the zone is signed for the first time. Once the wizard completes and you refresh the console, you’ll see new records, similar to Figure 8-8. The DNS console also indicates that a zone is signed by overlaying a lock icon on the zone in the tree to the left.

Figure 8-8. Signed DNS zone contents

If you want to change any of the properties of the DNSSEC configuration for the zone, you can access those SEC properties by right-clicking the zone and choosing DNSSEC→Properties. When you are ready to publish trust anchors, you can do so by checking “Enable the distribution of trust anchors for this zone,” as shown in Figure 8-9.

Figure 8-9. DNSSEC zone properties

One of the fundamental issues for clients in any environment is finding the most optimal domain controller (DC) to authenticate against. The process under Windows NT was not very efficient and could cause clients to authenticate to domain controllers in the least optimal location. With Active Directory, clients use DNS to locate domain controllers via the DC locator process. To illustrate at a high level how the DC locator process works, we will describe an example where a client has moved from one location to another and needs to find a DC for the domain it is a member of:

The two main things that are needed to support an efficient DC locator process are proper definition of the site topology in Active Directory and the presence of all the necessary Active Directory-related resource records in DNS. In the next section, we will describe the purpose of the resource records used in Active Directory.

When you promote a domain controller into a domain, a file containing the necessary resource records for it to function correctly within Active Directory is generated in %SystemRoot%System32Config etlogon.dns.

The contents of the file will look something like the following for a DC named moose.mycorp.com in the mycorp.com domain with IP address 10.1.1.1. We’ve reordered the file a bit to group records of similar purpose together (note that some lines may wrap due to their length):

mycorp.com. 600 IN A 10.1.1.1
ec4caf62-31b2-4773-bcce-7b1e31c04d25._msdcs.mycorp.com. 600 IN CNAME 
moose.mycorp.com.
gc._msdcs.mycorp.com. 600 IN A 10.1.1.1
_gc._tcp.mycorp.com. 600 IN SRV 0 100 3268 moose.mycorp.com.
_gc._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 3268 moose.
mycorp.com.
_ldap._tcp.gc._msdcs.mycorp.com. 600 IN SRV 0 100 3268 moose.mycorp.com.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mycorp.com. 600 IN SRV 0 100
3268
moose.mycorp.com.
_kerberos._tcp.dc._msdcs.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mycorp.com. 600 IN SRV 0
100
88 moose.mycorp.com.
_kerberos._tcp.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.
_kerberos._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 88
moose.
mycorp.com.
_kerberos._udp.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.
_kpasswd._tcp.mycorp.com. 600 IN SRV 0 100 464 moose.mycorp.com.
_kpasswd._udp.mycorp.com. 600 IN SRV 0 100 464 moose.mycorp.com.
_ldap._tcp.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.
_ldap._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 
389 moose.mycorp.com.
_ldap._tcp.pdc._msdcs.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.
_ldap._tcp.97526bc9-adf7-4ec8-a096-0dbb34a17052.domains._msdcs.mycorp.com. 600 IN
SRV
0 100 389 moose.mycorp.com.
_ldap._tcp.dc._msdcs.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mycorp.com. 600 IN SRV 0 100
389
moose.mycorp.com.

Although it may look complicated, it isn’t. Let’s go through what these records actually mean, splitting the records up into sections for ease of understanding. To start with, the first record is for the domain itself:

mycorp.com. 600 IN A 10.1.1.1

Each DC attempts to register an A record for its IP address for the domain it is in, similar to the preceding record.

Next, we have the following record:

ec4caf62-31b2-4773-bcce-7b1e31c04d25._msdcs.mycorp.com. 600 IN CNAME
 moose.mycorp.com.

This is an alias or canonical name (CNAME) record. It is contained under the _msdcs subdomain, which is used by domain controllers to intercommunicate. The record is comprised of the DSA GUID for the server, which is an alias for the server itself. DCs use this record if they know the DSA GUID of a server and want to determine its IP address.

Next, we have this A record:

gc._msdcs.mycorp.com. 600 IN A 10.1.1.1

This is registered only if the domain controller is also a Global Catalog server. You can query gc._msdcs.mycorp.com with nslookup to obtain a list of all the Global Catalog servers in the forest.

The remaining resource records are of type SRV. The SRV record type was defined in RFC 2782, “A DNS RR for Specifying the Location of Services (DNS SRV).” The full text can be found at http://tools.ietf.org/html/rfc2782. Simply put, SRV records allow you to specify one or more servers on your network that should be used for specific protocols. These records also allow you to remap the port numbers for individual protocols or the priority of servers, determining the order in which certain servers are used.

A few more GC-specific records are shown next:

_gc._tcp.mycorp.com. 600 IN SRV 0 100 3268 moose.mycorp.com.
_gc._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 3268 moose.
mycorp.com.
_ldap._tcp.gc._msdcs.mycorp.com. 600 IN SRV 0 100 3268 moose.mycorp.com.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mycorp.com. 600 IN SRV 0 100
3268
moose.mycorp.com.

One interesting thing to note about SRV records is the seventh field, which designates the port used to contact the service on that host. In all of these cases, 3268 is used, which corresponds to the Global Catalog port. You may have also noticed the entries that contain Default-First-Site-Name. Each Global Catalog server registers site-specific records so clients can find the optimal Global Catalog based on their site membership. See the upcoming sidebar Site Coverage for more information.

The next few SRV records are for Kerberos authentication (port 88) and the kpasswd process (port 464), which allows users to change passwords via Kerberos:

_kerberos._tcp.dc._msdcs.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mycorp.com. 600 IN SRV 0
100
88 moose.mycorp.com.
_kerberos._tcp.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.
_kerberos._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 88
moose.
mycorp.com.
_kerberos._udp.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.
_kpasswd._tcp.mycorp.com. 600 IN SRV 0 100 464 moose.mycorp.com.
_kpasswd._udp.mycorp.com. 600 IN SRV 0 100 464 moose.mycorp.com.

c:> nltest /dsgetsitecov /server:dc01

Just as with the Global Catalog SRV records, there may be more site-specific Kerberos records for any additional sites the DC covers.

The rest of the SRV records are used to represent a domain controller for a particular domain and site:

_ldap._tcp.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.
_ldap._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 389 moose.
mycorp.com.
_ldap._tcp.pdc._msdcs.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.
_ldap._tcp.97526bc9-adf7-4ec8-a096-0dbb34a17052.domains._msdcs.mycorp.com. 600 IN
SRV
0 100 389 moose.mycorp.com.
_ldap._tcp.dc._msdcs.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mycorp.com. 600 IN SRV 0 100 
389 moose.mycorp.com.

One record to note is the _ldap._tcp.pdc._msdcs.mycorp.com. entry, which is registered by the DC that is acting as the PDC Emulator for the domain. No other FSMO roles are registered in DNS.

Based on all these records, you can obtain a lot of information about an Active Directory environment by doing simple DNS queries. Some of the information you can retrieve includes:

Now that we’ve covered what Active Directory uses DNS for, we will review some of the options for setting up who is authoritative for the Active Directory-related zones. Ultimately, the decision boils down to whether you want your existing DNS servers or different servers, such as the domain controllers, to be authoritative for the zones. There are many factors that can affect this decision, including:

We will look at each of these factors as they apply to delegating the AD zones. Other slight variations of these options do exist, but we will discuss only the basic cases.

Not Delegating the AD DNS Zones

The first impulse of any cost-conscious organization should be to determine whether their existing DNS servers can be authoritative for the AD zones. That could entail manually populating all the necessary resource records required by each DC if the current DNS implementation doesn’t support dynamic updates. While this sounds fairly trivial at first glance, it becomes decidedly less trivial once you begin to explore the requirements.

Political factors

If the existing DNS servers are utilized for the AD DNS zones, the Active Directory administrators will likely not have the same level of control as they would if the zones were delegated and managed by them. This separation of duties—and lack of control over a critical dependency like DNS—may make it difficult for AD administrators to guarantee a certain level of service for AD.

Initial setup and configuration

The initial population of the AD resource records can be burdensome, depending on how you manage your resource records and how easy it will be for you to inject new ones. For example, domain controllers try to register their resource records via DDNS on a periodic basis. Many organizations do not allow just any client to make DDNS updates, due to the potential security risks. For that reason, you’ll need to configure your existing DNS servers to allow the domain controllers to perform DDNS updates.

Non-Windows DDNS implementations often restrict which clients can perform DDNS registrations and updates based on IP address. With this in mind, DNS administrators will need to configure DDNS to only allow domain controllers to update certain zones in order to mitigate the security risks of allowing too many clients the ability to update any DNS record in the server. This should not typically be a problem, at least at a technical level, but you will need to ensure that you communicate changes and plan for turnaround time when adding new domain controllers or changing the IP address of a DC.

Support and maintenance

Assuming the existing DNS servers are stable and well supported (as they tend to be in most organizations), name-resolution issues should not be a problem for domain controllers or other clients that are attempting to locate a DC via DNS.

Ongoing maintenance of the DC resource records can be an issue, as pointed out previously. Each time you promote a new DC in the forest, you’ll need to make sure it is allowed to register all of its records via DDNS. The registration of these records could be done manually, but due to the dynamic nature of the AD resource records, they would have to be updated on a very frequent basis (potentially multiple times a day). In addition, promoting one DC could cause other DCs to update the records they need registered in DNS as well.

Yet another option is to programmatically retrieve the netlogon.dns file from each domain controller on a periodic basis and perform the DDNS updates from a script. In large environments, the manual solution will probably not scale, and either DDNS or a programmatic solution will need to be explored.

Integration issues

When Windows 2000 Active Directory was first released in 1999, this was more of a problem than it is today, but older versions of DNS server or administration software may not support SRV records or underscores in zone or record names (e.g., _msdcs.mycorp.com). Upgrading to the latest version of your DNS server platform should be a priority in this case.

Figure 8-10 shows how the client request process is straightforward when the AD DNS zones are not delegated. Clients point at the same DNS servers they always have.

Figure 8-10. Active Directory and DNS

Delegating the AD DNS Zones

While at first glance it may seem pretty straightforward to support AD DNS zones in your existing DNS infrastructure, it can cause difficulties depending on your environment. Perhaps the most straightforward option is simply to delegate the DNS namespace(s) Active Directory will use to your domain controllers and allow them to host the DNS zones. If you use AD-integrated DNS zones, the maintenance becomes even easier. After you’ve done the initial creation of the zones by promoting a domain controller, the records are stored in Active Directory and distributed to the other domain controllers via replication.

Political factors

Frequently, organizations will have a central DNS team that manages and supports name resolution. If you make the decision to delegate the AD DNS zones to domain controllers, for example, a significant part of name resolution for your clients will not be done on the existing corporate name servers anymore. This can make the DNS administrators uncomfortable, and rightly so. Note that Active Directory does allow you to delegate the management of records in an Active Directory-integrated DNS zone to other administrators very easily.

Initial setup and configuration

The initial setup to delegate the AD DNS zones is straightforward. An NS record and any necessary glue records—for example, an A record for the server to which you’re delegating—need to exist on the parent zone pointing to the servers that will be authoritative for the zones. The rest of the configuration must be done on the servers that are going to support the AD DNS zones. If those servers are one or more domain controllers running Active Directory-integrated DNS, you will only need to add the DNS service (newer versions of Windows will allow you to perform this step as part of the DC promotion process).

Note

While it is entirely possible to run the DNS zones supporting Active Directory on Windows-based DNS servers other than the domain controllers, it is unlikely that this will make much sense considering the enhanced functionality that is only available when running Windows DNS on a domain controller.

Support and maintenance

Ongoing support and maintenance of the AD DNS zones is very minimal, especially if you are using AD-integrated zones. In fact, since the domain controllers can use DDNS to update DNS, this is one of the primary benefits of using this method.

Integration issues

Unless you already run Windows DNS server, it is unlikely you’ll be able to manage the AD DNS zones in the same manner as your existing DNS infrastructure. Figure 8-11 illustrates how, by delegating the AD DNS zones, you can still have clients point to the same DNS servers they do today. A variation of this approach would be to point the clients at the AD DNS servers and configure forwarding, as described in the next section.

Figure 8-11. Client request flow when delegating the AD DNS zones

If you’ve decided to host your AD DNS zones on your domain controllers, you should be using AD-integrated zones. This section will explain some of the benefits of using AD-integrated DNS versus standard primary zones.

Figure 8-12. Forwarders configuration screen in the Windows Server 2003 DNS MMC snap-in

Figure 8-13. Managing a conditional forwarder in Windows Server 2008

In the normal world of DNS, you have two types of name servers: primary (sometimes called a master) and secondary (a.k.a. slaves). The primary name server for a zone holds the data for the zone in a file on the host and reads the entries from there. Each zone typically has only one primary. A secondary gets the contents of its zone from the primary that is authoritative for the zone. Each primary name server can have multiple secondary name servers. When a secondary starts up, it contacts the primary for each zone and requests a copy of the relevant zone file via zone transfer. The contents of the secondary file are then dynamically updated over time, according to a set scheme. This is normally a periodic update or triggered automatically by a message from the primary stating that it has received an update. This is a very simplified picture, as each name server can host multiple zones, allowing each server to have a primary role for some zones and a secondary, for others.

Each type of server can resolve name queries that come in for the zones that it hosts. However, if a change must be made to the underlying contents of the DNS file, it has to be made on the primary name server for that zone. Secondary name servers cannot accept updates.

Another option available with Active Directory and Windows DNS Server is to integrate your DNS data into Active Directory. Effectively, this means that you can store the contents of the zone file in Active Directory as a hierarchical structure. Integrating DNS into Active Directory means that the DNS structure is replicated among all DCs of a domain; each DC holds a writable copy of the DNS data. The DNS objects stored in Active Directory could be updated on any DC via LDAP operations or through DDNS against DCs that are acting as DNS servers. This effectively makes the entire set of DCs act like primary name servers, where each DC can write to the zone and issue authoritative answers for the zone. This is a far cry from the standard model of one primary name server and one or more secondary name servers, which has the obvious downside of a single point of failure for updates to DNS.

There is a possible issue when using integrated DNS with Windows 2000 domain controllers, called the “DNS island” issue. Active Directory requires proper DNS resolution to replicate changes, and when using integrated DNS, the domain controllers replicate DNS changes through Active Directory replication. This is the classic chicken-and-egg problem; it can be avoided with proper configuration. The issue occurs when a forest root domain controller configured as a name server points at itself for DNS resolution. If that DC changes its IP address, the DNS records are successfully updated locally. However, unless the other DCs point at that same DC for their DNS resolution, they cannot resolve the DC’s IP address, so replication fails and no other DC gets the IP address change. The forest root domain controller has effectively been segregated from the rest of the forest and becomes its own replication island. To avoid this issue, the forest root domain controllers that are name servers should be configured to point at root servers other than themselves.

Application partitions, as described in Chapter 4, are user-defined partitions that have a customized replication scope. Domain controllers that are configured to host replicas of an application partition will be the only servers that replicate the data contained within the partition. One of the benefits of application partitions is that they are not limited by domain boundaries. You can configure domain controllers in completely different domains to replicate an application partition, so long as they are in the same forest. It is for these reasons that application partitions make a lot of sense for storing AD-integrated DNS zones. No longer do you have to store DNS data within the domain context and replicate it to every domain controller in the domain, even if only a handful are DNS servers. With application partitions, you can configure Active Directory to replicate only the DNS data between the domain controllers running the DNS service within a domain or forest.

There is one default application partition for each domain and forest. When configuring an AD-integrated zone, you have several options for storing the DNS data. These options are listed in Table 8-3.

The final option in Table 8-3 highlights that you can define custom application partitions outside of the default DomainDnsZones and ForestDnsZones partitions. Some organizations elect to define additional application partitions to control the replication scope of other DNS zones. For example, your domain controllers might be hosting DNS zones specific to a certain building or campus, so you might define an application partition called CampusDnsZones just to host these zones. You would, in turn, configure only the domain controllers at that campus to host this application partition, thereby limiting the replication scope of those zones.

When installing a new Windows Server 2003 Active Directory forest, the default DNS application partitions are created automatically. If you’ve upgraded from Windows 2000, you can manually create the DNS application partitions by using the DNS MMC snap-in or the dnscmd.exe utility. To manually create the DNS application partitions with the DNS MMC snap-in, right-click the server on the lefthand side and click “Create Default Application Directory Partitions.” Once you have created the application partitions, you must modify the replication scope of each zone individually to take advantage of the application partition replication, using these steps:

Figure 8-14. Modifying a DNS zone’s replication scope

One of the complexities of running a DNS infrastructure where clients can register their own records is that over time, records will build up in your zones for clients that no longer exist, or perhaps have a new name. If you only have a small number of machines on your network, you could likely manage these records yourself through the MMC. On the other hand, if you have hundreds or even hundreds of thousands of machines participating in a single DNS zone, chances are you won’t be able to manage the lifecycle of these records on your own.

Fortunately, the Windows DNS implementation includes a feature called scavenging that can help. Scavenging is a background process that you configure on a per-DNS-server basis to scan all of the records in a zone and remove the records that have not been refreshed in a certain time period. Clients that register themselves with dynamic DNS will automatically refresh their DNS registrations periodically. Windows DNS will store this timestamp as an attribute of the DNS record. By default, Microsoft DNS clients update and refresh their DNS registrations once every 24 hours.

One of the scavenging configuration options is the “no-refresh interval,” which defines how often the DNS server will accept the DNS registration refresh and update the DNS record. This functionality limits the amount of unnecessary replication for DNS record timestamp updates. For records that are manually created, the refresh timestamp is set to zero, which excludes the record from scavenging. You can also edit dynamically registered records to exclude them from scavenging.

Configuring Scavenging

Configuration of scavenging is a two-step process:

1. Enable scavenging for a specific DNS zone and define the refresh intervals for that zone.

   Note

   If you right-click on the DNS server node in the DNS MMC, there is an option called “Set Aging/Scavenging for All Zones” that will allow you to configure these two values once for all of the DNS zones hosted on that particular DNS server.

2. Enable scavenging on at least one DNS server hosting the zone and define how often the scavenging process runs.

Be sure that you complete both steps. Many administrators forget one of these steps and discover that scavenging is not working as expected. You only need to complete step 2 on at least one DNS server hosting each zone enabled for scavenging. Some administrators opt to configure every DNS server for scavenging (step 2), while others opt to only enable the scavenging process on certain domain controllers. Generally it is easier to simply enable the process on each DNS server.

Setting zone-specific options

The options to enable scavenging for a particular zone are accessible via the Aging button on the properties of the zone (see Figure 8-15). As shown in the next section, Enabling scavenging on the DNS server, there are two configuration items of interest:

No-refresh interval

This is how often the DNS server will propagate a timestamp refresh from the client to the directory or filesystem. The default value is seven days and is generally acceptable. The purpose of this setting is to reduce the amount of unnecessary replication or zone transfer activity that would be solely necessary for a timestamp update.

Refresh interval

This is how long the DNS server must wait following a refresh for a record to be eligible for scavenging. The default value here is again seven days. In practical terms, if you use the default values here, and a client refreshes its record on the seventh day of the month and then goes offline, the DNS server will scavenge the record no earlier than the fourteenth day of the month.

Enabling scavenging on the DNS server

Figure 8-15. DNS zone scavenging settings

The actual scavenging process must be enabled and configured on one or more DNS servers for scavenging to occur. It is a common misconception that the only scavenging configuration necessary is on the DNS zone itself.

To change the DNS server scavenging settings, access the properties of the DNS server in the DNS MMC and choose the Advanced tab, as shown in Figure 8-16. You will need to enable the scavenging process and define an interval for how often it runs. The default of seven days is often acceptable; however, you can adjust it to run as frequently as every hour. Be careful that you don’t set it to run so often that the DNS server is constantly running the scavenging process, though, as this would be counterproductive.

Figure 8-16. DNS server advanced properties

Traditionally, scripting common tasks involving Windows DNS servers has been difficult to do without a mix of complex tools. The DNS service has exposed various APIs via Windows Management Instrumentation (WMI) that you can access from VBScript and other scripting languages. Some tasks can only be automated with the dnscmd command-line tool, which requires complex text scraping and processing.

Windows Server 2012 introduces a wide range of Windows PowerShell cmdlets for managing DNS on Windows Server 2008 and newer DNS servers. In fact, with Windows Server 2012, you should be able to complete nearly any task dnscmd supports with Windows PowerShell. To make the DNS server cmdlets available and get a complete list of the cmdlets available for managing DNS, you can use these commands:

Import-Module DnsServer
Get-Command -Module DnsServer

In addition, the DnsClient and DnsConfig PowerShell modules provide the cmdlets necessary to manage the DNS configuration on a machine and resolve names. The Resolve-DnsName cmdlet provides the functionality that traditionally required you to use the nslookup command-line tool.

Active Directory relies heavily on DNS. In fact, Microsoft has shifted completely away from WINS for name resolution within the NOS in favor of standards-based DNS. The DC locator process is a core DNS-based function used within Active Directory to help domain controllers and clients locate domain controllers that have certain properties, such as residing in a particular site or being a Global Catalog server or PDC emulator. Deciding how to manage the AD DNS zones can be difficult, with each option having its own advantages and disadvantages. If you delegate the zones to domain controllers, AD-integrated zones can save you a lot of time in maintenance and upkeep and optionally enable you to divide the responsibility for DNS between traditional DNS administrators and the AD administrator.