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 late
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 the
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
nam
In message , 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 forwarding to the authoritative also caches th
> 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
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 is querying this bogus nameserver, then it's OK?
cv
On Thu, May 19, 2011 at 11:16 PM, Ma
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 of
SEC2.pdf,
combine info on pages 15+16 (bogus NS) and 17+18 (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:
> 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.
_
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 any
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.
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 th
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 t
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 t
On Thu, May 19, 2011 at 7:44 PM, Evan Hunt 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 environmental cond
> 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 environmental condition we haven't
identified yet--the bug has never once tur
Hi Matt:
On 05/19/11 17:08, Matthew Pounsett wrote:
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, a
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 undefined,
-Original Message-
> From: dns-operations-boun...@lists.dns-oarc.net
> [mailto:dns-operations-boun...@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-oper
19 matches
Mail list logo
