Re: Tracking down validation failures

2009-06-14 Thread Mark Andrews
In message , Chris Tho mpson writes: > On Jun 12 20009, I wrote: > > [...] > >The debug level 2 messages, which correspond to SERVFAILs, are all > >associated with "8.84.in-addr.arpa", and it does seem that something > >is wrong with the (signed) delegation of that from "84.in-addr.arpa". > >I ca

Re: Tracking down validation failures

2009-06-13 Thread Chris Thompson
On Jun 12 20009, I wrote: [...] The debug level 2 messages, which correspond to SERVFAILs, are all associated with "8.84.in-addr.arpa", and it does seem that something is wrong with the (signed) delegation of that from "84.in-addr.arpa". I can reproduce the SERVFAIL effect on other validating na

Re: Tracking down validation failures

2009-06-12 Thread JINMEI Tatuya / 神明達哉
At 12 Jun 2009 17:50:39 +0100, Chris Thompson wrote: > (They don't add up to as much as the statistics-channel "ValFail" counter > is increasing by, though.] It's not surprising: if validation attempt succeeds with one authoritative server after some validation failures with other authoritative

Re: Tracking down validation failures

2009-06-12 Thread Chris Thompson
On Jun 11 2009, Jeremy C. Reed wrote: On Thu, 11 Jun 2009, Chris Thompson wrote: We have recently turned on DNSSEC validation (using dlv.isc.org) in our main university-wide recursive nameservers, which are running BIND 9.6.1rc1. No-one is actually complaining, but the counts I am seeing for

Re: Tracking down validation failures

2009-06-11 Thread Mark Andrews
In message , Chris Thom pson writes: > We have recently turned on DNSSEC validation (using dlv.isc.org) in our > main university-wide recursive nameservers, which are running BIND 9.6.1rc1. > > No-one is actually complaining, but the counts I am seeing for "ValFail" > on the statistics channel ar

Re: Tracking down validation failures

2009-06-11 Thread Jeremy C. Reed
On Thu, 11 Jun 2009, Chris Thompson wrote: > We have recently turned on DNSSEC validation (using dlv.isc.org) in our > main university-wide recursive nameservers, which are running BIND 9.6.1rc1. > > No-one is actually complaining, but the counts I am seeing for "ValFail" > on the statistics chan

Tracking down validation failures

2009-06-11 Thread Chris Thompson
We have recently turned on DNSSEC validation (using dlv.isc.org) in our main university-wide recursive nameservers, which are running BIND 9.6.1rc1. No-one is actually complaining, but the counts I am seeing for "ValFail" on the statistics channel are quite a bit higher than we were seeing during