dnssec - basic automatic signing

This covers core functionality, no twiddles.

Zone signing

Signing NSEC/NSEC3 RRSets on the first run (see #103 (closed)) Signing SOA (see #103 (closed)) Removing standalone RRSIGs Removing standalone NSECs (and their RRSIGs) Merged branch-1.4prep (with dname-refactor) => RRSets should be ordered now In delegation points, sign only DS and NSEC, in non-authoritative nodes sign nothing @jkadlec Add 'force sign' functionality Add validity check function for supported signature families @jvcelak

Key management

Searching for keys in keydir requires 'K' at the beginning and '.private' at the end of the filename. Discuss what is the best solution (no name checking?) and modify. @jvcelak Now it's required that all DNSKEY records are inserted into the zone by hand before signing. Knot does not add any of the keys used for signing but does not check if all keys loaded from keydir are already in the zone file. Thus it may happen that the zone is signed by more/less keys than present in the zonefile. Think of and discuss a better solution (use all keys, but add the missing ones to the zone / use only those that are present in the zone file / something else). @jvcelak The DNSKEYs inserted in zone are not checked either, so it may happen that the key in the zone is not the one the zone is signed with. @jvcelak Determining whether to sign with NSEC3 is now done by detecting NSEC3PARAM record in the zone, maybe it could be done by distinguishing the key algorithm code? @jvcelak Configurable signing policy (at least globally, at least signature life time) @lslovak

TODOs until 1.4.0

Writing used keys to the zone. @jvcelak Fix signature validity check - the signature cannot be generated again, it would not work with DSA. @jvcelak Do not allow keys with identical keytags. @jvcelak Find out how does BIND behave with automatic signing after load and reload. @jkadlec What about multiple NSEC3 chains - find if there is some use case and how the server should behave. @lslovak Check removing standalone NSECs at parents of wildcard nodes. @lslovak Update user manual with info about DNSSEC - mention it as an experimental feature. @jvcelak Turn on signing after DDNS (resign whole zone for now, we'll not have time for a better solution for now) @jkadlec Fix NSEC generation - not all nodes need NSEC, reconnect NSEC chains after removal @jkadlec Find out if NSEC3 suffers from the problem above (probably not) @jkadlec Plan zone resigning, sign the whole zone for now @jkadlec Key algorithm must be compatible with used NSEC version @jvcelak Check whether the zone data lock in zone_dnssec_ev() is necessary. @mvavrusa

TODOs after 1.4.0

What about Opt-out? How is it managed in BIND (in the server and in the signzone utility), how is it configured? Write ideas about complex key management, automatic rollover, etc. @jvcelak Think about clever signing of modified parts of zone after dynamic update and for zone resigning.

Fixed a lot of leaks, mostly from missing cleanup. Valgrind still shows some reachable blocks at exit, mostly from key creation in create_pkey(). Will resolve later.

Just a note so that we don't forget:

• When a signed RRSet changes, erasing its RRSIG and resigning is not enough to keep the zone up-to-date for slave servers, since we need to send both new RRSet and its new RRSIG to slaves. Unfortunately, checking whether RRSIG is valid is insufficient in a case when RRSIG is outdated and RRSet changed. When this happens, there's no way to tell whether RRSet changed, we'd need an old zone for that. This brings me to a similar issue:
• Currently, we sign all RRSets in zone, even delegations without DS, which does not make much sense. Also, changes in these nodes will not be detected, when we fix this.

There might be two solutions to these problems:

• Always run zone diff before online signing (a safe bet, albeit slow)
• Merge zone diff and signing together somehow

Or we could force enable ixfr-from-differences when online signing is enabled (maybe silently). Thoughts?

(moved to issue description)

The current implementation of merging and storing changesets by JK is wrong: first the merged changeset is stored to disk and if the application of the DNSSEC changeset fails, the changeset remains in the journal. The process must be divided into store and commit phases as it is done after XFR. (DDNS is different as the changeset is not applied to the zone, the changes are made during packet processing.)

(moved to issue description)

Problem: if the zone is changed on the disk, but user does not increment serial, the zone is loaded, no changeset is generated from differences (this was desired behaviour until now, there cannot be a changeset without serial change), but the zone is resigned and a changeset is generated. Is this also a required behaviour?

Probably if user changed the zone file without changing the SOA, he does not want the change to be propagated. Should the DNSSEC changes be propagated in such case? Or he is just fixing something. What about that case?

Maybe the safest way would be to totally ignore changes to zone when serial was not changed (i.e. not even load them into the server). Or to do so only in case DNSSEC is enabled for the zone and in other cases go with just the warning.

What do you think? @jvcelak

Found out several NSEC-related issues (maybe also NSEC3 related):

• NSEC records are created also for non-authoritative names (below delegation points). This is wrong, see RFC4035, section 2.3:

Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address
RRsets.

• NSEC RRs are created for empty non-terminals. Also wrong (see 2 comments above).
• Next domain name is thus also set wrong (though well in terms of the chain) - it should skip non-authoritative nodes and empty non-terminals.
• If user removed all RRSets from a node, except for the NSEC (and possibly its RRSIG), the signing process removes the remaining NSEC (and changeset application later removes also the node, if it's not an empty non-terminal), but the previous NSEC still has the removed NSEC's owner set as Next domain name.

This is quite a lot of things to fix, so I pass it to @jvcelak or @jkadlec.

Also, consider if some of these problems do not apply also for NSEC3.

Changes made:

• SOA serial is always incremented when the zone is signed. No problem there, the merged changeset takes the serial given by user and increments it. There are some not very nice hacks around it to ensure that the individual SOAs get deallocated properly.
• The merged changeset is now saved in store-apply-commit sequence. This ensures that changes are not saved to journal if something went wrong. There is still one problem about this - we apply only the DNSSEC changeset and even if it's wrong, the changeset from zone diff should be saved to the journal. Please, look into this. The best would be, in case that DNSSEC changeset application fails, the original changeset from zone diff is stored. There is a catch - in the moment when the DNSSEC changeset is applied, we do not have the original changeset from zone diff anymore, as it have been merged. I've tried to create a new merged changeset when dealing with the previous problem, but it's not possible as the original list would still be modified (by appending the other one). It's still possible to duplicate the lists, but that's a lot of allocation... don't know what'd be best.

There are still the problems related to NSECs (and possibly NSEC3s) as mentioned above. It shouldn't, however, be too difficult, just skip the nodes which shouldn't have NSECs when iterating over the zone tree. Fixing these problems will also fix the current problem with signing the zone indefinitely on server restarts (first signing generates NSECs in nodes where they shouldn't be, another signing removes them, as I've already added the check, so yet another signing generates them again, and so on).

As for multiple NSEC3 chains, I've found no use for them. Switching NSEC3PARAMs can probably be done in one step in server operation.

I agree about the storing of diff changeset - we could achieve this working directly with the journal (rewriting the changesets in it), or we could just mark the last RRSet in diff changeset and stop the application when we get to it (we could either disconnect the lists or code some ad-hoc apply function, I'd vote for the first solution) - I'll look into this if there's time before release, but I don't think this is that crucial, since DNSSEC applying should seldom fail.

I decided to make Knot more strict when determining allowed key algorithm to be used with NSEC than ISC dnssec-signzone.

See commit ba2cb05a for details, explanation is in the commit message:

Key algorithm and used NSEC type must match:

RFC 5155 states, that for compatibility with old resolvers, NSEC3
must be used only with NSEC3 algorithms.

It makes no sense to sign NSEC with NSEC3 keys, because it will make
the validation impossible on NSEC3-unaware resolvers. This is stricter
than what dnssec-signzone from ISC does.

New algorithms (RSA >=256, ECDSA, GOST, ...) must work both with NSEC and NSEC3. Therefore the previous restriction is wrong. NSEC3 algorithms should work with NSEC.

Fixed in 75e1200f

Review current implementation in review-dnssec branch, post comments to MR !66 (closed).

As for my tasks:

What about multiple NSEC3 chains - find if there is some use case and how the server should behave. -- There should be no use case. At least I didn't find any. Check removing standalone NSECs at parents of wildcard nodes. -- Should be OK in all cases. Though, it would be nice to have tests for all such special cases.

Status changed to closed

Status changed to reopened

Documentation notes:

• dnssec-enable and dnssec-keydir belongs to zones section but its documentation is under A.1, which is the system statement. Move under A.7.
• Missing example of dnssec-enable option in zones and zone sections and dnssec-keydir in zones section.
• Missing example in knot.full.conf and knot.conf.5.in.
• Some minor grammar issues.

I already corrected all these, but feel free to check it after me. Possibility to set signature lifetime is not mentioned yet, please add it to the Signing policy section. @jvcelak

Question for discussion: what should be an example key directory in knot.full.conf and in man page?

I also stumbled upon problem with DNSKEY policy. AFAIK it goes like this:

• All DNSKEYs which are in the keydir but are not in the zone file, are added to the zone file.
• All DNSKEYs which are in the zone file and are not in the keydir are removed from the zone file.

The first point is OK, but should be mentioned in the documentation. The second one is problematic as it does not allow presence of DNSKEYs which are not used for signing. That is, however, required for pre-publish key rollover. There are two ways to handle this:

• Use only the intersection of DNSKEYs in zone file and those in keydir for signing.
• Use all keys from keydir for signing, but allow other DNSKEYs in zone.

Documentation:

• I intentionally didn't put the DNSSEC settings into example configuration file as the format might change. But I can do that, no problem.
• The same for examples in documentation, I put it on one place into separate section.
• Yes, I will add signature lifetime configuration.

As for key dir, I like ${storage_dir}/keys.

DNSKEY policy:

• I think that these issues are mentioned in documentation.
• I can add support for "publish/delete" timestamps for key files and use it when publishing the DNSKEYs, that shouldn't be very difficult. (I must not forget about adding this into signatures refreshing.) We discued the "unknown" DNSKEYs quite firecely on Jabber, and I think that we finally decided to remove them.

Anyway, what is the purpose of pre-publishing the key when we can already publish it with signatures? To save some space for large zones, or what?

Things to discuss, differences between BIND and Knot:

If you turn the inline-signing option on, BIND is able to track changes to the initial text zone file and sign them, HOWEVER, it ignores changes made to the serial completely, and always uses its own serial and it does not do this upon reload, only when you turn it off and on again (it stores a binary zone to an extra file (DNSSEC changes are in an extra file as well I believe), so it knows the difference between old zone it had in memory before shutdown and edited zone file.

So, we should decide whether we should: (for upcoming versions, not now)

• Ignore changes to SOA serial and manage it ourselves.
• Create differences also after restart - this could be possible, if we had binary zone dump.

Last documentation notes:

• Section 4.10.4 Zone signing: Throw out: 'This also means removing all keys which are not present in directory with signing keys.' and mention that any keys present in keydir and not in zone file, are added to the zone file.
• Add dnssec-keydir example to A.7.3 - zones Example.
• In knot.full.conf in zones section, I would set dnssec-enable to off, or put it in a comment. It is useless without dnssec-keydir anyway.

Unknown DNSKEYs are kept in zone unless they have same keytag as any other known key, but different RDATA.

4518abbb

Closing, let's create issues for individual features.

Status changed to closed

mentioned in issue #157 (closed)

mentioned in issue #211 (closed)

mentioned in issue #217 (closed)

mentioned in issue #359 (closed)

mentioned in issue #367 (closed)

mentioned in issue #428 (closed)

mentioned in merge request !616 (merged)

mentioned in issue #496 (closed)

mentioned in issue #741 (closed)

mentioned in issue #871 (closed)