On Fri, Feb 1, 2019 at 1:35 PM Tony Finch <[email protected]> wrote: > I'm working on tools for KSK rollover automation at the moment. > > It turns out that CDS records are very useful even if your parent zone > doesn't check them. > > KSK rolls work better when the DS records are not simply generated from > the current DNSKEY RRset. You need to be a bit more clever if you want to > minimize interactions with the parent zone, or minimize the DNSKEY RRset > size, or do an algorithm rollover. > > So your tool for setting DS records needs some way to ask the key store > what DS records should be. The nice thing about CDS records is that they > provide a standard way to do this, independent of the key store or signing > software. This allows registrar API clients to be decoupled from the > DNSSEC implementation. > > This makes me wonder how well this observation generalizes to > multi-provider DNSSEC. >
Sorry for answering this message so late. I'm in Prague for IETF104 and am gradually catching myself up with miscellaneous mailing lists .. > In model 1, the zone owner manages the KSK, so all the CDS/DS logic > remains centralized. > Yes, that's true. However, for automated CDS->DS updates, the zone owner still needs to propagate the CDS (or CDNSKEY) down to each of the signing providers. Since CDS/CDNSKEY are signed by an active KSK (that is managed by the zone owner), the providers will still likely need to provide an API that allows a signed CDS/CDNSKEY RRset to be pushed to them. This is analogous to how the current draft requires them to support an API mechanism to have a signed DNSKEY RRset pushed to them. In model 2, each DNS provider has its own KSK, and does its own DNSKEY > RRset management. In order to support CDS/CDNSKEY, I think it is necessary > for each provider to (somehow) generate RRsets that are the union of their > CDS/CDNSKEY RRsets and the other provider's. > > In normal cases, I think the "somehow" involves getting the other > provider's RRset, replacing any records corresponding to this provider's > keys with what this provider thinks they should be, and retaining any > records for unknown keys (which presumably belong to the other provider). > There's a mildly awkward risk of zombie records that are copied back and > forth despite neither provider knowing about them, but I suppose that can > be fixed manually if it arises. Or maybe it's simpler if this is done via > an API, like ZSK sharing :-) > I am in agreement with your last statement. We might as well extend the ZSK sharing API to also include CDS/CDNSKEY sharing. The risk of potential zombie records also exists with the DNSKEY RRset, and I expect that would be addressed by active management by the zone owner. Or, post bootstrapping, active pollling of providers by one another. Shumon
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
