ADPERF: LDAP connects take longer when targeting fully qualified DNS hostnames

Consider the following scenario:

• LDAP queries serviced by Windows Server 2008 R2 domain controllers may randomly take longer to respond than expected.
  
  
• In cases where domain controllers were upgraded from a previous OS version or where domains contain a mix of OS versions, Windows Server 2008 R2 domain controllers may be slower to service the same LDAP query compared to a Windows Server 2003 or Windows Server 2008 R2 domain controller.
  

Sample administrator, user and applications impacted include but are not limited to:

• LDAP connects that used to complete in less than second against Windows Server 2003 or Windows Server 2008 domain controllers were now taking ~6 seconds when serviced by Windows Server 2008 R2 domain controllers. Subsequent LDAP operations such as bind and LDAP searches appeared to have no additional delay after the initial LDAP connect.
  
  
• The LDIFDE.EXE command with and without the /S parameter is slow .
  
  
• Microsoft System Center Active Directory Management Pack (SCOM ADMP) health check script AD_General_Response.vbs.
  
  
• Microsoft Active Directory Users and Computers (ADUC) is slow to start or slow to open OU container
  
  Extensions in the Active Directory Users and Computers snap-in, DSA.MSC, uses the DC FQDN computer name as a domain name.
  
  
• Microsoft Active Directory Administrative Center (ADAC)
  
  Extensions in the Active Directory Administrative Center uses the DC FQDN computer name as a domain name.
  
  
• VBS scripts that make LDAP calls that reference the DCs fully qualified DNS name are slow to execute.

Windows 7 / Windows Server 2008 R2 introduced a name lookup behavior change to fix two broken scenarios:

1. LDAP clients would fall back to NTLM whenever the NetBIOS domain name was supplied as the hostname in the LDAP connection.
   
   AND
   
   
2. LDAP clients would fail to connect to a DC in the domain if a client had the same name as the targeted NetBIOS domain name.
   

The delay is introduced by the wait time for a broadcast response. You will not see this delay if NetBt name resolution through broadcasts is turned off.

The delays can be observed in a network trace which shows Windows 7 and Windows Server 2008 R2 LDAP clients performing NetBIOS name lookups for a [HOSTNAME]<0x1C> record prior to performing a DNS lookup to locate the application host computer (see Figure A.).

Figure A.



The network trace of a Windows Server 2003 LDAP client showed that it directly performed the DNS lookup for the host computer without performing the NetBIOS lookup for the <0x1C> record.

Figure B.

When targeting an LDAP server by hostname versus domain name, you should use the LDAP_OPT_AREC_EXCLUSIVE session option to indicate that the target is a hostname instead of a domain.

This option is set differently depending on the programming interface being used:

Wldap32:

If an Active Directory DNS server name is passed for the HostName parameter, then ldap_set_option should be called to set the LDAP_OPT_AREC_EXCLUSIVE flag before calling any LDAP function that creates the actual connection. This forces an A-record lookup and bypasses any SRV record lookup when resolving the host name. In the case of a branch office with a dial-up connection, using A-Record lookup can avoid forcing the dialup to query a remote DNS server for SRV records when resolving names.

ADSI:

If you must specify a server, use the ADS_SERVER_BIND flag to avoid unnecessary or incorrect queries to the DNS server. For more information, see the Knowledge Base article ADsOpenObject(), ADsGetObject(), OpenDSObject() Functions May Generate Incorrect DNS Queries.

System.DirectoryServices:

If your ADsPath includes a server name, specify the AuthenticationTypes.ServerBind flag when using the LDAP provider. Do not use this flag for paths that include a domain name or for serverless paths. Specifying a server name without also specifying this flag results in unnecessary network traffic.

Example:
DirectoryEntry ent = new DirectoryEntry("LDAP://server01",null,null,AuthenticationTypes.ServerBind);

The new default behavior in Windows 7 and Windows Server 2008 R2 can be reverted to pre-Windows 7 behavior. This may re-introduce problems with NETBIOS names as described in the CAUSE section. However there are also scenarios where the Pre-Windows 7 behavior provides better results. So it depends on what the main LDAP client use scenario is on what setting will produce the better results.

The long-term solution should always be to get the application to use server and domain names with the proper flags when calling into LDAP, ADSI or .Net interfaces. Using the correct flags makes the application independent from scenario dependencies when the directory services client code needs to decide the resolution method in ambiguous situations. The registry path, entry and value is shown below:

Subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP
Entry: UseOldHostResolutionOrder
Type: REG_DWORD
Value data: 1

As an additional approach you can look at turning off name resolution through broadcast for NetBt. This would be NodeType "p-mode" according to:

819108 Settings for minimizing periodic WAN traffic
http://support.microsoft.com/kb/819108/EN-US

Explanation of the mode:

Use 0x00000008 for hybrid node or h-node
Use 0x00000004 for mixed node or m-node
Use 0x00000002 for point-to-point WINS or p-node
Use 0x00000001 for broadcast node or b-node
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Name Resolution Nodes
B-Node (broadcast) - uses broadcasts to resolve names (not recommended for larger networks)
P-Node (peer to peer) - uses WINS only, no broadcasts. No WINS server, no resolution.
M-Node (mixed) - Broadcast first, then WINS. (not recommended as you want to minimize broadcasts)
H-Node (hybrid) - uses WINS first, then broadcast. (recommended as it cuts down broadcasts by trying WINS first but will resort to broadcast as last resort.)

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.