Windows Server 2003 : TCP/IP for AD Transport, Access, and Support (part 1) - AD/DNS Dependencies, How AD Uses DNS

3/12/2013 7:15:20 PM

An AD forest relies on TCP/IP for communications between member computers, between domain controllers, and between member computers and domain controllers. DNS provides name resolution and assists in the location of domain services through the use of SRV records. All of the benefits of AD (such as the centralized authentication database, computer management through Group Policy, and the centralization of multiple services) will not be available if DNS is incorrectly configured. Other TCP/IP-based protocols (such as the Windows Time Service, DHCP, and SMTP) are also important components.

This section discusses how TCP/IP relates to AD transport, access, and support. Here we will examine dependencies between AD and DNS, how to configure DNS for AD, how to use Windows Server 2003 AD application partitions to manage DNS Zone information, how AD uses DNS, how to configure the Windows Time Service, how to integrate DHCP with AD, and how NetBIOS and WINS are used in an AD domain. This is a long section, but critically important to AD administration. The most important subsection (the one that discusses dependencies between AD and DNS) is covered first because AD malfunction is often the result of DNS problems.

1. AD/DNS Dependencies

The interdependency between AD and DNS involves the following AD components:

Domain controller locator

This is implemented in the NetLogon service and enables clients to locate a DC.

AD domain names in DNS

Each domain has a DNS domain name. Every Windows Server 2003 server has a DNS name.

DNS delegation resource records

These reside in the parent zone of the zone that is delegated (that is, the zone that supports the AD domain).

DNS forwards

These are used by AD clients in one domain to locate a DC in another domain.

AD DNS objects

Domains are represented as objects in AD and as nodes in DNS. DNS domain names and AD domain names appear to be the same. However, they represent two different namespaces. While DNS resolves domain names and computer names to resource records and eventually to IP addresses, AD resolves domain object names to object records. An AD object name and a DNS host record can, however, represent the same computer.

To troubleshoot problems with logon, replication, Group Policy, and other domain activities, you should be familiar with how DNS and its SRV records are used.

For domain resources to be located on the network, they must be registered with appropriate name services. DNS registration must occur either dynamically or manually. If the Windows domain is configured for dynamic updates, it follows the standard described in RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE).

When a Windows Server 2003 DC starts, several processes interact with a DNS and/or WINS name server(s), including DNS name registration, DNS host record creation, and LDAP lookup. First, the DC registers its name with any name services configured for the network. For example, let's say that the domain controller regalinn is in the domain chicago.local, where both DNS and Windows Internet Name Service (WINS) services are configured. This DC registers its DNS name regalinn.chicago.local with DNS and its NetBIOS name, regalinn with WINS. If other, third-party name services are configured for the network and the DC is properly configured, the DC can also register its name in the appropriate format with that name service. When a workstation or server starts, in order to find its DC, it must use the name services (DNS, WINS) provided to locate the DC on the network. Once it finds the DC, the information is cached for later use.

Domain name registration in WINS (the creation of a domain_name[1C] record) occurs by broadcast, or by directing a NetBIOS name registration request to the NetBIOS name server. Windows clients that are not DNS-enabled can use WINS to find Windows Server 2003, Windows 2000, and Windows NT 4.0 domain controllers.

In addition to name registration, the NetLogon service on the DC dynamically creates the host or A record (server name and IP address) and SRV records in DNS. SRV records identify the services that the DC provides (such as LDAP, Kerberos, TCP, and, if the DC is a GC, that record as well).

Finally, the _msdcs.dnsdomainname is used to find an LDAP server that is running TCP and is performing a specific server role (such as domain controller or Kerberos server). Finding these servers is important to domain and forest operations such as authentication, resource location, replication, and so on.

Configuring DNS to properly interact with AD is important because if it is not, these functions (as well as others that are based on them) cannot occur. It is possible to correctly configure DNS so that it functions as a name server on your network and still not have it correctly configured so that AD can work correctly. Your DNS administrator must understand AD's requirements and correctly configure DNS for AD.

2. How AD Uses DNS

As shown in Table 1, there are multiple listings of SRV records for each service offered by AD DCs. Each SRV record can be found in multiple containers. This provides multiple options for locating specific DCs in the forest. This section explains the ways these records are used, including the following:

  • How DCs are located

  • How site information is used during logon

  • How DNS is used for AD replication

Table 1. SRV records used in AD
SRV recordDescription
_kerberosIndicates the location of a Key Distribution Center (KDC)
_kpasswdIndicates the location where password changes are recorded
_ldapIndicates the location of an LDAP server
_gcIndicates the location of a global catalog (GC) server

2.1. How DCs are located

When member computers boot, when users log on, or when replication initiates, a DC must be located. Let's look at how the process works when locating a DC using DNS. (A similar process is used by legacy Windows clients to locate a DC via WINS.)

On the client, a remote procedure call (RPC) is made to the local NetLogon service. The NetLogon service implements the Locator API (DsGetDcName). The client collects information needed to select a DC and provides it to the NetLogon service using DsGetDcName. (For example, the user's credentials entered during logon specify the domain in which his or her account resides.) The NetLogon service queries DNS by using the DNS-compatible LocatorDsGetDcNme to obtain the SRV records and A records from DNS.

The NetLogon service queries the discovered DCs using an LDAP UDP search. The search attempts to find a DC in the site closest to the client. In an AD domain, the site information in DNS is used to aid in this discovery. Site information is included in many places in DNS so that a search for the different roles that a DC may play all can be located in the closest site.

Available DCs respond. NetLogon services returns information to the client from the first DC to respond. The NetLogon service caches the discovered DC information for use in future requests.

2.2. How site information is used during logon

During logon, NetLogon attempts to find a DC in the site closest to the client. While site information for DCs is included in the DNS SRV records, site information of clients is stored in the client's registry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName value. This information is used to aid in the selection of a DC in the site closest to it. When the computer is located in the site that is recorded in the registry, the NetLogon query quickly locates a DC from this site (or one that is close to it). However, the NetLogon service on the DC uses the client's IP address to determine its site and returns this information to the client. If the two sites (the client registry site and the DC calculated site) do not match, then additional DC queries and even additional DNS queries may result.

When site information doesn't match, it is usually because the computer has been moved into another site. (A laptop, for example, may be moved from location to location. Its registry-based site information may then easily be out of date.) This is why the site information in the DynamicSiteName value in the registry is not used alone. During NetLogon startup, the NetLogon service on each DC enumerates the site object in the AD Configuration container and NetLogon is also notified of any changes to Site objects. This information is used by NetLogon to create (in the DC's memory) a subnet-to-site mapping table.

The client receives DC IP address information from DNS and queries each DC in turn to find out which ones are available. AD on the DC intercepts the query and passes it to NetLogon on the DC. NetLogon on the DC takes the client IP address (included in the query) and looks it up in its subnet-to-site mapping table. The DC then returns information to the client, including the name of the site of the client, the site name of the DC, and an indication of whether it (the DC) is located in the site closest to the client.

The client uses this information to determine whether to try to find a better DC:

  • If the DC is located in the site closest to the client, then this DC is used.

  • If no DC is in the site closest to the client, but the client has already tried to find a DC in the site the DC says the client is in, the client uses the current DC.

  • If the DC is not in the site closest to the client and the client has not looked for a DC in that site, the client updates its site information and sends a new DNS query. If this one is not successful, then the original DC is used.

You can override the DyanmicSiteName value, but you should do so by modifying the SiteName entry at the same location. When the SiteName value is used, the DynamicSiteName value is disregarded.

2.3. How DNS is used for AD replication

Replication topologies are configured both automatically and manually, and the information is stored in AD. These records assist replication partners in locating each other and in mutual authentication. However, the actual location requires more than a simple DNS lookup.

The DC finds its partner's GUID in AD. (A listing of GUIDs for each DC is at CN=NTDS Settings, CN=Sites, CN=Configuration, DC=domain_name, DC=domain_name_extension.) The DC queries DNS looking for an associated CNAME record. The CNAME record is of the form guid.msdcs.forest.root, as shown in Figure 1.

Figure 1. DC GUIDs are recorded in DNS to assist the location of replication partners

If the query is successful, the name of the DC is returned. A second DNS query is used to obtain the host record. The IP address from the host record is used to request a connection to the replication partner. If CNAME or host record is missing from DNS, a connection cannot be made and replication will not occur.

  •  HP Envy X2 Review - A Hybrid Tablet-Laptop Failing To Bring Up A Complete Package (Part 2)
  •  HP Envy X2 Review - A Hybrid Tablet-Laptop Failing To Bring Up A Complete Package (Part 1)
  •  Windows 7 : Designing a Client Hardware Platform (part 2) - Boot from VHD
  •  Windows 7 : Designing a Client Hardware Platform (part 1)
  •  Windows 7 : Designing and Managing a Licensing Strategy (part 1) - Volume Licensing Activation Methods
  •  How To Transfer Data From SSD To HDD
  •  9 Interesting Apps For Windows 8
  •  Windows Server 2003 : Moving from Workgroups to Domain Environments (part 3) - Moving Operations Master Roles, Back Up AD
  •  Windows Server 2003 : Moving from Workgroups to Domain Environments (part 2) - Configuring Sites
  •  Windows Server 2003 : Moving from Workgroups to Domain Environments (part 1) - Using dcpromo, Confirming DNS Registration of DC Information
    Top 10
    SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
    The latest Audi TT : New angles for TT
    Era of million-dollar luxury cars
    Game Review : Hearthstone - Blackrock Mountain
    Game Review : Battlefield Hardline
    Google Chromecast
    Keyboards for Apple iPad Air 2 (part 3) - Logitech Ultrathin Keyboard Cover for iPad Air 2
    Keyboards for Apple iPad Air 2 (part 2) - Zagg Slim Book for iPad Air 2
    Keyboards for Apple iPad Air 2 (part 1) - Belkin Qode Ultimate Pro Keyboard Case for iPad Air 2
    Michael Kors Designs Stylish Tech Products for Women
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    Popular Tags
    Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Exchange Server Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe Photoshop CorelDRAW X5 CorelDraw 10 windows Phone 7 windows Phone 8 Iphone