On Tue, Apr 26, 2016 at 5:13 AM, Matthijs Mekking <matth...@pletterpet.nl> wrote:
> All, > > Matthijs thanks for the review sorry for the delay in response. > I have read it and I like it. Still there are I think some things that > need to be addressed: > > - On enabling DNSSEC via CDS/CDNSKEY: most of the policies assume some > sort of communication channel between the child zone operator and parent > zone operator, while in fact RFC 7344 registers new resource records > because we assume there is no such channel. CDS/CDNSKEY records are put > in the child zone to signal the desired DS RRset in the parent. The > child can only hope that the parent will pick it up and the only way to > get confirmation is to query the parent zone. So how would the parent > "send a notification requesting a confirmation" (section 3.2) or > "instruct the requestor to insert some record into the child domain" > (section 3.4)? > Ok the current text is sub-optimal added: "for example by sending email to the registrant requesting a confirmation." > > It could use the same CDS approach and put it in some new resource > records in the parent zone (just stick it in the DNS ;)). > That is even bigger change :-) sorry no go > > Anyway, if we assume there is no other communication channel, the > document should provide more details on where to put this notification > or challenge such that the child can pick it up. If we say there is a > different communication channel, there needs to be more details about > how that channel looks. Or we should just keep saying it is a hard > problem and leave it out of scope (and solve it in yet another document). > In general we envision three confirmation approaches - A proof of change control of zone by requesting record insertion (covered) - A delay in acceptance, i.e. a stability check (covered) - A email to registrant asking for confirmation. (just added) While there might be more this is all we envision. > > - On using 0 as the DNSSEC Delete Algorithm in CDS and CDNSKEY records, > I think that is fine and is a cleaner approach then using a non-zero > algorithm number. The document could perhaps make it explicit it is > meant only to be used in CDS and CDNSKEY records, not DS/DNSKEY. > done > > - The document suggests that when disabling DNSSEC, only the fixed > fields should appear in the records. Do you mean fixed length fields? > changed "fixed fields" to "exactly the fields" > > - Leaving out the Digest/Public Key field changes the definition of the > CDS and CDNSKEY records: No longer are their formats identical to the > DS/DNSKEY records. So at minimal this updates RFC 7344. Existing > versions of DNS server that support RFC 7344 will likely not be able to > load a CDS record as described in section 4 and consider it malformed. > Good point, making this clearer in text > > > Finally, two nits: > > - Nit: The abstract gives the reader the feeling that initial trust is a > very hard problem, but then section 1.2 says it can be easily solved > with some simplifying assumptions :) Perhaps you meant to say that it is > hard to solve technically unless some reasonable policies can be assumed. > > - Nit: The first use mentioned in section 2 is just KSK Rollover. What > does explaining the different operations add to the document? > > Basically setting the stage and expectations > > Best regards, > Matthijs > > > thanks again Olafur
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
