Having quickly read the -01 for Automating DNSSEC delegation trust maintenance:
I'd like to propose a twist. Comparing to X.509, a CDS record is kinda sorta like a key signing request. For that reason I want to see an explicit "request" in the RDATA and not have anything implied. I would suggest that the RDATA of it *not* be the same as the DS record. There should be an explicit RDATA element instructing the parent what to do with the request. Probably some other ancillary data will be needed too. I would not specify how the parent "discovers" the CDS. Just as for AXFR, knowing how AXFR works is different from why it is called. I say this because in some scenarios I can see the parent scanning the children and in others there will be an event driven reason to look for the CDS set at a child. In some cases "scraping" is optimal, in some cases "explicit" is optimal. The CDS has to do this: 1. Let the parent know whether it is a request for new DS records or whether this is a request to delete DS records. (Plural referring to the fact that a SEP might have more than one DS record.) 2. Let the parent know when this request was first posted (so that the parent can tell if it did this one before). I.e., a 32 bit timestamp viewed as a yyymm-etc. like the RRSIGs do. Or it could be the serial number of the zone when the request was added (although that might be hard for a tool to determine). But - goal is - something to let the parent know when this request appeared so that the parent can guess whether it has already responded to it. 3. Let the parent know the RDATA of the DS records that are desired. What #3 hints at is the case where DS records are requested for a DNSKEY that is not (yet) published in the child zone. There is a DS record in the root zone for a ccTLD that points to no existing record - an example that this is done. I'd like to see one CDS per DNSKEY state change. It is up to the child to groom the CDS set, that is, once the parent has granted the request (which can be seen by asking the parent) the child has the onus to remove the CDS - but as protocol designers we have to account for the case where a child does not remove a CDS (ever), and might in fact have a CDS to add a key and another to delete the key. Other considerations. I left off "urgent" or "due time" because those features generally are overkill. For urgent matters, that falls under the "why" category and not the "how" category. And "how" is what we need to define. For example, a zone has KSKs with footprints/ids of 11111 and 22222 and is flipping to the latter: zone.tld. 1800 IN CDS DELETE 20130201000000 11111 7 1 DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7 zone.tld. 1800 IN CDS ADD 20130201000000 22222 7 1 DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7 The hash in the DELETE is over kill. Perhaps for that just the footprint is needed (unless you want to delete one or the other hash only). Here's a meltdown case that I want to smooth over (with hashes elided): zone.tld. 1800 IN CDS ADD 20130201000000 22222 7 ... zone.tld. 1800 IN CDS DELETE 20130301000000 22222 ... In this case, the child forgot to remove the add request when it decided to do the delete. (No intention of allowing the timestamp to be a schedule - even though I show a future date in the example, I did that just for convenience.) The parent should know then to delete what it has for 22222, whether or not it ever added the DS. (E.g., if the two records popped up together with the same timestamp.) PS - looking at the email addresses for the authors: so it is true, Warren and George are the same person!
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
