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 support algorithm #7.
> Yes and no.
In message <19306.62546.632032.348...@hadron.switch.ch>, Alexander Gall writes:
> 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
> >> s
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 and no. Just because you are using a algorithm that is unsupported
doesn'
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"
>> 3 "9.4.2-P2.1"
>> 3 "9.4.2-P2"
>> 3 "9.4.2-P1"
>>
On Feb 4 2010, Alexander Gall wrote:
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
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.
6 matches
Mail list logo