Cisco Jabber SRV Records: Being a Knowledgeable & Helpful Collaboration Engineer

If you’ve deployed Cisco’s IM & Presence (formerly Cisco Unified Presence or CUPS) and its associated Jabber product line, you know all about DNS SRV records, or at least you should.
If you don’t know about them or if you are a little rusty, Cisco has a good document (link below) that you should get to know intimately…
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html

SRV records allow servers to advertise service locations within the core of the DNS architecture. For example: _cuplogin._tcp.example.com is an SRV record the Jabber looks for during service discovery and sign-in. The record above points at the IM & Presence service across port 8443 which happens to be what Jabber/IM&P uses for authentication. There are SRV records that Jabber looks for for directory services as well as Collaboration Edge (Cisco Expressway) which is its own animal.

Without SRV records flexible Jabber deployment becomes difficult and Collaboration Edge integration becomes next to impossible.

So we know that SRV records are important, but are they really our problem as Collaboration Engineers? I guess that depends on how broad your IT shop or your customer’s IT shop is. You may have, at your disposal, wonderful Server Engineers who know DNS like you know Call Manager, but not every situation is that clean.

I realize that not every enterprise uses Windows for internal DNS, but since the majority seem to, we’ll cover Windows DNS. My system is a 2008 Server Standard instance.

– What SRV records do we need to add? Cisco gives us a good run down in the document referenced above, I copied the below passage from that document.

The following is an example of the _cisco-uds SRV record:
_cisco-uds._tcp.example.com 
priority       = 1
weight         = 5
port           = 8443
svr hostname   = cucm1.example.com

The following is an example of the _cuplogin SRV record:
_cuplogin._tcp.example.com
priority       = 5
weight         = 100
port           = 8443
svr hostname   = cup1.example.com

**There are additional records required for Collaboration Edge**

In the outputs above, you’ll see the SRV record and its priority, weight, port  and host the has the service. You’ll notice in the SRV record itself that TCP is called out. If these were UDP SRV records you would of course see UDP in the SRV.

– How does this translate to Windows DNS? Pretty easily actually…

Below is the DNS Manager screen from my server.

                     

You’ll see that under my domain’s Forward Lookup Zones there are several folder entries including _tcp, _udp, and others.

If you right click on the domain (image below)  you’ll able to add Other New Records and from here you can select SRV records

Once you select your SRV record type you can begin configuring the SRV record (shown below)

Once you fill in the particulars and click OK, you’ll see your record(s) under the _tcp organizational folder (shown below)

From there, repeat the process to add the other records that you need.

We haven’t really talked about priority and weight and they do exactly what you might expect them to do. Multiple systems can respond to the same SRV record within the same DNS domain. Like anything else, someone has to be first. Assigning a priority and a weight allows you to both build redundancy and load balance across multiple hosts. For instance if you have a CUCM PUB and a SUB, you may be want the SUB to respond first and thus would give it a higher priority for its _cisco-uds record.

In closing, you may never need to know how to add SRV records but if you do, hopefully you’ll remember this post and be successful in your deployment.

-Justin