Our authoritative servers for the signed TLD ch (NSEC3, no opt-out)
are receiving queries whose qnames are the NSEC3 hashed owner names of
existing delegeations. I suspect that this is a BIND issue (see
below), hence my post to this list.
What I'm seeing is stuff like this:
03-Feb-2010
On 04 Feb 2010 15:39:55 +, Chris Thompson c...@cam.ac.uk said:
On Feb 4 2010, Alexander Gall wrote:
Of the 60 sources in my sample,
26 responded to version queries. All of them identified themselves as
some version of BIND
5 9.5.0-P2
3 9.4.2-P2.1
3 9.4.2-P2
3 9.4.2-P1
3 9.3.4-P1
On Fri, 05 Feb 2010 08:18:35 +1100, Mark Andrews ma...@isc.org said:
In message 19306.52059.975062.462...@hadron.switch.ch, Alexander Gall
writes:
All of those are NSEC3-agnostic. They should not do any DNSSEC
processing for the ch zone, because they don't support algorithm #7.
Yes
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen gilles.mas...@restena.lu
said:
Hello,
Since enabling the root TA in my resolver, I keep seeing from time to time:
21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
SOA: attempting insecurity proof
21-Jul-2010
On Thu, 22 Jul 2010 07:15:25 +1000, Mark Andrews ma...@isc.org said:
In message 19526.43429.234698.104...@hadron.switch.ch, Alexander Gall
writes:
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen gilles.mas...@restena.lu
said:
Hello,
Since enabling the root TA in my resolver, I keep
It appears that NODATA responses for qtype=DNSKEY are not cached if
DNSSEC validation is enabled (tested with 9.7.2-P3). What is the
rationale behind this?
--
Alex
___
bind-users mailing list
bind-users@lists.isc.org
my
tools could properly handle turning on DNSSEC for an existing zone,
which involves having to wait for cached DNSKEY NODATA to expire from
caches before adding the DS.
On 11/01/11 4:52 PM, Chris Thompson c...@cam.ac.uk wrote:
On Jan 11 2011, Alexander Gall wrote:
It appears that NODATA
I have a signed zone for which dnssec-signzone and named-checkzone of
BIND 9.8.0-P4 emit the message in the subject several times. This
appears to happen in loadnode() defined in lib/dns/rbtdb.c and has
something to do with an auxiliary tree for NSEC, whatever exactly
that is. It doesn't tell me
On 22 Sep 2011 22:57:17 +0100, Chris Thompson c...@cam.ac.uk said:
There was some correspondence last year about this warning message, but
this seems to be caused by something new.
Back then it was due to a bug in dnssec-signzone that caused NSEC3
records to remain in the zone during
9 matches
Mail list logo
