feat: try to connect to parent xmpp domain

[mightymop]

If no dns entry was found for xmpp service subdomain, try to connect to xmpp domain host itself.

Example:

If the dns entry for conference.xmppdomain, pubsub.xmppdomain, search.xmppdomain was not set the method will now try to connect to the (parent) xmppdomain, cause the service will mostly run on the same host as the subdomain service.

[guusdk]

I'm thinking that this is behavior that's already in Openfire?

[mightymop]

I'm thinking that this is behavior that's already in Openfire?

i think i have found an edge case:

For example:

i have a srv record for mopsdom.de, but a wildcard * for subdomains to another server which has nothing to do with xmpp

dig srv _xmpp-server._tcp.mopsdom.de
_xmpp-server._tcp.mopsdom.de. 300 IN    SRV     0 5 5269 www.mopsdom.de.

i used gajim and connected with an account to mopbook(xmppdomain) to make some service discoverys on mopsdom.de (xmppdomain) and i ran into:

1. org.jivesoftware.openfire.net.SocketUtil.createSocketToXmppDomain which trys to get the host for mopsdom.de (thats working of cource)
2. when i wanted to scan conference.mopsdom.de it gets resolved to the other server (because of wildcard for subdomains) remoteHost.getHost(); returns "conference.mopsdom.de" to realHostname so socket.connect( new InetSocketAddress... trys to open a connection to "conference.mopsdom.de" which of course will fail and then it jumps into catch block after timeout

i could reproduce this with other service subdomains (pubsub,...) too

then i inserted the fallback if the connection could not be established

Otherwhise for every xmpp-subdomain a cname entry to dns have to be inserted to overcome this issue... But that is in the hands of the other administrator (receiver). So this could help the sender.

[mightymop]

rebased to current master...