Hi, I agree with khm that it's not because A software does something that it's right and that B should also do it.
I do think however like Dave (independently of what BIND does) that the aim of having several upstreams is to provide robustness. The upstreams in our case are the customer's ISP DNS (we use several ISP at the same time). We cannot control those DNS. If one of them is misconfigured and has a internal failure, it will return SERVFAIL. This should not affect dnsmasq's robustness. The end DNS client wants to get an answer. If he gets a SERVFAIL answer, it's terrible, usually it means no Internet at all. Our case is not DNSSEC related. DNSSEC is disabled, but upstream can still return SERVFAIL. We've already patched our dnsmasq internally and it's already in production. We are happy with this behaviour. Our clients only need to have at least one ISP DNS which is working, and dnsmasq will make sure he gets an answer. Of course if all upstreams return SERVFAIL, dnsmasq will forward SERVFAIL. I just wanted to share it here to help in case dnsmasq maintainers also think it's a good behaviour. :) Martin On 22/01/17 22:57, Kurt H Maier wrote: > On Sun, Jan 22, 2017 at 07:31:35PM -0800, Dave Taht wrote: > > From a brief conversation with the bind9 maintainer: > > BIND is far from being a normative DNS reference, and I certainly do > not believe that "BIND does it" is a good reason for anything. Quite > the contrary. > > However, this discussion has been happening for a while now; last thing > Simon Kelley said about it was that SERVFAIL in a DNSSEC context meant > that the upstream server cannot validate the record's chain of trust -- > meaning that this particular SERVFAIL is not recoverable. In that case > you don't want to waste time spamming other resolvers just to get the > same failure. > > Where are you getting SERVFAIL in this case? Is it a DNSSEC failure? > > khm > > _______________________________________________ > 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
