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. 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. I am also worried about DNSSEC failures resulting from botched changes of domain hosting or ownership. Not sure what to say about that. 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 don't understand the diagram :-( 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. 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. 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. 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. Section A.1: Worth mentioning unbound-control insecure_add and insecure_remove? 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
