Subject: Re: [DNSOP] [email-masked]

From: 神明達哉 <[email-masked]>
Date: Fri, 1 May 2015 11:25:25 -0700

At Fri, 24 Apr 2015 23:59:22 -0400,
Warren Kumari <[email-masked]> wrote:

> So, I have gone back through previous mail and it seems that this was
> the only email that got missed.
> Anyway, it seems that other folk also made similar comments, and so,
> by -03, we had addressed almost all of them.
>  Apologies again for not seeing and responding to your mail.

No worries, and thanks for addressing these so quickly.

> >   I agree with the sense of the statement, but specifically how can
> >   the operator confirm that it's misconfiguration? [...]
>
> My last update (a few days ago) included inserting an Appendix that
> covers some of this. It is somewhat rough,and more conversational in
> tone than if it were in the main part of the draft, but I think
> strikes a nice balance.

Do you mean Appendix B?  It certainly looks good enough to me to
address this point.

> > - Also on that sense and this one in Section 8:
> >
> >    Use of a
> >    Negative Trust Anchor MUST NOT be automatic.
> >
> >   Again, I agree with the sense, but I wonder whether players like big
> >   ISPs or public DNS services are really willing to follow the
> >   suggestion of human intervention and/or ban of automation.
[...]
> >   For these recommendations to be really effective rather than just
> >   ignored, I think we need to provide some more information, e.g.,
> >   statistics on how often these events are happening in actual
> >   providers that use NTAs, show example of operational practices
> >   (which I guess would include some level of automation).
>
> We don't really have anything published, but I spoke with the person
> who deals with these and it is around once per quarter (it has slowed
> down). This year we have only done it once - for the .KE keyroll event
> ( thread here: https://lists.dns-oarc.net/pipermail/dns-operations/2015-March/013060.html
> )

Okay, then I'd suggest adding some brief note on this point.  One
possibility would be to add something like this to the end of the
first paragraph of Section 2:

   [... prior to implementing the Negative Trust Anchor.]  Involving
   trained technical personnel is costly, but operations experiences
   so far suggest that this is a very rare event such as around once
   per quarter or even less.

(and if we can include a concrete reference, do that)

> > - Also on Section 8:
> >
> >    Finally, a Negative Trust Anchor SHOULD be used only in a specific
> >    domain or sub-domain and MUST NOT affect validation of other names up
> >    the authentication chain.
> >
> >   I think it would also help clarify that the deepest anchor should be
> >   used, whether positive or negative. [...]
>
> Actually, an NTA stops validation at that point, which includes things
> under that.
> Here is text (which probably changed after your comment:
> "This Negative Trust Anchor can potentially be implemented at any
> level within the chain
>  of trust and would stop validation from that point in the chain down."
>
> This gave us the needed behavior when .ke broke...
> Yes, turning off validation for an entire ccTLD is a big hammer --
> but, it is better than turning off validation for *everyone*, or just
> leaving an entire country unresolvable for many hours....

Hmm...first, if this is really the intent, I'd suggest revising
Section 8, too, to state it more explicitly (also possibly with an
example).

Secondly, does it make most sense?  If we have a manually configured
positive trust anchor for "good.example.ke", isn't it better to still
use it for anything on or below that, but skip DNSSEC validation for
everything else on or under .ke?  At least this shouldn't mean
"turning off validation for *everyone*" or "just leaving an entire
country unresolvable for many hours", so such arguments don't seem to
be a reason for not doing this.

> > - Section 10
> >
> >    validates can have security considerations.  It is therefore
> >    recommended that NTA implementors should periodically attempt to
> >    validate the domain in question, for the period of time that the
> >
> >   I wonder whether this 'should' may better be SHOULD.  Not a strong
> >   opinion, but it seems to be similar to other recommendations using
> >   the capitalized keyword in Section 8.
>
> So, I went to go make that change, and discovered it is already a SHOULD.
> Sometime between when you wrote this mail (11/14) and version -03 I
> incorporated this change.

It's still a "should" in the 04 version:

   validates can have security considerations.  It is therefore
   recommended that NTA implementors should periodically attempt to
   validate the domain in question, for the period of time that the
   Negative Trust Anchor is in place, until such validation is again
   successful.
(from https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04)

> > - Appendix A: not intending to endorse a particular implementation(s),
> >   but I'd suggest clarifying which specific implementations support
> >   various recommendations of the draft.  For example, BIND 9 is quite
> >   diligently follow it while (if my memory is correct and it's still
> >   the case today) unbound's support is quite primitive and you cannot
> >   specify timeouts.  I think it's important to avoid allowing lazy
> >   operators to just configure some NTAs and forget them.  It would
> >   also encourage "lazy developers" to support full recommendations
> >   sooner.
>
> I'm a little uncomfortable doing this. This is still only a draft, and
> vendors will continue to add support when it gets published as an RFC.
> I'd hate vendor X to add support for all the rest of the requirements,
> but have customers discriminate against them because the RFC didn't
> predict that...

Okay, then I won't push that.  But I'd like to suggest adding some
more general note like this to Appendix A:

   Please note: These are simply examples - nameserver operators are
   expected to test and understand the implications of these operations.
   Note also that some of available implementations may not implement
   all recommended functionality in this document.  In that case it is
   advisable to request the developer or vendor of the implementation
   to support the missing feature, rather than start using the
   incomplete implementation.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 May 2015 12:09:53 -0400

> Do you mean Appendix B?  It certainly looks good enough to me to

Yup. Excellent!

>    per quarter or even less.

Will do.

> be a reason for not doing this.

Ah! I've just realized that I'd misunderstood your question -- I'd
somehow completely skipped over the "whether **positive** or negative"
(emphasis added). This isn't a very common case for us, and so I'm not
sure that the authors have discussed it.

The way that our resolver works is the most specific ("deepest") TA
would win, so, assuming that we had a positive TA for good.example.ke
it *would* override the NTA for .ke.

I personally (and I think you as well) believe that this makes the
most sense, but let me double check with co-authors.
Whatever the case, we don't actually address this in the document, and
it should be....

> It's still a "should" in the 04 version:

Will fix.

> more general note like this to Appendix A:

Will do!

-- 
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