NSEC3PARAM and DNSKEY change using DDNS should be allowed

Some notes:

• If NSEC3PARAM is changed in any way (or added anew, or removed) special function that creates new chain has to be coded.
• I would not let the user change DNSKEYS - since Knot manages them semi-automatically, upon their removal, they would be added right back (maybe valid only for prepublish, but that should be handled using key metadata see #220 (closed))

Check out how NSEC -> NSEC3 (or backward) rollovers are handled with regard to caching resolvers. Should there be both chains at once present in the zone? If yes, adding NSEC3PARAM should result only in creating NSEC3 chain, leaving NSEC chain intact. If not, the NSEC chain should be removed.

NSEC3PARAM handling

• Added new NSEC3PARAM: It's OK to do all the steps at once (the following order is according to RFC 5155):
  • Generate new NSEC3 chain
  • Add NSEC3PARAM
  • Remove all NSECs from zone
• Removing one or more NSEC3PARAMS: Also OK to do all the steps at once:
  • If all NSEC3PARAMS are removed, create NSEC chain
  • Remove NSEC3PARAM(s)
  • Remove all NSEC3s associated with the removed NSEC3PARAM(s)

DNSKEY handling

• Adding new DNSKEY:
  • If the key is not present in the keydir, it should be added to the zone, but no signatures generated.
  • If the key is present in the keydir, consult key metadata and generate signatures according to them (published/active).
• Removing one or more DNSKEYs:
  • If the removed DNSKEY is not in the keydir, remove it and probably also remove all signatures associated with this key.
  • If the removed DNSKEY is in the keydir, consult key metadata and leave/remove it according to them. If the DNSKEY is left in the zone, warn user in the log.

In either case, it is safer to use the whole-zone-signing function when manipulating DNSKEYs over DDNS. For NSEC3PARAM, the zone-fixing function is sufficient, but it should create/remove NSEC/NSEC3 chains.

Comments are welcome, @mvavrusa @jvcelak @dsalzman @ondrej

If the key is present in the keydir, consult key metadata and generate signatures according to them (published/active).

This is not possible. If the DNSKEY exists in keydir, it is automatically handled by automated signing. So if inactive DNSKEY is added using DDNS, it will be removed during next resign event.

And the same is valid for DNSKEY removing.

I would rather refuse all changes of DNSKEYs, which are present in keydir.

I meant this situation:

Key K1 is added by the admin to the keydir, but not to the zonefile, server is not reloaded. Then he adds DNSKEY for K1 to the zone via DDNS. Then the signing should take this DNSKEY, check if it is present in the keydir and if it is, use or don't use it for signing according to he policy.

So if inactive DNSKEY is added using DDNS, it will be removed during next resign event.

How is this so? Didn't we agree that inactive DNSKEYs should be present in the zonefile for the pre-publish-type rollover. Or maybe I'm using wrong terms, so please correct me.

We are stuck with ISC terminology: create -> publish -> activate -> inactivate -> delete

I'm trying to say that if you add the DNSKEY into the zone before publish or after inactivate using DDNS, it will be later removed by automatic signing.

OK, that's probably correct. I used the terms incorrectly and by 'inactive' I meant published but not active.

If an inactive or not-published key is added using DDNS, then it's OK that it will be removed (though it should be logged).

However, it's also possible to use the keys without the metadata, isn't it?

If there are no metadata, it will be just kept in zone untouched.

Then everything is OK

mentioned in issue #171 (closed)

It may happen that there is already NSEC3PARAM in the zone and an UPDATE tries to add another one. There are 3 possible solutions:

1. Add the NSEC3PARAM to the zone and create second NSEC3 chain. This is not desirable, as it is not known what NSEC3 chain the user wants to use for answering and only one may be "active" in any time.
2. Replace NSEC3PARAM in the zone. This may be desirable, but it is not very straightforward and such behaviour is not defined anywhere in RFCs (AFAIK).
3. Ignore the incoming NSEC3PARAM. If the user wants to replace NSEC3PARAM, he still remove the previous one and add the new one in one UPDATE.

We chose the 3rd option as it is the most intuitive.

Seems to be finished (see !138 (merged)).

Status changed to closed

mentioned in issue #185 (closed)