On 22 Sep 2011 22:57:17 +0100, Chris Thompson 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 incremental signing wh
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 m
operly 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" wrote:
>> On Jan 11 2011, Alexander Gall wrote:
>>
>>> It appears
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
https://lists.isc.org/mailman/listi
Hello Karl
On Thu, 26 Aug 2010 23:17:29 +1000, Karl Auer said:
> Some time ago (at least six years) I wrote a program that, among many
> other related operations, creates new zones for a nameserver. This
> program creates new zones that have a TTL value of zero for the SOA
> record.
> That's wh
On Thu, 22 Jul 2010 07:15:25 +1000, Mark Andrews said:
> In message <19526.43429.234698.104...@hadron.switch.ch>, Alexander Gall
> writes:
>> On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen
>> said:
>>
>> > Hello,
>> > Since enabling the ro
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen
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 08:52:27.929 dnssec: debug 3:
On Fri, 05 Feb 2010 08:18:35 +1100, Mark Andrews 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
On 04 Feb 2010 15:39:55 +, Chris Thompson 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"
>&
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 17:36:15.
On Mon, 15 Dec 2008 15:44:39 -0800, JINMEI Tatuya / $(b...@l@C#:H(B
said:
> At Mon, 15 Dec 2008 17:18:21 +0100,
> Alexander Gall wrote:
>> > http://members.iinet.com.au/~pyard...@ihug.com.au/#%5B%5BBIND%209.5%20DNS%20Stats%5D%5D
>>
>> This looks useful, thanks.
On Fri, 12 Dec 2008 17:12:21 +1100, Peter Yardley said:
> I have written a script to collect data from the XML stats channel of a
> Bind 9.5+ DNS server. It works with Cricket and should work with MRTG
> and Cacti.
> You can get it here...
> http://members.iinet.com.au/~pyard...@ihug.com.au/
>
12 matches
Mail list logo
