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 > > -- > JINMEI, Tatuya > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
