XCCC: Instant Messaging Logon Process Takes an Unusually Long Time When Using Additional DNS Server Entries (309668)



The information in this article applies to:

  • Microsoft Exchange 2000 Server

This article was previously published under Q309668

SYMPTOMS

If Exchange 2000 Instant Messaging clients attempt to connect across a virtual private network (VPN) connection, it may take an unusually long amount of time to log on to Instant Messaging.

CAUSE

An Instant Messaging client is most likely to receive Domain Name System (DNS) server entries when the Instant Messaging client gains access to the Internet through the Internet service provider (ISP). After the Instant Messaging client successfully receives these DNS entries, the client initiates a VPN connection to the corporate LAN to log on to the Instant Messaging server. After the VPN connection is established, the Instant Messaging client receives a third DNS server entry.

After an unsuccessful DNS SRV query attempt to the ISP DNS servers, the client receives a response from the internal DNS server, and the logon process proceeds. During this process, the client attempts to subscribe to other Instant Messaging clients. These other Instant Messaging clients are enabled as an address that is similar to "user@im.company.com", which the client attempts to resolve as an RVP record against all three of the defined DNS servers. Because there is no SRV/RVP record in the "_rvp._tcp.im.company.com" DNS zone, all of the DNS SRV/RVP queries fail, but eventually fallback to a standard DNS "A" record lookup. This causes long delays in the logon process; however, the client does eventually log on.

NOTE: If the client is configured with DNS suffix entries, the client also appends each DNS suffix to the DNS SRV/RVP query and submits the appended query to all three of the DNS servers until every attempt has been exhausted.

RESOLUTION

To resolve this behavior, the DNS administrator of the Instant Messaging server's company must add an additional DNS zone to include the zone "im" under the top-level company.com domain. The administrator must create an RVP/SRV DNS record in this "im" zone and set the "Host offering this service" string to the same name that is used in the top-level DNS zone (for example, im.company.com). With this additional zone in place, the client can issue the query and find the record that the client is looking for (for example, im.company.com)

STATUS

This behavior is by design.

Modification Type:MinorLast Reviewed:4/25/2005
Keywords:kbprb KB309668