On Apr 25, 2014, at 2:28 AM, Matthijs Mekking <matth...@nlnetlabs.nl> wrote:
> Hi, > > On 04/24/2014 05:41 PM, 神明達哉 wrote: >> At Thu, 24 Apr 2014 07:55:52 +0200, >> Matthijs Mekking <matth...@nlnetlabs.nl> wrote: >> >>> The child can also signal its desire to remove DS records by removing >>> the corresponding records from the CDS/CDNSKEY RRset again. >> >> ...unless that would make the resulting CDS/CDNSKEY RRset empty. >> Otherwise it can contradict this one: > > Of course. I tried to rephrase it in four short lines. That does not > mean that one line that stands alone is the absolute truth: you have to > consider the complete context. > > >>> If the parent sees no CDS/CDNSKEY RRset published in the child's zone, >>> this means there is no action to perform for the parent. Hence, this >>> document does not support removing all DS records from the parent. >> >> I guess this discussions is essentially the same as what I asked a few >> months ago: >> http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html >> >> and while I thought revised versions of the draft were clear about >> this point, but the fact that we still have this discussion seems to >> suggest it's probably not sufficiently clear. Perhaps the problem is >> that many of us already knows how it works and it's difficult for us >> to see how it could be interpreted by first-time readers. So, while >> it may look redundant, it may help if we show a specific example of >> how the child adds/removes CDS/CDNSKEY and how it works at the parent: > > I am indeed pretty clear about how this should work and I think the > draft reflects that. But indeed: there is nothing wrong with adding an > appendix with some examples. Some remarks below: > >> 0. the child becomes signed from unsigned, tells the parent its >> DNSKEY (say KSK1), the parent has a DS. this step is out of scope >> of CDS/CDNSKEY: >> child.example. DS ....(for KSK1) >> 1. the child adds the corresponding CDS in the child zone: >> child.example. DNSKEY ....(for KSK1) >> child.example. CDS ....(for KSK1) > > The child does not necessarily need to add the CDS now: The parent > already has the correct DS RRset (step 0) and no rollover has happened > since then. > > >> 2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the >> child zone: >> child.example. DNSKEY ....(for KSK1) >> child.example. DNSKEY ....(for KSK2) >> child.example. CDS ....(for KSK1) >> child.example. CDS ....(for KSK2) > > Depending on the type of rollover, the child might not want to add the > CDS directly (Double-Signature KSK Rollover) or might want to add the > CDS before adding the DNSKEY (Double-DS KSK Rollover). > > >> 3. the parent notices or is notified of a change in the child, and >> finds there's a new CDS (for KSK2) that doesn't match its set of >> CDS, and adds a new DS corresponding to that one: >> child.example. DS ....(for KSK1) >> child.example. DS ....(for KSK2) >> 4. the child confirms the DS and CDS are now synchronized, and removes >> the old DNSKEY (KSK1) and corresponding CDS: >> child.example. DNSKEY ....(for KSK2) >> child.example. CDS ....(for KSK2) > > You want to remove DNSKEY and CDS for KSK1 here. > > Again: The old CDS may be removed earlier, at the time of adding the CDS > for KSK2 (Double-Signature) or later (Double-DS). > > >> 5. the parent notices or is notified of a change in the child, and >> finds a CDS (for KSK1) that currently matches one of its DS's is >> now removed. the parent removes the corresponding DS: >> child.example. DS ....(for KSK2) >> 6. the child confirms the DS and CDS are now synchronized. at this >> point, it MAY remove the remaining CDS for the reason explained in >> Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11: >> child.example. DNSKEY ....(for KSK2) >> (no CDS records) >> 7. the parent notices the change in the child, but does nothing since >> there's no CDS record in the child: >> child.example. DS ....(for KSK2) ; still exist >> 8. eventually the child might go unsigned again. all of its DNSKEYs >> will be removed, but the child needs to tell the parent about the >> change and have them remove the DS records in some other way than >> CDS/CDNSKEY. removing all CDS records can't be used since it >> doesn't make any change at the parent as shown in steps 6 and 7. > > Other than that, I think these examples are very clear, and I support > adding them as an appendix. > > Best regards, > Matthijs > I'm willing add an appendix that has Double DS KSK rollover to the appendix with reference to RFC6781 figure 7, as an example. I will think about the dual KSK example. Tim tell me if you DO NOT want this added to the document. Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
