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.
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.
The fix for this seems to have removed the fallback to older _jabber._tcp.xyz 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 _xmpp-client._tcp.xyz cannot be resolved.
If the patch for proper DNS SRV handling is merged, the see-other-host feature becomes trivial to implement.
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