Improper handeling of DNS SRV records


RFC 2052 describes use for DNS SRV records. Each entry has 4 parts: A priority, a weight, a port, and the hostname. When multiple entries are returned:

"A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in pseudorandom order."

Smack currently returns the first entry returned from the DNS server, which may not have the lowest-numbered priority, and then will not attempt any other servers since the other entries are discarded.




Florian Schmaus
November 10, 2014, 8:14 PM

Indeed, the fallback using the host and the default port (5222 in this case) was re-introduced in Smack 4.1 with the Stream Management commit. But this should be backported to Smack 4.0. I've raised to track this.

Christoph Kutzinski
November 10, 2014, 7:11 PM

The fix for this seems to have removed the fallback to older DNS records - which is still mentioned in the Javadoc

Also this doesn't seem to support the 3rd mentioned fallback:
"If that lookup fails as well, it's assumed that the XMPP server lives at the host resolved by a DNS lookup at the specified domain on the default port of 5269."
since it seems immediately to fail with a javax.naming.NameNotFoundException when cannot be resolved.

See also

Florian Schmaus
February 24, 2013, 10:15 AM
Florian Schmaus
February 24, 2013, 9:45 AM

If the patch for proper DNS SRV handling is merged, the see-other-host feature becomes trivial to implement.

Florian Schmaus
February 24, 2013, 9:44 AM

DNS SRV records are still handled incorrectly:

  • Records with the same priority but different weight aren't randomly distributed by weight

  • Records with the same priority and all 0 weight aren't randomly distributed

Your pinned fields
Click on the next to a field label to start pinning.


Florian Schmaus


Jay Kline