2.In the Reconcile dialog box, tap or click Verify.
3.Inconsistencies are reported in the status window. Select the displayed addresses, and then tap or click Reconcile to repair inconsistencies.
4.If no inconsistencies are found, tap or click OK.
To reconcile all scopes on a server, follow these steps:
1.In the DHCP console, expand the server entry, press and hold or right-click the IPv4 node, and then tap or click Reconcile All Scopes.
2.In the Reconcile All Scopes dialog box, tap or click Verify.
3.Inconsistencies are reported in the status window. Select the displayed addresses, and then tap or click Reconcile to repair inconsistencies.
4.If no inconsistencies are found, tap or click OK.

CHAPTER 9: Optimizing DNS
■Understanding DNS
■Configuring name resolution on DNS clients
■Installing DNS servers
■Managing DNS servers
■Managing DNS records
■Updating zone properties and the SOA record
■Managing DNS server configuration and security
This chapter discusses the techniques you use to set up and manage Domain Name System (DNS) on a network. DNS is a name-resolution service that resolves computer names to IP addresses. When you use DNS, a fully qualified host name-omega.microsoft.com, for example-can be resolved to an IP address, which enables computers to find one another. DNS operates over the TCP/IP protocol stack and can be integrated with Windows Internet Name Service (WINS), Dynamic Host Configuration Protocol (DHCP), and Active Directory Domain Services (AD DS). Fully integrating DNS with these Windows networking features enables you to optimize DNS for Windows Server domains.
DNS organizes groups of computers into domains. These domains are organized into a hierarchical structure that can be defined on an Internet-wide basis for public networks or on an enterprise-wide basis for private networks (also known as extranets and intranets , respectively). The various levels within the hierarchy identify individual computers, organizational domains, and top-level domains. For the fully qualified host name omega.microsoft.com, omega represents the host name for an individual computer, microsoft is the organizational domain, and com is the top-level domain.
Top-level domains are at the root of the DNS hierarchy and are also called root domains . These domains are organized geographically, by organization type, and by function. Typical corporate domains, such as microsoft.com, are also referred to as parent domains because they’re the parents of an organizational structure. You can divide parent domains into subdomains you can use for groups or departments within your organization.
Subdomains are often referred to as child domains . For example, the fully qualified domain name (FQDN) for a computer within a human resources group could be designated as jacob.hr.microsoft.com. Here, jacob is the host name, hr is the child domain, and microsoft.com is the parent domain.
Integrating Active Directory and DNS
Active Directory domains use DNS to implement their naming structure and hierarchy. Active Directory and DNS are tightly integrated, so much so that you should install DNS on the network before you can install Active Directory Domain Services.
During installation of the first domain controller on an Active Directory network, you have the opportunity to automatically install DNS if a DNS server can’t be found on the network. You can also specify whether DNS and Active Directory should be integrated fully. In most cases, you should respond affirmatively to both requests.
With full integration, DNS information is stored directly in Active Directory, which enables you to take advantage of Active Directory’s capabilities.
Understanding the difference between partial integration and full integration is very important:
■ Partial integrationWith partial integration, the domain uses standard file storage. DNS information is stored in text-based files that end with the.dns extension. The default location of these files is %SystemRoot%\System32\Dns. Updates to DNS are handled through a single authoritative DNS server. This server is designated as the primary DNS server for the particular domain or an area within a domain called a zone . Clients that use dynamic DNS updates through DHCP must be configured to use the primary DNS server in the zone. If they aren’t, their DNS information won’t be updated. Likewise, dynamic updates through DHCP can’t be made if the primary DNS server is offline.
■ Full integrationWith full integration, the domain uses directory-integrated storage. DNS information is stored directly in Active Directory and is available through the container for the dnsZone object. Because the information is part of Active Directory, any domain controller can access the data, and you can use a multimaster approach for dynamic updates through DHCP. This enables any domain controller running the DNS Server service to handle dynamic updates. Furthermore, clients that use dynamic DNS updates through DHCP can use any DNS server within the zone. An added benefit of directory integration is the ability to use directory security to control access to DNS information.
If you look at the way DNS information is replicated throughout the network, you will find more advantages to full integration with Active Directory. With partial integration, DNS information is stored and replicated separately from Active Directory. By having two separate structures, you reduce the effectiveness of both DNS and Active Directory and make administration more complex. Because DNS is less efficient than Active Directory at replicating changes, you might also increase network traffic and the amount of time required to replicate DNS changes throughout the network.
In early releases of the DNS Server service for Windows servers, restarting a DNS server could take an hour or more in large organizations with extremely large AD DS-integrated zones. The operation took this much time because the zone data was loaded in the foreground while the server was starting the DNS service. To ensure that DNS servers can be responsive after a restart, the DNS Server service for Windows Server 2008 R2 and later has been enhanced to load zone data from AD DS in the background while the service restarts. This ensures that the DNS server is responsive and can handle requests for data from other zones.
At startup, DNS servers running Windows Server 2008 R2 and later perform the following tasks:
■Enumerate all zones to be loaded.
■Load root hints from files or AD DS storage.
■Load all zones that are stored in files rather than in AD DS.
■Begin responding to queries and Remote Procedure Calls (RPCs).
■Create one or more threads to load the zones that are stored in AD DS.
Because separate threads load zone data, the DNS server is able to respond to queries while zone loading is in progress. If a DNS client performs a query for a host in a zone that has already been loaded, the DNS server responds appropriately. If the query is for a host that has not yet been loaded into memory, the DNS server reads the host’s data from AD DS and updates its record list accordingly.
Читать дальше