Olafur Please add this. I'll get caught back up on the rest of this by the time warren returns from his walkabout.
Sent from my Hi-Tech Gadget. > On Apr 25, 2014, at 6:48, Olafur Gudmundsson <o...@ogud.com> wrote: > > >> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
