At Thu, 24 Apr 2014 07:55:52 +0200, Matthijs Mekking <[email protected]> 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: > 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: 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) 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) 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) 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. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
