-----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 [email protected] >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > _______________________________________________ Dnsmasq-discuss > mailing list [email protected] > 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----- _______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
