On Tue, Aug 30, 2016 at 6:32 PM, Yuri Schaeffer wrote:
> Hi Emil,
>
> > Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> > the empty non-terminal is only derived from an insecure delegation
> > covered by an Opt-Out NSEC3 RR.
> >
> > If I understand the above corre
On Tue, Aug 30, 2016 at 6:32 PM, Yuri Schaeffer wrote:
> Hi Emil,
>
> > Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> > the empty non-terminal is only derived from an insecure delegation
> > covered by an Opt-Out NSEC3 RR.
> >
> > If I understand the above corre
Hi Emil,
> Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> the empty non-terminal is only derived from an insecure delegation
> covered by an Opt-Out NSEC3 RR.
>
> If I understand the above correctly, NSEC3 records should not be created
> for insecure delegations.
Hi Mark,
The policy I used for this example was actually created for a very short
zonefile with well known records where the enumeration is not an issue. I
would have even used NSEC, but instead opted for NSEC3 to make the custom
checks I run on the signed zones compliant for all zones (when all z
Excuse my ignorance/sanity, what does it mean to have a NSEC3 iteration
of Zero? Shouldn't the minimum be 1 ?
I would also have thought that salt would be required - so a length of
Zero would be a strange thing to do. Kind of makes the Resalt value of
100 days redundant
Personally - I'd choose an
Hello,
Running ODS 1.4.9. I know 1.4.10 is out (as well 2.x.x) but I do not see
anything related to the issue mentioned in the Changelog, so I presume
1.4.10 inherits the same behavior.
Domain example.com, contains the following insecure delegation:
sub2.sub1 IN NS ns1.yahoo.com.
