Alexander Clouter wrote:
[...]
It is interesting that an A record lookup is made by ejabberd though in
this situation, is there some fallback code being involked? Should it
be?
Yes and no: the fallback to the A-record resolution is specified in the
spec (see the fourth paragraph of [1]), but the spec seems to only talk
about the case of a failed SRV query, in the sense of the query returned
the NXDOMAIN (or a similar) error, as I understand this.
So what's the correct behaviour in the presense of a misconfigured DNS
resolver is not clear to me.
Well it probably should not work at all. I'm confused why A record
queries are being spat out though rather than SRV. You would either
expect this to work or not at all.
Any ideas how to go about working out under what situation
(/etc/resolv.conf content relating, when it cannot be parsed) would
cause ejabberd to make A record lookups rather than SRV ones?
My speculation (I haven't studied the Erlang source code so far) follows.
It might surprise you (as I was surprised by this on my first
encounter), but the core (libc's) resolver does not have any devices to
easily perform DNS queries, other than A and PTR (and possibly AAAA),
and these are performed by higher-level library calls like gethostbyname(3).
When you need to query for something funky, like SRV, you either have to
use some special library like ADNS or lwres, or resort to using
low-level resolver(3) calls or step even lower and speak to nameservers
directly.
The resolver(3) does not export any API for parsing the responses of DNS
servers (while the code to do this is actually present), and so there's
no much difference between calling the low-level resolver(3) functions
or messing with DNS datagrams directly.
Therefore, my guess is that Erlang uses gethostbyname(3) and friends for
simple cases, as they are supported even on Windows, and resorts to
sending network packets for complex cases. That's why it parses
/etc/resolv.conf looking for nameservers.
In ejabberd, a failure to resolve an SRV record (on my system, attempts
to resolve an SRV record with misconfigured resolver (nameserver set to
"::1") lead to ETIMEDOUT errors) is possibly tread in the same way as a
missing SRV record for that host, which, in turn, triggers the fallback
mechanism.
If resolution of A records, as I suppose, is, in the end, performed
using the calls like gethostbyname(3), these worked OK as they used the
core resolver which seems to have no problems with IPv6 nameservers.
As a side note, such approach for DNS queries is also used in Tcl: its
core runtime supports TCP sockets and does basic A/PTR resolution behind
the scenes, using the standard calls mentioned above.
Contrary to this, the extension module tcldns, which adds support for
complex queries, attempts to load an extension providing support for
UDP, then parses the system DNS resolver confguration and speaks to
nameservers directly. And if it cannot use UDP, it even resorts to
performing queries using TCP.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
