On 11 apr 2014, at 23:12, Warren Kumari <war...@kumari.net> wrote: > Hi there all, > > At the moment this document says that the child SHOULD remove the > CDS/CDNSKEY record once the parent has consumed / acted on it (this > behavior was requested by someone -- unfortunately I cannot remember > whom). > > I *think* that I'm hearing that folk would prefer that the child > SHOULD leave it in, or, less strongly MAY remove it. > > This (IMO) makes the doc and the child's life simpler, but potentially > makes a bit more work for the parent -- currently most of the > time the parent will see no CDS, and so will go back to sleep. If the > child leaves them around, the parent will need to check them against > what is currently published and take action if they differ. > > Can folk please let us know if they would prefer: > A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the > parent has published it (currently documented behavior) or > > B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a > small edit to the doc) > > My personal preference is for B - it seems more elegant, but (as > always) we'll do whatever the WG wants.
Let me try to explain in a neutral way what I see as an issue: As I am one of the persons that have rised the issue that we must be extremely clear on what we thing is ok here, let me explain the situation I am looking at, and that is how things work when child want to do a key rollover. I.e. child has for example DS foo and want to swap to DS bar. This implies having CDS for foo ate some point in time, CDS for foo and bar at some interval and then CDS for bar at some point in time. I.e. both add bar and remove foo. This is, I think -- but can be wrong, much easier if CDS foo is in the zone all the time DS for foo is to be valid, and then CDS for bar is in the zone as long as the DS for bar is to be valid. Example below is for CDS because it is shorter to type, but can be valid for CDNSKEY as well of course (and yes, Antoine has convinced me as well that DNSKEY is the path forward...;-) ). The argument for me is that if CDS is removed, then we have: 1. Add DS foo 1.1. Add CDS foo 1.2. Remove CDS foo 2. Add DS bar and remove DS foo 1.2. Add CDS foo 2.2. Add CDS bar 2.3. Remove CDS foo 2.4. Remove CDS bar I am here nervous over the parent detecting 2.4 before 2.3, and the wrong DS is removed. Note that the last DS is never removed if the last CDS is removed from the zone. And the parent still must detect when CDS foo is added that that is already in the parent zone, and no action is needed. If the CDS stays in the zone, we have: 1. Add DS foo 1.1 Add CDS foo 2. Add DS bar and remove DS foo 2.1. Add CDS bar 2.2 Remove CDS foo So I am in favor of B. Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
