[Dnsmasq-discuss] Bug forward upstream SERVFAIL

Eric Luehrsen ericluehrsen at hotmail.com
Tue Jan 24 08:02:52 GMT 2017


As dnsmasq is a stub resolver I believe it _IS_ important to consider what poppular recursive resolvers do. Bind, Unbound, and NSD do need to be reference because they do most of the heavy lifting. Bind was already discussed. Unbound not only checks for multiple response paths but caches all kinds of infrastructure info (response times n such). For DNSSEC, this means servers with lame DSKEY are passed over for awhile and servers with clean databases are preferred. Obviously dnsmasq wouldnt do this, but the design concepts need to account for common lessons in robustness. ... some servers are lame ...

- Eric



-------- Original message --------
From: Martin Wetterwald <martin.wetterwald at corp.ovh.com>
Date: 1/23/17 05:09 (GMT-05:00)
To: dnsmasq-discuss at thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL

-------- Original message --------
From: Martin Wetterwald <martin.wetterwald at corp.ovh.com>
Date: 1/23/17 05:09 (GMT-05:00)
To: dnsmasq-discuss at thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20170124/f651a2a9/attachment.html>


More information about the Dnsmasq-discuss mailing list