On Feb 7, 2014, at 12:18 PM, 神明達哉 <[email protected]> wrote:
> At Thu, 6 Feb 2014 14:13:05 -0500, > Warren Kumari <[email protected]> wrote: > >> At time T+3 the child sees that the parent has published the new key >> information ( and the standard keyroll stuff has all happened (records >> are signed with new key, waited for old TTLs to expire, etc)) and so >> wants to remove the old key. >> ** This is, as far as I understand, what you were asking about) > > Yes, and... > >> The child now publishes just the new key info. They stop publishing the old >> one. >> Parent: >> example.com. 300 IN DS 31589 8 1 123456...... >> example.com. 300 IN DS 31589 8 1 789ABC...... >> Child: >> example.com. 300 IN CDS 31589 8 1 789ABC...... >> [ Child is only publishing new record / they stop publishing the old one ] >> >> At time T+4 the parent checks agin (it polls, the human clicks the >> button on the web page, some other trigger happens, etc): >> It sees that what the child has published does not match what the >> parent currently has, and so it copies the contents from the child. >> Parent: >> example.com. 300 IN DS 31589 8 1 789ABC...... >> Child: >> example.com. 300 IN CDS 31589 8 1 789ABC...... >> [ The child and parent are back in sync. The old key (123456...) is no >> longer in use anywhere. ] > > ...this makes sense, and actually matches what I first thought was the > intent of the draft. With this clarification I guess my confusion > mainly came from the first sentence of Section 4.1: > > Absence of CDS / CDNSKEY in child signals "No change" to the current > DS set. > > Now I understand this is intended to mean "absence of CDS / CDNSKEY > *RRset*", i.e., absence of any CDS / CDNSKEY. But it was not super > clear when I first read it and it could also mean the absence > (removal) of this CDS at time T+4 > Jinmei thanks for pointing this out yes you are absolutely right and I have added the word "RRset" into this sentence. I'm reading the rest of the document to make sure we are clear in all places like this one. > example.com. 300 IN CDS 31589 8 1 123456...... > > maybe I was the only person who was confused about this, but it > wouldn't do any harm to clarify the wording. > > My original question is now resolved, but I have now another about the > "absence of CDS / CDNSKEY"... > >> This means that you can use this to update / replace / remove existing >> DS records (if you have keys A, B, C and D and want to stop using C, >> you simply publish A, B, D), but you cannot remove *all* DS records / >> go unsigned. > > This is fine, but technically doesn't it contradict Section 3? > > The CDS / CDNSKEY record is published in the child zone and gives the > child control of what is published for it in the parental zone. The > CDS / CDNSKEY RRset expresses what the child would like the DS RRset > to look like after the change; > > In that, technically, an empty CDS / CDNSKEY RRset should mean the DS > RRset at the parent should be empty. I have no problem with treating > an empty set as an exception, but I think it would help if the draft > explains that more explicitly. > Semantics semantics, No we are defining the semantics to be "IF C* is published parent DS should mirror that, if no C* in child --> parent has no action to perform" > I'd also note that "absence of CDS" (or CDNSKEY) cannot happen once > one such RR is published, and it should mean something erroneous (most > likely an operation error at the child or a bug in its tool). I think > it's worth noting in Section 4.1 Why? Here is a perfectly fine time line <At start parent DS reflects key A and child uses A to sign DNSKEY RRset> Child publishes CDS with A and B Parent updates DS to reflect A and B Child deletes CDS <child performs key roll over from A to B> Child publishes CDNSKEY reflecting B Parent changes DS to reflect only B Child deletes CDNSKEY Do you think it is helpful to add an appendix with some examples of use of C* records ? > . > > Finally, I'd suggest explicitly clarifying that CDS / CDNSKEY cannot > be used for a child from signed to unsigned (since it would have to > remove all CDS / CDNSKEY records to do so). And, I suspect this is a > "MUST NOT", unlike the case of initial enrollment described in Section > 9, because this would break interoperability. > In theory we can use C* to perform the Going-Unsigned operation, and earlier version of this document proposed that, but people objected and we removed that text. We explicitly outlaw going from Unsigned --> Signed w/o some out-of-band validation. Olafur _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
