Windows Server 2008 R2 Unleashed (63 page)

server. If the IP address of that server changed, the DNS server updated its own entry in

ptg

DNS, but then other DNS servers within the domain were unable to successfully retrieve

updates from the original server because they were requesting from the old IP address.

This effectively left the original DNS server in an “island” by itself, hence the term.

Microsoft DNS fixed this problem in Windows Server 2003 and above. Windows Server

2008 R2 DNS first changes its host records on a sufficient number of other authoritative

servers within DNS so that the IP changes made will be successfully replicated, thus elimi-

nating this “island” problem. As a result, it is no longer necessary to point a root DNS

server to another DNS server for updates, as was previously recommended as a method of

resolving this issue.

Forest Root Zone for _msdcs

In Active Directory, all client logons and lookups are directed to local domain controllers

and global catalog servers through references to the SRV records in DNS. These SRV

records were stored in a subdomain to an Active Directory domain that is known as the

_msdcs subdomain.

10

In Windows Server 2008 R2, _msdcs is a separate zone in DNS, as shown in Figure 10.14.

This zone, stored in the application partition, is replicated to every domain controller that

is a DNS server. This listing of SRV records was moved mainly to satisfy the requirements

of remote sites. In Windows 2000, these remote sites had to replicate the entire DNS data-

base locally to access the _msdcs records, which led to increased replication time and

288

CHAPTER 10

Domain Name System and IPv6

reduced responsiveness. If you delegate the SRV records to their own zone, only this

specific zone can be designated for replication to remote site DNS servers, saving replica-

tion throughput and increasing the response time for clients.

ptg

FIGURE 10.14

_msdcs zone.

DNS in an Active Directory Domain Services

Environment

DNS is inseparable from Active Directory. In fact, the two are often confused for one

another because of the similarities in their logical structures.

Active Directory uses a hierarchical X.500-based structure that was designed to map into

the DNS hierarchy, hence the similarities. In addition, Active Directory utilizes DNS for all

internal lookups, from client logons to global catalog lookups. Subsequently, strong

consideration into how DNS integrates with Active Directory is required for those consid-

ering deploying or upgrading AD.

The Impact of DNS on Active Directory Domain Services

Problems with DNS can spell disaster for an Active Directory environment. Because all

servers and clients are constantly performing lookups on one another, a break in name-

resolution service can severely affect Active Directory functionality.

For this and other reasons, installing a redundant DNS infrastructure in any Active

Directory Domain Services implementation is strongly recommended. Even smaller envi-

DNS in an Active Directory Domain Services Environment

289

ronments should consider duplication of the primary DNS zone, and nearly as much

emphasis as is put into protecting the global catalog AD index should be put into

protecting DNS.

Security considerations for the DNS database should not be taken for granted. Secure

updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a

domain controller can also help to secure DNS (see previous sections of this chapter for

more details on this concept). In addition, limiting administrative access to DNS will help

to mitigate problems with unauthorized “monkeying around” with DNS.

Active Directory Domain Services in Non-Microsoft DNS

Implementations

Active Directory Domain Services was specifically written to be able to coexist and, in fact,

utilize a non-Microsoft DNS implementation as long as that implementation supports

dynamic updates and SRV records. For example, AD will function in all versions of UNIX

BIND 8.1.2 or higher. With this point in mind, however, it is still recommended that an

organization with a significant investment in Microsoft technologies consider hosting

Active Directory DNS on Windows Server 2008 R2 systems because functionality and secu-

rity enhancements provide for the best fit in these situations.

For environments that use older versions of DNS or are not able (or willing) to host Active

ptg

Directory clients directly in their databases, Active Directory DNS can simply be delegated

to a separate zone in which it can be authoritative. The Windows Server 2008 R2 systems

can simply set up forwarders to the foreign DNS implementations to provide for resolu-

tion of resources in the original zone.

Using Secondary Zones in an AD DS Environment

Certain situations in Active Directory require the use of secondary zones to handle specific

name resolution. For example, in peer-root domain models, where two separate trees form

different namespaces within the same forest, secondaries of each DNS root were required

in Windows 2000 to maintain proper forestwide synchronization.

Because each tree in a peer-root model is composed of independent domains that might

not have security privileges in the other domains, a mechanism will need to be in place to

allow for lookups to occur between the two trees. The creation of secondary zones in each

DNS environment will provide a solution to this scenario, as illustrated in Figure 10.15.

Windows Server 2008 R2 now has the option of replicating these separate trees to all DNS

servers in the forest, reducing the need for secondary zones. Replicating secondary zones

10

outside of a forest is still sometimes necessary, however. Conditional forwarding and stub

zones can also be used in certain cases to achieve a similar result without the need for data

replication.

SRV Records and Site Resolution

All Active Directory Domain Services clients use DNS for any type of domain-based

lookups. Logons, for example, require lookups into the Active Directory for specific SRV

records that indicate the location of domain controllers and global catalog servers.

290

CHAPTER 10

Domain Name System and IPv6

CompanyABC’s AD Forest

abcroot.local

companyabc.com

Domain DNS

Domain DNS

Server

Server

abcroot.local

companyabc.com

AD-Integrated

Zone

AD-Integrated

Zone

Transfers

Zone

companyabc.com

abcroot.local

Secondary

Secondary

Zone

Zone

ptg

FIGURE 10.15

Peer-root domain DNS secondary zones.

Windows Server 2008 R2, as previously mentioned, divides the location of the SRV

records into a separate zone, which is replicated to all domain controllers that have DNS

installed on them.

Subdomains for each site are created in this zone; they indicate which resource is available

in those specific sites, as shown in Figure 10.16. In a nutshell, if an SRV record in the

specific site subdomain is incorrect, or another server from a different site is listed, all

clients in that site are forced to authenticate in other sites. This concept is important

because a common problem is that when Active Directory sites are created before they are

populated with servers, an SRV record from the hub location is added to that site subdo-

main in DNS. When a new server is added to those sites, their SRV records join the other

SRV records that were placed there when the site was created. These records are not auto-

matically deleted, and they consequently direct clients to servers across slow wide area

network (WAN) links, often making logon times very slow.

In addition to the site containers, the root of these containers contains a list of all domain

controllers in a specific domain. These lists are used for name resolution when a particular

site server does not respond. If a site domain controller is down, clients randomly choose

a domain controller in this site.

DNS in an Active Directory Domain Services Environment

291

FIGURE 10.16

Site-level SRV records.

ptg

GlobalNames Zone

In some cases, using a fully qualified domain name (FQDN) is not convenient for the end

users. This is especially true for novice users or in the case of very long domain names. A

user entering the uniform resource locator (URL) http://intranet.convergentcomputing.

com is quite likely to make a mistake in the typing. The WINS name resolution provides

relief from this, in that single-label names can be used instead. This allows the user to type

the URL http://intranet and still reach the desired resource.

However, with the advent of IPv6, WINS will no longer be supported as the new address-

ing is deployed throughout the organization. There are also many advantages of DNS over

WINS, including reducing administrative overhead, single name resolution repository,

security, and open standards.

Windows Server 2008 R2 provides a feature that was introduced in Windows Server 2008

to address this problem, specifically the GlobalNames zone (GNZ). This zone provides

single-label name resolution via a DNS zone, similar to WINS. The zone is a normal

forward lookup zone, albeit with a special name (GlobalNames), and is used by the DNS

10

server in a special way. If the DNS server is unable to resolve an address in its local zones,

it will then resolve the single-label address against the GlobalNames zone.

The GNZ holds out the promise of finally doing away with WINS and NetBIOS naming.

292

CHAPTER 10

Domain Name System and IPv6

To configure the GlobalNames zone, execute the following steps:

1. Launch Server Manager.

2. Expand the Roles, DNS Server, and DNS nodes, and then select the server name.

3. Select the Forward Lookup Zones node.

4. Select Action, New Zone.

5. Click Next on the Welcome page.

6. Select Primary Zone and make sure that the Store the Zone in Active Directory check

box is checked. Click Next.

7. Select To All DNS Servers in This Forest, and click Next.

8. Enter the Zone name GlobalNames and click Next.

9. Leave the default Dynamic Update setting and click Next.

10. Click Finish to create the zone.

11. Open a command prompt and enter the command dnscmd /config

/EnableGlobalNamesSupport 1. The message “Registry property

EnableGlobalNamesSupport successfully reset” should be returned. This command

must be run on each DNS server that is expected to resolve GlobalNames, regardless

of if the zone is replicated to them already.

ptg

Now the GlobalNames zone is ready to respond to queries. For any server that needs to

respond to single-label queries, enter a CNAME record in the GlobalNames zone with the

appropriate FQDN for the resource. The DNS server will try the GlobalNames zone after

trying other local zones.

Troubleshooting DNS

Much has been written about the complexity of DNS, and even more confusion and

misconceptions have been written about it. In truth, however, DNS structure is logical, so

you can easily troubleshoot it, if you use the proper tools and techniques. A good grasp