On 5/28/2011 4:18 PM, Michael Sinatra wrote:
This will be in BIND 9.8.1 final. BIND 9.8.1b1 is already cut
and will need this to be applied.
I just noticed that the patch for query.c has been added as an extra
patch to the FreeBSD port for 9.8.0-P2, so if you build the bind98 port
from the
This will be in BIND 9.8.1 final. BIND 9.8.1b1 is already cut
and will need this to be applied.
I just noticed that the patch for query.c has been added as an extra patch
to the FreeBSD port for 9.8.0-P2, so if you build the bind98 port from the
latest FreeBSD ports collection, you'll get
Subject: Re: [dns-operations] Bind 9.8.0 intermittent problem with
non-recursive responses
So, if I understand you correctly, if I were to sign my authoritative
zone and my caching nameserver, which is bogus for this zone, is
dnssec enabled, and also validating, and no other validating
nameserver
On 2011-05-19, at 21:58, Michael Sinatra wrote:
If you're saying that you shouldn't *offer* recursive and authoritative
services on the same box, then I generally agree. If you're saying that you
shouldn't ever prime your cache with a zone, or have a recursive server be a
slave to
I hope to have a fix soon, before 9.8.1 ships (but after 9.8.1b1, which
is already in the pipeline).
Followup: The bug was in fact found about an hour after I wrote that,
and will be fixed in 9.8.1.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
(forwarding NS)
)
Kind regards,
Marc Lampo
Security Officer
EURid
-Original Message-
From: Matthew Pounsett [mailto:m...@conundrum.com]
Sent: 20 May 2011 06:49 AM
To: Carlos Vicente
Cc: bind-users@lists.isc.org
Subject: Re: [dns-operations] Bind 9.8.0 intermittent problem with
non
On 05/20/2011 05:56 AM, Matthew Pounsett wrote:
If, for some reason, you can't wait for your TTLs to expire, then
forwarding the relevant zones to your authoritative servers is a
better solution than slaving the zones.
How?
The whole point of stealth slaving is timely (NOTIFY/IXFR) updates
If, for some reason, you can't wait for your TTLs to expire, then forwarding
the relevant zones to your authoritative servers is a better solution than
slaving the zones.
But the server that is forwarding to the authoritative also caches the
response, so that won't help. I'm looking for
In message BANLkTinz9NvUMzA83b6KC12Wi6=bpoz...@mail.gmail.com, Carlos Vicente
writes:
If, for some reason, you can't wait for your TTLs to expire, then
forwarding the relevant zones to your authoritative servers
is a better solution than slaving the zones.
But the server that is
...@lists.dns-oarc.net] On Behalf Of Carlos Vicente
Sent: Thursday, May 19, 2011 1:58 PM
To: bind-users@lists.isc.org; dns-operati...@lists.dns-oarc.net
Subject: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive
responses
Dear lists [apologies if you receive two copies
While it's possible you have encountered a bug with BIND, it's generally a bad
idea to mix recursive and authoritative service in the same process. The RFCs
that define the resolution algorithms were never written with mixed service in
mind, and there are conflicts that can result in
On Thu, May 19, 2011 at 7:44 PM, Evan Hunt e...@isc.org wrote:
Odds are good this is a software bug in BIND.
I can absolutely confirm that this is a bug in BIND 9; we're aware of
it and have been trying to reproduce it for some time. Unfortunately
it seems to be triggered by some
Hi all,
If you're saying that you shouldn't *offer* recursive and authoritative
services on the same box, then I generally agree. If you're saying that you
shouldn't ever prime your cache with a zone, or have a recursive server be a
slave to anything, then I'd say it gets kind of hairy
Hi all,
If you're saying that you shouldn't *offer* recursive and authoritative
services on the same box, then I generally agree. If you're saying that you
shouldn't ever prime your cache with a zone, or have a recursive server be a
slave to anything, then I'd say it gets kind of hairy
On 2011-05-20, at 00:35, Carlos Vicente wrote:
That's news to me. What's the failure mode? Does the server return SERVFAIL,
or does it not set the AD flag, or...?
It's another undefined condition in the RFCs, and so the outcome is
implementation specific. I believe in the case of BIND the
In the end it was a simple bug. dbversion-queryok was not being
set to ISC_TRUE when it should have been (second change).
Initialising dbversion-queryok to ISC_FALSE made the failure
deterministic.
This will be in BIND 9.8.1 final. BIND 9.8.1b1 is already cut
and will need this to be applied.
16 matches
Mail list logo
