> ...and if I'm not terribly mistaken, the three zones which have been
> flagged in this way (yep, two more popped up) so far have all been
> added to our OpenDNSSEC setup after we upgraded to 1.4.9.
I think there is a relation but no causation in this case. They are
probably added around the same
>>> Does anyone have an idea what more needs to be done to zero in on
>>> this problem?
>>
>> Hmm. My first guess would be that it involves a resalt. Your log lines
>> seem to indicate that no new NSECS are being generated. Yet a resign
>> solves the problem. Could you compare the NSEC3PARAM from t
>> Does anyone have an idea what more needs to be done to zero in on
>> this problem?
>
> Hmm. My first guess would be that it involves a resalt. Your log lines
> seem to indicate that no new NSECS are being generated. Yet a resign
> solves the problem. Could you compare the NSEC3PARAM from the fai
Hm,
seems I need to follow up on my own posting, as I see that all
the three "bad" zones have *two* NSEC3PARAM records:
255.39.128.in-addr.arpa. 0 IN NSEC3PARAM 1 0 5 45F39B9A60C14581
255.39.128.in-addr.arpa. 0 IN NSEC3PARAM 1 0 5 D9E0ED2449E3721D
while the good one only has one:
255.39.1
Hi Håvard,
> Apr 1 02:50:06 hugin ods-signerd: [STATS] 255.39.128.in-addr.arpa 2016040100
> RR[count=0 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=2 reused=237
> time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)]
> Apr 1 04:50:07 hugin ods-signerd: [STATS] 255.39.128.in-addr.arpa 2016040101
Hi,
our zones are set up to use NSEC3 for authenticated denial of
existence. In our setup, we let OpenDNSSEC do zone transfers in
and out (as explained before), but on the public distribution
master we run periodic checks of all the zones using both
ldns-verify-zone and BIND's dnssec-verify progr
