Design and Implement Network Infrastructure Services

Objective 2.2: Design a name resolution solution strategy

Name resolution typically involves Domain Name System (DNS) but can also include Windows Internet Name Service (WINS). This objective concentrates on design of the solution rather than its implementation.

This objective covers just this topic:

• Design considerations, including secure name resolution, DNSSEC, DNS socket pool, cache locking, disjoint namespaces, DNS interoperability, migration to application partitions, IPv6, Single-Label DNS Name Resolution, zone hierarchy, and zone delegation

Designing a name resolution strategy

You need to keep several things in mind when designing a complex name resolution strategy at the enterprise level. These include prioritizing security while at the same time providing a reliable and robust infrastructure for the organization. Several features of Windows Server 2012 can be used to create this robust and reliable design.

In addition to the features you can use to create a robust and reliable design, you should also be intimately familiar with DNS for the exam. This includes being familiar with the DNS protocol as well as the tools and concepts surrounding implementation of DNS in an enterprise. Many of these tools and concepts have existed for quite some time and aren’t directly called out as objectives on the exam. As an enterprise administrator, you are expected to have the prerequisite knowledge of a primary protocol such as DNS.

Table 2-2 Additional resources

Concept	More Information
Conditional forwarding	http://technet.microsoft.com/library/0104be3c-0405-4455-b011-6950875c0446
DNS zone types	http://technet.microsoft.com/library/cc771898
DNS server placement	http://technet.microsoft.com/library/cc737361
Troubleshooting DNS	http://technet.microsoft.com/library/cc753041
DNS Technical Reference	http://technet.microsoft.com/library/dd197461

Secure name resolution

Ensuring secure name resolution includes making sure that the name server and DNS server have been secured. The Advanced tab in the DNS server Properties sheet, shown in Figure 2-9, contains several check boxes relevant to secure name resolution.

Among the options relevant to DNS security is Secure Cache Against Pollution, which randomizes the source port for requests, and Enable DNSSEC Validation For Remote Responses, which is discussed in the “DNSSEC” section later in this chapter.

Several other design considerations should be examined when looking at the name resolution strategy. If clients will resolve external DNS names, such as for Internet hosts, you can configure a group of DNS servers in the forest root domain to forward queries to external DNS servers or by using root hints so that any child domain servers forward queries to the forest root domain servers.

This is essentially what you’ll do by disabling recursion on a child DNS server. You can disable recursion for DNS servers that are authoritative for DNS zones but don’t need to provide general DNS resolution to clients on the network. A good example of this is an enterprise scenario in which the domain controllers are separate from the DNS servers that clients use for normal Internet name resolution. In such a scenario, recursion should be disabled on the domain controllers. If your domain has both types of records, you should consider splitting the DNS namespace between external and internal servers.

Zone transfers should be disabled by default and enabled only to allowed hosts.

DNSSEC

DNSSEC, defined primarily by RFCs 4033, 4034, and 4035, adds security to DNS. Windows Server 2012 enhances support for DNSSEC (DNS Security Extensions). DNSSEC provides new resource records and also provides for data integrity, origin authority, and authenticated denial of existence. DNSSEC operates using public key cryptography whereby clients receive cryptographically signed responses to queries. The clients have the public key of the server signing the response and can therefore ensure the validity of the response, and that it hasn’t been tampered with.

DNSSEC can also sign entire zones via the dnscmd.exe tool. With Windows Server 2012, you can now deploy DNSSEC in Active Directory–integrated zones with dynamic updates. This is a change from previous versions of Windows and its support for DNSSEC.

DNSSEC establishes a chain of trust with a trust anchor at the root zone that enables a chain of trust to be built to ensure that responses are trustworthy. Therefore, when planning to use DNSSEC, you need to determine the location for the trust anchors. This also means that the validity of not only individual resource records can be verified, but also the actual server itself can be verified as being the correct authoritative server.

A signed zone contains RRSIG, DNSKEY, and NSEC records in addition to the normal DNS records in that zone. NSEC provides authenticated denial of existence for DNS. Windows Server 2012 supports NSEC and NSEC3, an extended version of the standard. NSEC3 helps to prevent zone enumeration whereby an attacker can send repeated queries across a zone to determine targets.

DNS socket pool

The DNS socket pool enables randomization of queries to prevent cache poisoning attacks. Security update MS08-037 enables this feature by default, and it is enabled by default in Windows Server 2012. The DNS socket pool uses several source ports for issuing queries.

Both the number of source ports to be used and any exclusions or ports not to be used for issuing queries can be configured. Unfortunately, this feature can’t be controlled using the DNS management tool and must instead be configured by using either the dnscmd tool or the registry.

Cache locking

Another method for preventing cache poisoning is with cache locking. Cache locking prevents cached responses from being overwritten during their Time to Live (TTL). Cache locking is configured as a percentage of the TTL. So if the TTL is 3600 seconds, a cache-locking percentage of 50 would prevent the cached value from being overwritten for 1800 seconds, or 50 percent of the TTL. You can configure cache locking by using the CacheLockingPercent registry key or the dmscmd tool.

Disjoint namespaces

A disjoint namespace has a different Active Directory domain and DNS domain suffix. For example, a DNS suffix of corp.adventure-works.com with an Active Directory domain of int.corp.adventure-works.com is in a disjoint namespace. Domain members register resource records in the domain in which they’re members—int.corp.adventure-works.com in the example. The domain controller then registers both global and site-specific service (SRV) records into the DNS domain. The SRV records are also placed in the _msdcs zone.

Disjoint namespaces are used when business rules dictate that namespace separation needs to occur. However, applications to be used in a disjoint namespace should be tested because they may expect that the domain and DNS suffix match and therefore may not work. Disjoint namespaces require additional administration overhead because of the manual processes involved to manage the DNS and Active Directory information.

The following configurations support disjoint namespaces:

• In a multi-domain Active Directory forest with a single DNS namespace or zone
• In a single Active Directory domain that’s split into multiple DNS zones

On the other hand, a disjoint namespace won’t work in the following configurations:

• When a suffix matches an Active Directory domain in the current or another forest
• When a certification authority (CA) domain member changes its DNS suffix

DNS interoperability

Microsoft’s implementation of DNS complies with the relevant DNS-related RFCs, thus making interoperability possible with other servers. The Enable BIND Secondaries check box on the Advanced tab of the DNS server Properties sheet enables the Windows-based DNS server to interact with a server running the BIND name server. Refer to Figure 2-9 for a screenshot of this tab.

Migration to application partitions

Application partitions enable certain data to be replicated along partition lines. Specifically, application partitions assist with control of the replication’s scope—for instance, to enable certain DNS zones to be replicated.

An application partition is created with the dnscmd command-line tool:

dnscmd <ServerName> /CreateDirectoryPartition <Fully Qualified Domain Name>

After the partition is created, servers are enlisted with this command:

dnscmd <ServerName> /EnlistDirectoryPartition <Fully Qualified Domain Name>

After the directory partition is created, you can change zone replication in the Properties sheet for the given zone. On the General tab of the zone’s Properties sheet, you change the replication configuration by clicking Change. Figure 2-10 shows the General tab.

When you click Change, the Change Zone Replication Scope dialog box appears, as in Figure 2-11.

IPv6

Windows Server 2012 supports IPv6 DNS hosting. Address records are known as AAAA in IPv6 rather than the A record for IPv6 DNS hosts. Designing IPv6 DNS typically means a coexistence strategy of some nature whereby both IPv4 and IPv6 DNS is supported on a network.

Windows Internet Name Service (WINS) doesn’t support IPv6, so keep this limitation in mind when planning an IPv6 deployment. You can use an ISATAP router to provide translation services for WINS.

Single-label DNS name resolution

Single-label domains are missing a top-level domain (TLD) and the normal dot (.) notation associated with domain names. For example, a normal domain is adventure-works.com, whereas a single-label domain is adventure-works.

You find single-label names on networks with legacy Windows Internet Name Service (WINS) deployments. However, as WINS is retired, administrators must plan for providing name resolution for older, legacy WINS-based applications and important resources. Windows has a GlobalNames Zone (GNZ) that can be used to provide name resolution for single-label names. GNZ can be deployed in a single forest or across multiple forests to provide static name resolution.

GNZ helps in the transition from WINS to the multi-label standard DNS zones and can therefore be part of a planning strategy for name resolution. You should understand how GNZ varies from domain suffixes and how it has improved performance over multiple domain suffixes in single-label resolution scenarios with several domains. Windows Server 2012 looks first in the GNZ when a single-label resolution query is received. If a record is in the GNZ, it can’t participate in dynamic updates, and dynamic update requests for that record will be refused.

Zone hierarchy and zone delegation

The zone hierarchy is the tree-like structure of DNS, in which the root of the zone is represented by a single dot (.). Up the tree from that root are top-level domains (TLDs) such as .com, .net, and .org. The tree branches out into the private domains that you recognize, like microsoft.com and adventure-works.com.

Zone delegation refers to the ability to respond to queries authoritatively by using a portion of a zone. For example, in the hierarchical nature of DNS, the root servers are responsible for the root of the zone and delegate authority for TLDs to TLD servers who then delegate responsibility for domains such as adventure-works.com to private corporate nameservers. When a query arrives for www.adventure-works.com, the query begins at the root server, which refers the query to the responsible server for the .com TLD, which then refers to the responsible server for the domain being queried.

In much the same way that root servers delegate to TLD servers, which then delegate to corporate nameservers, you can also delegate portions of corporate domains such as adventure-works.com to other nameservers so that they become authoritative for that part of the zone. For example, you may want to create an authoritative zone for corp.adventure-works.com so that queries are sent to a different server for hosts in that domain.

Zone delegation is configured in the DNS Manager by right-clicking the zone to be delegated and then selecting New Delegation. Doing so invokes the New Zone Delegation Wizard so that the portion of the zone, such as the corp subdomain in the corp.adventure-works.com scenario, can be delegated.

Objective summary

• The DNS service supports configurations to enhance security including DNSSEC, DNS socket pool, and cache locking.
• DNS socket pool randomizes the source port for DNS queries, and cache locking prevents cached entries from being overwritten for a certain percentage of their Time to Live (TTL) value.
• Microsoft’s DNS implementation supports disjoint namespaces, in which the DNS name suffix varies from the Active Directory Domain Services (AD DS) domain name suffix.
• Zone delegation enables a different server to be authoritative for a given zone. This, coupled with zone hierarchy and application partitions, enables complex name service architectures for an organization.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. Which of the following are supported disjoint namespace configurations in Windows Server 2012?

   1. When a suffix matches an Active Directory domain in the current or another forest

   2. In a multi–Active Directory domain forest with a single DNS namespace or zone

   3. In a single Active Directory domain that’s split into multiple DNS zones

   4. When a certification authority (CA) domain member changes its DNS suffix

2. Which command creates an application partition?

   1. dnscmd <FQDN> /CreateDirectoryPartition <ServerName>

   2. dnscmd <ServerName> /CreateApplicationPartition <FQDN>

   3. dnscmd <ServerName> /CreateDirectoryPartition <FQDN>

   4. dnscmd <FQDN> /CreateApplicationPartition <ServerName>

3. Which feature of Microsoft’s DNS implementation helps prevent cache poisoning?

   1. DNS socket pool

   2. Cache lock pooling

   3. Cache poisoning prevention

   4. DNS pool randomization

4. You’ve configured cache locking and have received reports that clients are receiving stale DNS query responses. Which registry key do you need to change in order to change the TTL ratio that remains locked?

   1. TTLRatioPercent

   2. CacheResetValue

   3. TTLLockingValue

   4. CacheLockingPercent