[Opendnssec-user] NSEC3 resalting again

Discussion:

Havard Eidnes

2016-10-17 07:58:55 UTC

Hi,

it looks like the earlier problem I've had with a failure to remove
the old NSEC3PARAM resource records in a re-salt event is back again,
this time with OpenDNSSEC 1.4.10.

I'm seeing zones on my public master with 2 NSEC3PARAM resource
records, the oldest one being published last, and this causes BIND's
dnssec-verify to claim that all the NSEC3 records in the zone are
missing. Bumping the SOA version on the hidden master causes a
re-sign and clears the problem, and this removes the extraneous
NSEC3PARAM record and causes dnssec-verify from BIND to be happy with
the zone again. However, "this should not happen".

The earlier change which was supposed to fix this problem was

https://github.com/opendnssec/opendnssec/commit/033021ff3736cae867cd6f57c8acd05600da5590

It looks like zone_del_nsec3params() is now responsible for marking
all NSEC3PARAM records with "is_removed = 1" (instead of outright
removing them, which caused IXFR to miss the update). However, this
function appears to only be called from zone_publish_nsec3param(),
which in turn appears only to be called from zone_recover2(), which
has the header comment "Recover zone from backup." So where does a
re-salt event occur in the code, and what piece of code takes
responsibility for calling zone_del_nsec3params() when that happens?

It looks like OpenDNSSEC-778 needs to be re-opened...

Regards,

- Håvard

Yuri Schaeffer

2016-10-18 15:01:47 UTC

Permalink

Hi Havard,

Post by Havard Eidnes
It looks like zone_del_nsec3params() is now responsible for marking
all NSEC3PARAM records with "is_removed = 1" (instead of outright
removing them, which caused IXFR to miss the update).

I'm not sure what you mean by "which caused IXFR to miss the update". As
far as I can remember, at the time the issue was that removing the
record would result in the IXFR not to include the removal. But marking
it removed allowed the IXFR to detect its deletion.

Post by Havard Eidnes
However, this
function appears to only be called from zone_publish_nsec3param(),
which in turn appears only to be called from zone_recover2(), which
has the header comment "Recover zone from backup." So where does a
re-salt event occur in the code, and what piece of code takes
responsibility for calling zone_del_nsec3params() when that happens?

zone_publish_nsec3param() is also called from tools_input() when a
signconf is reread. When the signer is commanded to update a zone this
will trigger.

I have been testing today with the DNS output adapter to provoke an
incorrect IXFR but I haven't had any success so far.

If you still have a handle on the var/../tmp/<zone>.ixfr file I'd like
to see it. Perhaps the <zone>.backup2 file as well. But that has to be
from the time of the error to be useful.

Post by Havard Eidnes
It looks like OpenDNSSEC-778 needs to be re-opened...

It is now.

Regards,
Yuri

Yuri Schaeffer

2016-10-20 20:06:17 UTC

Permalink

Hi Håvard,

Post by Havard Eidnes
it looks like the earlier problem I've had with a failure to remove
the old NSEC3PARAM resource records in a re-salt event is back again,
this time with OpenDNSSEC 1.4.10.

We have been able to reproduce the problem today. The offending sequence
of events is:

- ods-signer retransfer (do an AXFR)
- Perform a resalt

NSEC3PARAM record gets a special treatment during XFR since it is
generated by OpenDNSSEC and it is not expected from the input zone. When
processing changes after a AXFR the NSEC3PARAM record is skipped. This
however causes any existing NSEC3PARAM record marked as 'added'.

Later in the NSEC3 generate stage this causes the existing record to
stay in the zone. Triggering your case.

I do have a patch that works but we still have to evaluate if it is
entirely correct.

Regards,
Yuri

Havard Eidnes

2016-10-24 15:32:54 UTC

Permalink

Post by Yuri Schaeffer

Post by Havard Eidnes
it looks like the earlier problem I've had with a failure to remove
the old NSEC3PARAM resource records in a re-salt event is back again,
this time with OpenDNSSEC 1.4.10.

We have been able to reproduce the problem today. The offending sequence
- ods-signer retransfer (do an AXFR)
- Perform a resalt
NSEC3PARAM record gets a special treatment during XFR since it is
generated by OpenDNSSEC and it is not expected from the input zone. When
processing changes after a AXFR the NSEC3PARAM record is skipped. This
however causes any existing NSEC3PARAM record marked as 'added'.
Later in the NSEC3 generate stage this causes the existing record to
stay in the zone. Triggering your case.
I do have a patch that works but we still have to evaluate if it is
entirely correct.

Thanks, that's good news. Sorry I went sort of quiet after my
initial message.

Regards,

- Håvard

Havard Eidnes

2017-01-13 15:44:46 UTC

Permalink

Post by Havard Eidnes

Post by Yuri Schaeffer

Post by Havard Eidnes
it looks like the earlier problem I've had with a failure to remove
the old NSEC3PARAM resource records in a re-salt event is back again,
this time with OpenDNSSEC 1.4.10.

Thanks, that's good news.

Any additional news on this? Is there perhaps now a patch I can
apply on top of 1.4.12?

Regards,

- Håvard

Yuri Schaeffer

2017-01-16 09:05:25 UTC

Permalink

Post by Havard Eidnes
Any additional news on this? Is there perhaps now a patch I can
apply on top of 1.4.12?

Yes, you could apply this [1] commit; Though I recommend checking out
the 1.4/develop branch for a couple of other fixes as well. I'll suggest
in the team whether it is maybe a good time to do a 1.4 release.

Regards,
Yuri

[1]
https://github.com/opendnssec/opendnssec/commit/159331c199315af51a539415be039d46adeceedb

Havard Eidnes

2017-01-16 09:24:25 UTC

Permalink

Post by Yuri Schaeffer

Post by Havard Eidnes
Any additional news on this? Is there perhaps now a patch I can
apply on top of 1.4.12?

Yes, you could apply this [1] commit; Though I recommend checking out
the 1.4/develop branch for a couple of other fixes as well.

Thanks! For now I've applied this single fix.

Post by Yuri Schaeffer
I'll suggest in the team whether it is maybe a good time to do
a 1.4 release.

I'll await the conclusion to this.

Regards,

- Håvard