Smack 4.2.0 failed to resolve for certain FQDN

Smack Smack Dev
1

atalk encounters problem when trying to login with an xmpp account on xxxx@jabbim.com.

The account resolves to an address “lb.jabb.im:5222”. See IM Observatory

However when smack attempts to lookupHostAddress0 with “name = lb.jabb.im” in org.jivesoftware.smack.util.dns.minidns.MiniDnsResolver, it causes an exception: de.measite.minidns.util.MultipleIoException: null, failed to connect to /::1 (port 53): connect failed: ECONNREFUSED (Connection refused).

Not sure what is the exact cause of the problem. Appreciate some help on this.

=====================================

protected List lookupHostAddress0(final String name, List failedAddresses, DnssecMode dnssecMode) {
final ResolverApi resolver = getResolver(dnssecMode);

final ResolverResult aResult;
final ResolverResult aaaaResult;

try {
aResult = resolver.resolve(name, A.class);
aaaaResult = resolver.resolve(name, AAAA.class);
} catch (IOException e) {
failedAddresses.add(new HostAddress(name, e));
return null;
}

2

Look like it also cannot resolve other address. The address is retrieved from the SRVRecord i.e. jabberd.jabber.ccc.de./146.255.57.229:5222

jabberd.jabber.ccc.de.

3

However when smack attempts to lookupHostAddress0 with “name = lb.jabb.im” in org.jivesoftware.smack.util.dns.minidns.MiniDnsResolver, it causes an exception: de.measite.minidns.util.MultipleIoException: null, failed to connect to /::1 (port 53): connect failed: ECONNREFUSED (Connection refused).

Always show the full exception including its stacktrace if possible. In this particular case it’s especially important to see where exactly in MiniDNS’s buisness logic the connection to the IPv6 localhost address is attempted.

4

Thanks, I have found the problem. The problem is that aTalk retrieves the hostname from the “target” in the SRVRecord (if service is supported) using method SRVRecord#getTarget() in org.xbill.DNS.SRVRecord.java. The resulted hostname is used in XMPPTCPConnectionConfiguration.Builder.setHost(hostname);

However the hostname in a SRVRecord always end in a dot as stated in a SRVRecord format indicated below. The getTarget() methods returns the hostname without stripping off the end dot. The method Resolver#resolve(hostname, A.class);

cannot tolerate FQDN with an extra dot at the end hence throws an exception as reported earlier. Without the end dot, the resolver returns the appropriate inetAddress as expected.

Sorry for the confusion caused.

FYI: the windows command ping and online ip resolver tools can handle the FQDN ends in dot without problem.

==========================================

A SRV record has the form:

_service._proto.name. TTL class SRV priority weight port target.
  • service: the symbolic name of the desired service.
  • proto: the transport protocol of the desired service; this is usually either TCP or UDP.
  • name: the domain name for which this record is valid, ending in a dot.
  • TTL: standard DNS time to live field.
  • class: standard DNS class field (this is always IN).
  • priority: the priority of the target host, lower value means more preferred.
  • weight: A relative weight for records with the same priority, higher value means more preferred.
  • port: the TCP or UDP port on which the service is to be found.
  • target: the canonical hostname of the machine providing the service, ending in a dot.