Dear DNSOP, RFC 7344 describes DS rollovers using CDS/CDNSKEY records. It does not prescribe how the CDS/CDNSKEY records should be retrieved. On the contrary, it is fully left open (Section 6.1):
How the Parental Agent gets the CDS/CDNSKEY RRset may differ. Below are two examples of how this can take place. This poses a problem in conjunction with multi-signer setups, which may be gaining traction (RFC 8901, draft-ietf-dnsop-dnssec-automation). The problem is: when the CDS/CDNSKEY are retrieved "normally" using a validating resolver (and then checked as required in Section 4.1), chances are that records are retrieved from one nameserver only (that is, without checking for consistency across other NS hostnames). In a multi-signer setup, this means that a single provider can (accidentally or maliciously) roll the DS record at the parent. IMO the most likely scenario would be that a provider performs a key rollover and then accidentally publishes CDS/CDNSKEY records for its own keys. As a result, the other providers' DS records would be removed from the parent, breaking the zone for some or all queries. Regardless of whether that's likely to happen or not: a single provider should not be in the position to remove the other providers' trust anchors. It is therefore necessary to either (1) require the parent to make sure that other provider's DS records remain available (but there is no reliable way of ascribing them, especially for pre-published standby DS records); or (2) require providers to agree on what are the proper CDS/CDNSKEY record sets, so that any error by a single party is effectively vetoed. I thus propose to update RFC 7344 along the lines of (2), such that it is REQUIRED to retrieve CDS/CDNSKEY records using queries to all authoritative nameservers. Such a change would also prevent CDS/CDNSKEY loops, where one secondary has a replication issue and keeps announcing an old C* RRset (and the parent happens to retrieve alternating information during daily scans, for example). Does the WG think this is a reasonable thing to pursue? Thoughts welcome. Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
