Ahh, yes. I went back to see your message. I'll address the points in your message here
1) Telling the parent "this is a new KSK and it will have a DS in the future" (code 0) is unnecessary. This is state the parent should not track and not have the burden of tracking. The other two states map to my "ADD" and "DELETE" but in mine I hide semantics (or reasons why). So for the most part we agree. 2) All that is needed is the CDS be signed as any other RRSET. When the parent elects to do so, it would do a query +DO to get the records and hope to see "ad" in the flags. 3) I don't think the parent ought to have to do a periodic check (it's up to the parent). Either way, that doesn't belong in the document. 4) Good question - I would assume that a well-run zone would have in-sync servers. Given that the document assumes the parent could "scrape" this, the concern is understood. But my assumption is that this would be event driven (prompt up the tree somehow) and that lessens the concern of an out of sync server. OTOH, I have the idea that there needs to be some way of tagging the request to get it's freshness. OYTOH (On yet the third hand), there's always out of band ways to ask for a retry. 5) Kind of agree - why not. If the domain name is registered via a method that has a half-dozen pre-delegation checks and credit checks, what more armoring is needed? 6) Ahh, and I thought I was the only one that noticed. (Sorry, Marc, evidently I hadn't read all of your message. ;)) What I have in mind is a smaller definition for CDS, but use it in a way where the client has the responsibility to check whether the parent has granted the request. On Feb 28, 2013, at 15:23, Marc Lampo wrote: > 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 >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
