[ Top post ] Thanks for all the comments. I've integrated most of them (need additional text for one), and am posting a new version with the changes.
Comments inline. On Wed, May 6, 2015 at 8:37 AM, Tony Finch <d...@dotat.at> wrote: > I have read through the draft. Looks good. > > Some wording suggestions: > > Section 1.1: > > By way > of analogy, negative trust anchors stop validation of the > authentication chain. Instead, the resolver sends the response as if > the zone is unsigned and does not set the AD bit. > > I suggest: > > Instead, the validator treats any upstream responses as if > the zone is unsigned and does not set the AD bit in responses it sends > to clients. DONE. Thanks. > > > Section 1.2: > > As domains transition to DNSSEC, the most > likely reason for a validation failure will be misconfiguration. > > I suggest: > > As domains transition to DNSSEC, the most > common reason for a validation failure has been misconfiguration. > DONE. Thanks. > I am also worried about DNSSEC failures resulting from botched changes of > domain hosting or ownership. Not sure what to say about that. > Me neither -- but that's a type of misconfiguration? :-) If anyone has suggested test I'm happy to consider it. > Section 2: > > The requirement MUST NOT affect parental domains is fine, but why only > SHOULD NOT for other branches of the tree? I would expect that to be MUST > NOT as well. Is this to allow for someone putting an NTA on a DLV domain > perhaps? I seem to remember it being something subtle to do with delegations, but will check with co-authors / go back through earlier mail. Example.com uses ns1.example.net. example.net borks their keyroll, and we "rescue" them by putting in an NTA. This has affected something in another branch of the tree. > > I don't understand the diagram :-( Fair enough - it *is* confusing. I'll ask one of the other authors to fix it (you *so* don't want me to fix it :-)) > > Section 3: > > Most current implementations of DNS validating resolvers currently > follow [RFC4033] on defining the implementation of Trust Anchor as > either using Delegation Signer (DS), Key Signing Key (KSK), or Zone > Signing Key (ZSK). > > I suggest: > > Most current implementations of DNS validating resolvers currently > follow [RFC4033] on configuring a Trust Anchor using either a public > key as in a DNSKEY RR or a hash of a public key as in a DS RR. > > ... because this is closer to what RFC 4033 says, and from the point of > view of the validator there's no difference between a KSK and ZSK, and > usual practice says you should only use SEP keys (i.e. KSKs) for trust > anchors so mentioning ZSKs here is very unwise. DONE. Fair 'nuff. > > This sentence is unclear: > > A Negative Trust Anchor should use domain name > formatting that signifies where in a delegation a validation process > should be stopped. Yes, that is unclear.... > > Does it mean: > > A Negative Trust Anchor should be configured using a > fully-qualified domain name in RFC 1035 master file syntax, to > indicate that validation should not occur at or below that domain name. DONE. Nope. I don't think that we need to define the format here -- it is (IMO) an implementation detail. I don't really know what the point of the sentence is, but it does't (AFAICT) add anything, and so I'm removing it... Thanks! > > And for: > > Different DNS recursive resolvers may have different configuration > names for a Negative Trust Anchor. For example, Unbound calls their > configuration "domain-insecure."[Unbound-Configuration] > > I suggest: > > Different DNS validators may have different configuration > names for a Negative Trust Anchor. For examples see Appendix A. DONE. Thanks, much better. That was left over from earlier versions... > > Section A.1: > > Worth mentioning unbound-control insecure_add and insecure_remove? NOT DONE. Yes, yes it is. I believe one of the Unbound developers was going to contribute text, I'll follow up with them. Thanks again, W > > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > Hebrides, Bailey: Northerly backing northwesterly 6 to gale 8, increasing > severe gale 9 at times, decreasing 5 later in west Bailey. Rough or very > rough, occasionally high in Hebrides. Occasional rain. Good, occasionally > poor. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
