Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-05.txt

[Tony Finch <[e-mail]>]

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  <[e-mail]>  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.