Hello, somewhat more words but in line with what I was suggesting, a couple of days ago, about adding "operation code" to CDS RDATA.
This still feel like a good idea, worth elaborating, I'd see. I support this. Kind regards, Marc Lampo On Thu, Feb 28, 2013 at 7:56 AM, Edward Lewis <[email protected]> wrote: > 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 > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
