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 zones use NSEC3). With no other reason to use NSEC3 I was advised to use zero length salt and zero iterations, this way verifying resolvers need to do less work.. IIRC resalt value of 0 did not work and generated an error, so 100 in this case is just a number.
Emil On Tue, Aug 30, 2016 at 4:44 PM, Mark Elkins <[email protected]> wrote: > 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 iteration of 5 (something between 2 and 8) > and a salt of at least 4, though I use 8. > > On 30/08/2016 15:21, Emil Natan wrote: > > 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 <http://example.com>, contains the following insecure > > delegation: > > sub2.sub1 IN NS ns1.yahoo.com <http://ns1.yahoo.com>. > > > > Policy and signconf has optout set: > > <Denial> > > <NSEC3> > > <OptOut/> > > <Resalt>P100D</Resalt> > > <Hash> > > <Algorithm>1</Algorithm> > > <Iterations>0</Iterations> > > <Salt length="0"/> > > </Hash> > > </NSEC3> > > </Denial> > > > > When signed with ODS, NSEC3 record is created for sub1.example.com > > <http://sub1.example.com>, see files attached. > > > > RFC5155, Section 7.1 > > > > 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. > > validns also recognize this as an error: > > validns ../signed/example.com.zone.signed > > ../signed/example.com.zone.signed:22: NSEC3 without a corresponding > > record (or empty non-terminal) > > > > Any help will be highly appreciated. > > > > Emil > > > > p.s I'll try 1.4.10 anyway and will update if it makes any difference > > > > > > > > _______________________________________________ > > Opendnssec-user mailing list > > [email protected] > > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > > > > -- > Mark James ELKINS - Posix Systems - (South) Africa > [email protected] Tel: +27.128070590 Cell: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > >
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
