On Tue, Jan 24, 2017 at 08:02:52AM +, Eric Luehrsen wrote:
> 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.
This really just reinforces
servers are lame ...
- Eric
Original message
From: Martin Wetterwald <martin.wetterw...@corp.ovh.com>
Date: 1/23/17 05:09 (GMT-05:00)
To: dnsmasq-disc...@thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL
Original message
From:
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
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
l.com>
Sent: Sunday, January 22, 2017 22:31
To: dnsmasq-discuss
Subject: Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL
>From a brief conversation with the bind9 maintainer:
D: if bind gets a servfail, and has two forwarders, will it try the
other forwarder?
E: Yes.
D: Even in the
From a brief conversation with the bind9 maintainer:
D: if bind gets a servfail, and has two forwarders, will it try the
other forwarder?
E: Yes.
D: Even in the case of a dnssec query?
E:
Bind9 retries an authoritative answer because it might have been
spoofed or one of the servers might be out
On Tue, Jan 03, 2017 at 02:42:41PM +0100, Martin Wetterwald wrote:
>
> However, our case is not DNSSEC related and can be reproduced by setting up
> two upstreams, with one always replying by SERVFAILs answers, the other
> one working normally.
>
You can 'reproduce' all kind of stuff by setting
Hi and happy new year :)
We don't use DNSSEC, the problem doesn't seem DNSSEC related.
But even if DNSSEC is enabled, a SERVFAIL answer should be forwarded by
dnsmasq to the client only if all upstreams fail DNSSEC chain-of-trust
validation and all send a SERVFAIL to dnsmasq.
How do you think
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
On Tue, Nov 22, 2016 at 04:18:55PM +, 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
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
Hello,
At OVH, we use dnsmasq in our product OverTheBox, an OpenWRT based
router.
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).
If you have say 4
12 matches
Mail list logo
