DNSSEC DS vs DNSKEY record publication order question (wrt key algorithm rollover)

Tony Finch dot at dotat.at
Thu Jan 17 15:18:23 UTC 2013


Brian Kroth <bpkroth at gmail.com> wrote:
>
> For instance, suppose I did the following:
>
> - gen new algorithm keys and sign with them
> - wait for some period then publish the new DS (old DS remains)
> - revoke the old algorithm KSK (leave the ZSK alone), which changes its   DS
> fingerprint, so publish a new DS

It doesn't make sense to have any records that refer to a revoked key,
other than its self-signed RRSIG which confirms the revocation.

> However, if I'm reading things correctly, then the REVOKE bit really just
> governs automatic trust-anchor updates for clients that support that
> mechanism, but the key is still usable for validating at the very least
> itself, if not also other RRSIGs (eg: for compatibility with clients that
> don't understand the REVOKE bit and have another trust anchor to work off
> of?).

Right.

> In looking at an example, dnssec-signzone still signs a DNSKEY record which
> includes the old algorithm's ZSK for that zone, so I think there's still a
> valid chain of trust, and the same RFC 6781 4.1.4 note applies.

You need to be clear about whether there are signatures with both
algorithms or not. Because all the DNSKEYs form a single RRset, they will
all be signed with all algorithms. It is an error to have a DNSKEY RRset
that includes keys with an algorithm that doesn't sign the RRset - the
chain of trust does not cross over between algorithms except at DS RRsets.

> If this is true, then the only way to actually complete the algorithm rollover
> is to just drop the algorithm from the DS records once the new algorithm is in
> place, but before actually dropping the RRSIGs and DNSKEY records for that
> algorithm, correct?

Right.

> [1] I guess I should have mentioned that basically I got stuck with a system
> with a deficient dnssec implementation on 100+ zones that are generated from a
> db via perl, so I was really hoping in the course of fixing it up to to get to
> something where I (or the person behind me) could just change $ALG =
> 'NEW_VALUE' and have it complete the rest of the steps as necessary, even if
> some of them were just "compare expected vs. seen DS and generate an email to
> tell people to push things up stream when they need to be updated".  Now, it's
> looking more and more to me like some of this just isn't possible to automate
> well.

Best attempt I have seen so far is
http://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.



More information about the bind-users mailing list