[Dnsmasq-discuss] Bug forward upstream SERVFAIL

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The rationale behind this change is that SERVFAIL is the expected
reply if DNSSEC checking is turned on, and the upstream server cannot
validate the DNSSEC chain-of-trust for the requested record. This
change went as part of the dnsmasq DNSSEC implementation, because it
was expected that the "check DNSSEC" bit would be set on queries, so a
return of SERVFAIL implies a DNSSEC problem, which is not recoverable.

If SERVFAIL is an expected error return which means DNSSEC validation
failure, you don't necessarily want to spend time forwarding the query
to other servers and waiting for them to reply.

I'm not sure the above is cast-iron argument for the current
behaviour, and even if it is the behaviour could be modulated,
depending on if the "check DNSSEC" bit was set in the query.

Was the original problem DNSEC related, or does the SERVFAIL originate
from some other error?


Cheers,

Simon.


On 23/11/16 12:04, Martin Wetterwald wrote:
> Yes, the behaviour I had in mind is to only forward SERVFAIL to
> the client if we didn't have any "better" answer (NOERROR) from any
> other upstream.
> 
> That way, DNS resolution with several upstreams stays reliable even
> if some of them SERVFAIL.
> 
> Does that seem reasonable? Does that still respects the RFC
> definition of "SERVFAIL"?
> 
> Martin
> 
> On 22/11/16 12:02, /dev/rob0 wrote:
>> On Tue, Nov 22, 2016 at 04:18:55PM +0000, Chris Novakovic wrote:
>>> On 22/11/16 15:03, Martin Wetterwald wrote:
>>>> We found what we think is a bug (at least a not wanted 
>>>> behaviour), but it seems it's actually a feature, when
>>>> looking at commits 4ace25c5 and 51967f980 (pasted at the end
>>>> of this email).
>>> 
>>> 4ace25c5 is a red herring: that provides REFUSED responses with
>>> the behaviour you're looking for. Whether the same behaviour
>>> ought to be applied to SERVFAIL responses is for Simon to
>>> decide: the commit message for 51967f980 isn't clear about why
>>> SERVFAIL should be considered a "successful" upstream response,
>>> but I'm sure there was a reason, and I'm sure he can fill us
>>> in.
>> 
>> SERVFAIL can sometimes be considered "successful" depending on 
>> circumstances.
>> 
>> If all the authoritative NS hosts for a zone are returning
>> SERVFAIL for queries, then indeed, that's as best as can be
>> done.
>> 
>> But the problem could be on the recursive resolver, such as [for
>> one example] cache poisoning causing DNSSEC validation failure.
>> 
>> Unfortunately dnsmasq is not in a position to know which it is.
>> 
>> I think the most prudent thing for dnsmasq to do on SERVFAIL is
>> to attempt the query with other upstream servers, if possible.
>> But an answer needs to be provided to the client before its own
>> timeout value. -- http://rob0.nodns4.us/ Offlist GMX mail is seen
>> only if "/dev/rob0" is in the Subject:
>> 
>> _______________________________________________ Dnsmasq-discuss
>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYVFciAAoJEBXN2mrhkTWiYzQP/3m2IDxpNFrif/r7Y7AKTlv+
HiBIcHJCGuMxrxAAyBjh2OrS8ePM880fiK1Hbin2q2lJ7n5adSx2KncmKTh14qJt
4NELzU21NlW7FvOufmqUvoYR2RzlR42GajtL9kjgvG+MW4EkvLF0gnLwEZLEzhbp
HTUHQCqvgIr4Tya7Ut+wyxywwsem20pXAub5Na9rR9gqZzGeE96zErWxTxKjeUr6
N/AavO5ls6qJo1Xf9qihpSPMbr3OHV+o5Tb+Nk4JWXZ7RJDBAkVxwV/BzrXdD2aL
In7YZUpnFyboGtEWiiYZ7CxKxGypS/vm8TdPMBX8K0738NnwHWAWJBzVeNMJDJub
aYx7ATHDhxEtT9rSeGoQJ9B+tma5mwNMDNsXZ44xClV40hjuZWGqFuLUb0vJCEHP
+BBL/H7lKLsNBrf8qSqWitQBTKLj9MSv8HxVljkzWWcuorXmF13mQF+vmG673ERg
ZhfZ/wpGBtPfmZ9O3riV9/r24sk8VXK6AzQAzJYZGDMvfqR5zmHlIripg2Fow7Do
0tL/v3PGfWDFvbDPF3yxmwJUI0UmPPbzsGZtixf0Tic9csZ31ROYAeuPGXZclI0h
ABzw20msbZvEXUAoZuIjyMbUd89v0W5TyBpVLkUJHsH8tGjSYRoLAppXF/6yPz3R
r3i5gpPShBB1cV6moJk5
=PVK8
-----END PGP SIGNATURE-----