[jitsi-dev] [patch] DNS Resolving assumes NXDOMAIN for AAAA queries


#1

Hey Emil

Since r8310 the ParallelResolver DNS resolver expects an NXDOMAIN response as soon as there is no answer, authority or additional record. This causes troubles with AAAA-queries when none of these three sections are present and NOERROR is returned. According to RFC2308 this is a valid response (NO DATA RESPONSE: TYPE 3.). And as far as I can tell even Google's public DNS returns NODATA for AAAA-queries.

Well, I'm no DNS specialist, but at least the current behavior causes Jitsi to fall back to the backup resolvers (which are blocked at my current network location) and trying lookups for almost three minutes (!) until finally connecting to the SIP proxy/registrar.

I modified the check in isResponseSatisfactory to accept empty responses for AAAA as valid, now logging in works again in a timely fashion.

The attached patch also corrects the lookup of the relevant DNS properties. Guess what the currently present Long.getLong("net.java.sip.communicator.util.dns.DNS_PATIENCE", DNS_PATIENCE) did... :wink:

Regards,
Ingo

dns_resolving.patch (2.81 KB)


#2

Hey Ingo,

Thanks for tracking this down. Please find my replies inline:

На 07.03.11 11:33, Bauersachs Ingo написа:

Hey Emil

Since r8310 the ParallelResolver DNS resolver expects an NXDOMAIN
response as soon as there is no answer, authority or additional
record.

Yes it takes this as its cue that, since its primary resolver doesn't
seem to have any data for the domain, then maybe it would be worth
checking the backup resolver.

This causes troubles with AAAA-queries when none of these
three sections are present and NOERROR is returned. According to
RFC2308 this is a valid response (NO DATA RESPONSE: TYPE 3.). And as
far as I can tell even Google's public DNS returns NODATA for
AAAA-queries.

Indeed, that would make sense for them. They only return AAAA records
for networks that they have an "arrangement" with, so returning NXDOMAIN
doesn't seem kosher in these circumstances.

Well, I'm no DNS specialist, but at least the current behavior causes
Jitsi to fall back to the backup resolvers (which are blocked at my
current network location) and trying lookups for almost three minutes
(!) until finally connecting to the SIP proxy/registrar.

I modified the check in isResponseSatisfactory to accept empty
responses for AAAA as valid, now logging in works again in a timely
fashion.

Well, again, the reason that behaviour was implemented is because we
encounter such responses in many cases where records do exist and are
simply not returned by the local DNS (most often with residential
gateways). This happens regularly for NAPTR and SRV queries but it could
very well happen for AAAA as well.

I understand that what we do is causing problems in your network, but
wouldn't it make more sense to simply set an alternate backup-resolver
in your case? You can very easily do so through provisioning.

Let me know if you'd need any help with this.

Cheers,
Emil

···

The attached patch also corrects the lookup of the relevant DNS
properties. Guess what the currently present
Long.getLong("net.java.sip.communicator.util.dns.DNS_PATIENCE",
DNS_PATIENCE) did... :wink:

Regards, Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#3

Hey

Since r8310 the ParallelResolver DNS resolver expects an NXDOMAIN
response as soon as there is no answer, authority or additional
record.

Agreed, makes sense so far.

Yes it takes this as its cue that, since its primary resolver doesn't
seem to have any data for the domain, then maybe it would be worth
checking the backup resolver.

This causes troubles with AAAA-queries when none of these
three sections are present and NOERROR is returned. According to
RFC2308 this is a valid response (NO DATA RESPONSE: TYPE 3.). And as
far as I can tell even Google's public DNS returns NODATA for
AAAA-queries.

Indeed, that would make sense for them. They only return AAAA records
for networks that they have an "arrangement" with, so returning NXDOMAIN
doesn't seem kosher in these circumstances.

Apart from Google, I've read that returning NXDOMIN for an AAAA query actually stops further lookups for A-records. So it would be an error with or without an arrangement. I therefore interpret the empty result for AAAA as perfectly valid.

Well, again, the reason that behaviour was implemented is because we
encounter such responses in many cases where records do exist and are
simply not returned by the local DNS (most often with residential
gateways). This happens regularly for NAPTR and SRV queries but it could
very well happen for AAAA as well.

While I agree this makes a lot of sense for NAPTR and SRV queries, I disagree on the AAAA-records as its normal behavior. Instead of just accepting empty responses as in my patch a cross-check whether a result for a "normal" A-response was received could be implemented. As soon as a valid address is retrieved further lookups should not block the application.

All in all, I think the whole DNS stuff should be up to the OS as it knows whether IPv6 is available at all, whether it should be preferred etc. Java's (and by this I mean the JRE) DNS lookup is completely broken. It doesn't even know how to correctly lookup the DNS server addresses in Windows! Using xbills dnsjava is only proof of this...

I understand that what we do is causing problems in your network, but
wouldn't it make more sense to simply set an alternate backup-resolver
in your case? You can very easily do so through provisioning.

Let me know if you'd need any help with this.

I can't set a backup-resolver as _all_ foreign DNS servers are blocked from inside the university network. Provisioning doesn't help either because this problem only affects me and the other users at FHNW - but not the whole project.

The attached patch also corrects the lookup of the relevant DNS
properties. Guess what the currently present
Long.getLong("net.java.sip.communicator.util.dns.DNS_PATIENCE",
DNS_PATIENCE) did... :wink:

Do you agree at least on these snippets? :slight_smile:

cu,
Ingo


#4

Hey all,

Ingo and I have discussed most of this offlist but I thought I'd update
the archives.

So basically we have agreed that we won't fallback to backup resolving
in case we get a non-NXDOMAIN failure for AAAA and NAPTR. We'll still do
it otherwise.

Ingo is also going to implement a patch that allows users to disable DNS
fallback entirely if they choose to.

Cheers,
Emil

На 08.03.11 23:52, Bauersachs Ingo написа:

···

Hey

Since r8310 the ParallelResolver DNS resolver expects an
NXDOMAIN response as soon as there is no answer, authority or
additional record.

Agreed, makes sense so far.

Yes it takes this as its cue that, since its primary resolver
doesn't seem to have any data for the domain, then maybe it would
be worth checking the backup resolver.

This causes troubles with AAAA-queries when none of these three
sections are present and NOERROR is returned. According to
RFC2308 this is a valid response (NO DATA RESPONSE: TYPE 3.). And
as far as I can tell even Google's public DNS returns NODATA for
AAAA-queries.

Indeed, that would make sense for them. They only return AAAA
records for networks that they have an "arrangement" with, so
returning NXDOMAIN doesn't seem kosher in these circumstances.

Apart from Google, I've read that returning NXDOMIN for an AAAA query
actually stops further lookups for A-records. So it would be an error
with or without an arrangement. I therefore interpret the empty
result for AAAA as perfectly valid.

Well, again, the reason that behaviour was implemented is because
we encounter such responses in many cases where records do exist
and are simply not returned by the local DNS (most often with
residential gateways). This happens regularly for NAPTR and SRV
queries but it could very well happen for AAAA as well.

While I agree this makes a lot of sense for NAPTR and SRV queries, I
disagree on the AAAA-records as its normal behavior.

Instead of just
accepting empty responses as in my patch a cross-check whether a
result for a "normal" A-response was received could be implemented.
As soon as a valid address is retrieved further lookups should not
block the application.

All in all, I think the whole DNS stuff should be up to the OS as it
knows whether IPv6 is available at all, whether it should be
preferred etc. Java's (and by this I mean the JRE) DNS lookup is
completely broken. It doesn't even know how to correctly lookup the
DNS server addresses in Windows! Using xbills dnsjava is only proof
of this...

I understand that what we do is causing problems in your network,
but wouldn't it make more sense to simply set an alternate
backup-resolver in your case? You can very easily do so through
provisioning.

Let me know if you'd need any help with this.

I can't set a backup-resolver as _all_ foreign DNS servers are
blocked from inside the university network. Provisioning doesn't help
either because this problem only affects me and the other users at
FHNW - but not the whole project.

The attached patch also corrects the lookup of the relevant DNS
properties. Guess what the currently present
Long.getLong("net.java.sip.communicator.util.dns.DNS_PATIENCE",
DNS_PATIENCE) did... :wink:

Do you agree at least on these snippets? :slight_smile:

cu, Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31