Discussion:
[Opendnssec-user] nsec3 records for insecure empty non-terminal
Emil Natan
2016-08-30 13:21:00 UTC
Permalink
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.

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, 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
Mark Elkins
2016-08-30 13:44:24 UTC
Permalink
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.
Post by Emil Natan
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
sub2.sub1 IN NS ns1.yahoo.com <http://ns1.yahoo.com>.
<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 ../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
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Emil Natan
2016-08-30 14:08:45 UTC
Permalink
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
Post by Mark Elkins
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.
Post by Emil Natan
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
sub2.sub1 IN NS ns1.yahoo.com <http://ns1.yahoo.com>.
<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 ../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
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
--
Mark James ELKINS - Posix Systems - (South) Africa
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Yuri Schaeffer
2016-08-30 15:32:14 UTC
Permalink
Hi Emil,
Post by Emil Natan
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 ../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.
Ah, opt-out with empty non terminals. Tricky business. From that quote
(and some light reading) I can not derive the signer output is wrong.
Basically that requirement explicitly does not apply here.

I'm unsure why validns does not detect the empty non-terminal. But I
admit further reading might be necessary to give a definitive answer.

//Yuri
Emil Natan
2016-08-30 16:13:58 UTC
Permalink
Post by Yuri Schaeffer
Hi Emil,
Post by Emil Natan
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 ../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.
Ah, opt-out with empty non terminals. Tricky business. From that quote
(and some light reading) I can not derive the signer output is wrong.
Basically that requirement explicitly does not apply here.
I'm unsure why validns does not detect the empty non-terminal. But I
admit further reading might be necessary to give a definitive answer.
//Yuri
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Emil Natan
2016-08-30 16:25:52 UTC
Permalink
Post by Yuri Schaeffer
Hi Emil,
Post by Emil Natan
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 ../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.
Ah, opt-out with empty non terminals. Tricky business. From that quote
(and some light reading) I can not derive the signer output is wrong.
Basically that requirement explicitly does not apply here.
I'm unsure why validns does not detect the empty non-terminal. But I
admit further reading might be necessary to give a definitive answer.
//Yuri
Actually validns error message suppose presence of empty non-terminals.
In addition (I decided not to mention it in my initial email) BIND also do
not sign these. It does not mean the ODS signer is doing the wrong thing, I
only mention it as a reference to other interpretations on the RFC
definition. Unfortunately the different interpretations break few of my
tests on the signed zones which is not ideal. I presume in practice nothing
will be broken in either way.
Post by Yuri Schaeffer
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Loading...