XMPP Server Discovery via DNS

The XMPP adapter has functionality that allows the adapter to find the client XMPP domain automatically. These instructions show three different configurations: a simple configuration with a single XMPP host, an example using multiple legacy DNS domains, and XMPP with Jabber already deployed.

Requirements for the XMPP Adapter

This functionality was built with the following requirements:

.

See rfc6120 for a description of how XMPP finds the actual host based on an XMPP domain. The XMPP adapter will stop searching for the XMPP domain under the following circumstances:

  1. If an XMPP domain has already been discovered and previously used by the client, the adapter will use that domain.
  2. For each DNS search domain configured on the device
    1. Check the DNS CNAME records for autodiscovervcxmpp.
    2. If a match is found use the alias returned by the CNAME record as the XMPP domain.
    3. If no match is found, try the next domain in the list.
  3. For each DNS search domain configured on the device.
    1. Check for DNS SRV records for _xmpp-client._tcp.vcxmpp.
    2. If a match is found use vcxmpp.search domain where search domain is the search domain being tested as the XMPP domain.
    3. If no match is found, try the next domain in the list.
  4. For each DNS search domain configured on the device.
    1. Check for DNS SRV records for _xmpp-client._tcp.
    2. If a match is found use the domain being tested as the XMPP domain.
    3. If no match is found, try the next domain in the list.

Example 1: Simple

A hospital site with domain hospital.net is deploying Vocera Platform 6.1. They decide to deploy the XMPP host on foo.hospital.net and want to use hospital.net as their domain name. They do not have another XMPP root level deployment and are not doing federation.

_xmpp-client._tcp.hospital.net. 18000 IN SRV 0 0 5222 foo.hospital.net. 

When the Unified Client starts it discovers that it does not know of a valid XMPP domain. It doesn't find any CNAME records so it continues. It finds hospital.net in the search domains and looks for a SRV record for _xmpp-client._tcp.vcxmpp.hospital.net. It does not find a record. There are no more search domains so now it tries _xmpp-client._tcp.hospital.net. It gets the above SRV record. This is sufficient for the algorithm to stop and use hospital.net as the XMPP domain.

When the user logs in the normal XMPP domain to host discovery process described by rfc6120 will find foo.hospital.net on port 5222 from the SRV record because the client is using hospital.net as the XMPP domain.

Example 2 (Multiple Legacy DNS)

A hospital site with domain hospital.net is deploying Vocera Platform 6.1. They decide to deploy the XMPP host on foo.hospital.net and want to use hospital.net as their domain name. They do not have another XMPP root level deployment and are not doing federation. They have multiple legacy networks and the default DNS domains set in DHCP are different for some of their wireless networks. These include hospital.local and care.net.

_xmpp-client._tcp.hospital.net. 18000 IN SRV 0 0 5222 foo.hospital.net. 
autodiscovervcxmpp.hospital.net. 3600 IN CNAME hospital.net.
autodiscovervcxmpp.hospital.local. 3600 IN CNAME hospital.net.
autodiscovervcxmpp.care.net. 3600 IN CNAME hospital.net.

When the Unified Client starts it discovers that it does not know a valid XMPP domain. It may be on any of the wireless networks. For this example, the wireless network is on care.net. The XMPP adapter finds care.net in the search domains and looks for a CNAME record for autodiscovervcxmpp.care.net and finds hospital.net. This is sufficient for the algorithm to stop and use hospital.net as the XMPP domain.

When the user logs in, the normal XMPP domain to host discovery process will find foo.hospital.net on port 5222 from the _xmpp-client._tcp.hospital.net SRV record, because hospital.net is the XMPP domain.

Example 3 (With Jabber Already Deployed)

A hospital site with the domain hospital.com is deploying Vocera Platform 6.1. They decide to deploy the XMPP host on a4567.hospital.com but cannot use hospital.net as their domain name because Jabber is already deployed there. They want to federate with Jabber.

For the client

_xmpp-client._tcp.vcxmpp.hospital.com. 18000 IN SRV 0 0 5222 a4567.hospital.com. 

For federation

_xmpp-server._tcp.vcxmpp.hospital.com. 18000 IN SRV 0 5 5269 a4567.hospital.com.
_xmpp-server._tcp.chat.vcxmpp.hospital.com. 18000 IN SRV 0 5 5269 a4567.hospital.com.

When the Unified Client starts it discovers that it does not know of a valid XMPP domain. It does not find any CNAME records so it continues. It finds hospital.com in the search domains and looks for a SRV record for _xmpp-client._tcp.vcxmpp.hospital.com. It retrieves the SRV record and is sufficient for the algorithm to stop and use vcxmpp.hospital.net as the XMPP domain.

When the user logs into the normal XMPP domain to host discovery process described by rfc6120 , they will find a4567.hospital.com on port 5222 from the SRV record because the client is using vcxmpp.hospital.net as the XMPP domain.