Create CDS/CDNSKEY

[jschlyter]

I need to create CDS/CDNSKEYs and support for this directly in dnspython would be nice. A couple of ideas:

• Add from_ds() method on dns.rdtypes.ANY.CDS (and similar for DNSKEY). Implemented in DSBase and DNSKEYBase.
• Add cds_from_ds() and cdnskey_from_dnskey() functions.
• Add option to make_ds()/make_dnskey() to return CDS/CDNSKEY instead of DS/DNSKEY.

Perhaps there's an even easier option?

[rthalley]

This one is tricky!

Let's look at the likely use cases, and consider offering higher level support:

CDS: The authority has a DNSKEY RRset/Rdataset and wants to generate the matching CDS RRset/Rdataset. This gets published, and then the registrar is going to want to do CDS -> DS as part of updating the registry. This makes me think we want something like make_ds_rdataset() in dns.dnssec for this job, and that it should take a DNSKEY or CDNSKEY RRset or (name, Rdataset) tuple and a set of all the DSDigest algorithms you want too. It would also take the type you want it to make. It would return an Rdataset, so no mypy typing issues there. We let you give either DNSKEY or CDNSKEY for the CDNSKEY use case (below). I guess you'd need a cds_rdataset_to_ds_rdataset() function too for the registrar.

A factory option to make_ds() is appealing as the helper the new function would use, but released versions of dnspython published the return type as DS, so this would be an incompatible API change, which we don't do if at all posible. Perhaps we'd have a _make_ds with a factory parameter to say whether it returned DS or CDS, and then have make_ds() and make_cds() call it appropriately and cast the result to the right type.

CDNSKEY: The authority has a new DNSKEY Rdataset that they want to publish. I say DNSKEY as they will need the DNSKEY at some point, and it's pretty natural to start with it rather than converting a CDNSKEY into a DNSKEY later. They need to generate the appropriate CDNSKEY Rdataset from it, so dnskey_rdataset_to_cdnskey_rdataset(). Again because this is an Rdataset-level operation, it seems like dns.dnssec is the best place for it. We could have a dnskey_to_cdnskey() helper for the rdata level that would just invoke the CDNSKEY constructor, as calling make_dnskey() would be more work. The registrar then needs to do CDNSKEY Rdataset -> DS Rdataset, so they'd just use make_ds_rdataset().

[jschlyter]

Sounds resonable. I'll start some work as part of my CDS scanner and see if this fits the bill. Do you prefer working with a Rdataset as input/output, or with a RRset?

[rthalley]

I tend to prefer Rdataset, so try that!

[jschlyter]

Some initial work in #872

[peterthomassen]

They need to generate the appropriate CDNSKEY Rdataset from it, so dnskey_rdataset_to_cdnskey_rdataset(). Again because this is an Rdataset-level operation

Note that in general (and also rather typically), not all of the DNSKEYs will be reflected in the CDNSKEY dataset. In particular, ZSKs, experimental keys or keys endorsed by trust anchors not rooted in the DNS will not make it into the DS record set, and thus are not reflected in the CDNSKEY RRset.

The conversion from DNSKEY Rdataset to CDNSKEY Rdataset should somehow account for that. (Checking the SEP bit is a good heuristic, but its presence is not a sufficient condition [and arguably also not a necessary one].)

[jschlyter]

Agree, but one can of course filter the rdataset before feeding it into the conversion function. I can see if I can add a test case for this.

[rthalley]

Note I made a few edits after my initial response, so read the discussion on GitHub not email.