Subject: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 09 Jul 2015 05:16:40 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-negative-trust-anchors-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In an ideal world, my YES ballot for would really be "YES,
sadly I suppose we need this kind of thing but wouldn't life be
much better if DNSSEC was much easier to deploy, ah well, too
late now I guess:-(" 

- section 1.1: Where is the definition? I see you telling me
what an NTA isn't, but not what it is. I think what you want to
say is that an NTA is a domain name or a pair (a domain name
and a sub-domain of that) represented in a resolver
implementation-specific manner so that DNSSEC validation is
turned off from the higher domain name down (to the subdomain
if we have a pair). Is that right?

- 1.1: RFC5914 is a little misleading as a reference as that
was done for X.509 stuff and is nothing to do with DNSSEC.
Maybe it'd be worth pointing that out just in case some reader
somewhere goes and gets confused.

- section 2: what do you mean happens "once per quarter"?

- section 2: "immediately restores" - well that depends on the
screw-up doesn't it? Or are you saying (where?) that an NTA
must only be put in place when the screw-up is specifically and
only about and because of DNSSEC and where ignoring DNSSEC will
result in things "working"? For example, DNSSEC could fail
because all my nameservers are entirely offline due to a f/w
mis-configuration that blocks loads of port 53, but putting in
place an NTA won't help then. (As it happens, I'm right now
gettting a f/w to re-unblock 53 so I can serve some DNSSEC
records so this issue is one that's close to the bone for me:-)

- Section 6: 1st 2 sentences repeat repeat dnssec-failed.org
too too many times.

- random question: why not have an "I'm just testing" RR that I
could put in alongside my ZSK DNSKEY as I start to play with
DNSSEC? Or maybe that exists already.

---

From: [email-masked] (Paul Ebersman)
Date: Mon, 20 Jul 2015 16:26:45 +0200

sfarrell> - section 2: "immediately restores" - well that depends on the
sfarrell> screw-up doesn't it? Or are you saying (where?) that an NTA
sfarrell> must only be put in place when the screw-up is specifically
sfarrell> and only about and because of DNSSEC and where ignoring DNSSEC
sfarrell> will result in things "working"?

Yes. This only addresses validation failures, not server/infrastructure
failures.