Jabber for Windows with multiple DNS servers

[Ingo de Jager]

Hi All,

I have a strange scenario where we have multiple DNS/LDAP servers over a large geographical area but we have one centralised CUCM/CUP cluster. Testing Jabber 11.6+ I've found that on first login it does a DNS A record lookup for the domain and the reply contains the 30 odd servers we have. Looking at a packet trace it seems Jabber goes to each and everyone of these servers and does 'something', either just a check to see if it's alive or perhaps even a _ldap SRV lookup to build it's cache and download all my contact photos and information.

The problem I face is that one of these DNS/LDAP servers is at a remote site with low(ish) bandwidth and also firewalled. This remote DNS/LDAP server pair is there to keep traffic local and not have one server at one end serve a client at the other extreme end of the network. According to the DNS guys they call it DNS affinity or something.

Ok, so Jabber now connects to each and everyone of the servers and can't connect to this firewalled DNS/LDAP server and then things grind to a halt. Contact pictures come through one at a time and very slowly and directory searches are extremely slow. My guess is that it somehow wants to connect to this remote DNS/LDAP server but either can't or is very slow.

Just for info, all DNS/LDAP servers are fully meshed and replicated and they all have the exact same information.

Does anyone know why if Jabber 11.6+ use the DNS Affinity the guys mentioned and if it's possible to force Jabber to keep traffic and queries local to the closest DNS/LDAP server pair?

Btw. We are running Jabber for Windows 11.5(3) and it works perfectly, it's just when we test 11.6+ in preparation for an imminent upgrade that we found this.

Thanks,

Ingo

[Jaime Valencia]

If you're using the default EDI integration and just depending on the SRV records to find your LDAP server, Jabber should use the records according to the weight and priority. You can just bypass that by configuring the LDAP server in CUCM, and assigning it to the right Jabber clients via their service profile.

If every single Jabber in the network, gets the same SRV records, I don't see how they they have this "affinity" working (which doesn't even seem to be a term, just googled DNS affinity as I have not heard it before). In order to do that, you would actually require split horizon DNS.

[Ingo de Jager]

Yes, all the servers have the same weight and priority. I have a jabber-config.xml file that has Primary and Secondary servers specified but what I read in the documentation it's only used if the clients cannot find the services by using SRVs. This tells me that no matter what I configure it will not be used if SRVs exist in the DNS.

I am not an AD person so don't really know the correct terms but try "LDAP Site-Affinity" which is probably what the guy tried to explain to me. LDAP and DNS runs on the same server hence me calling it DNS Affinity.

[Jaime Valencia]

If all the servers have all the same weight and priority, and if you do a SRV lookup, you get all of them, from anywhere in the network, there's no way Jabber (or anything else that uses those SRVs) will use the closest one to them just because, it would become a round robin. If you want to make sure they only use the closest LDAP, then that's done with split horizon DNS.

The configuration has precedence over the SRVs which are used by default

Configure Cisco Jabber to connect to a directory server using a service profile or using parameters in the jabber-config.xml file. Cisco Jabber for Windows connects to a Global Catalog server by default and this is the recommended method for Cisco Jabber for Windows, you do not need to configure Cisco Jabber for Windows to connect to the directory.

[Ingo de Jager]

The following is an extract from the reference guide and its a bit confusing. Could you shed some more light on the following in bold. I am under the impression that if the client can indeed discover the directory server automatically then this entry will be ignored.

PrimaryServerName

Required parameter. Specifies the address of the primary directory server. You can configure this parameter to enable manual connection where the client cannot automatically discover the directory server.

Note

The client attempts to connect to the primary directory server or the secondary directory server in the following ways: When the client starts, it attempts to connect to the primary server. The client attempts to connect to the secondary server when: The primary server is not available. The primary server fails after the client connects to it. If the connection to the secondary server is successful, the client retains the connection to the secondary server until the next restart. If the secondary server fails while the client is connected to it, the client attempts to connect to the primary server.

• IP address — Use IP address for primary directory server.

• FQDN — Use FQDN for primary directory server.

Example: <PrimaryServerName>www.example.com</PrimaryServerName>

I've done some more reading and packet traces on this and it seems that when Jabber does a LDAP query for my user attributes the LDAP server reply with a list of 'DNS application partitions'. In these are all the servers listed and the partition right at the top of the list is the one to the furthest/slowest server pair. I am now speaking to a DNS/LDAP guy to see if we can manipulate the LDAP response so that a 'closer' application partition is at the top of the list.

This is getting very interesting and I will post more info as things develop.