Subject: [DNSOP] [email-masked]

From: 神明達哉 <[email-masked]>
Date: Wed, 5 Nov 2014 11:31:23 -0800

I've read the draft.  Overall it's pretty well written.  I also
personally support the idea of NTAs; although I see its side effect
and the possibility of abuse, the draft seems to do its best to
explain the implications and avoid abusing.

Here are some specific comments on the 01 version:

- Section 8:

   Technical personnel trained in the operation of DNS servers MUST
   confirm that a failure is due to misconfiguration, as a similar
   breakage could have occurred if an attacker gained access to a
   domain's authoritative servers and modified those records or had the
   domain pointed to their own rogue authoritative servers.

  I agree with the sense of the statement, but specifically how can
  the operator confirm that it's misconfiguration?  Cases like sending
  a bogus answer from an off-site attacker may be easier to
  distinguish (e.g. repeat the same query to the authoritative server
  by hand, maybe over TCP), but I guess such cases as compromised
  authoritative servers can be quite difficult to distinguish (or
  maybe impossible in some cases) from mere misconfiguration.  It
  would help if it (maybe in the appendix) can provide example
  diagnosing techniques for such cases.

- 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.  In fact,
  with my biased impression it's quite surprising to me if Google
  really allows involving humans, not machines, in such cases:-)
  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).

- 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.  So, in the example diagram, if
  there's a (positive) trust anchor for sub.zone1.example.com, the NTA
  for zone1.example.com won't apply for sub.zone1.example.com,
  www.sub.zone1.example.com, etc (is my understanding correct?).  It
  may look quite obvious, but I think it's worth noting.

  On a related note, there are some corner cases which may also be
  worth noting: queries for DS or DLV (or anything similar to that).
  So, for example, zone1.example.com/DS should still be validated even
  if there's an NTA for zone1.example.com.  Again, this might sound
  obvious, but I think it's worthwhile.

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

- Section 12: a minor point, but it may be better to use "server
  failure" instead of SERVFAIL:

   this or other similarly intentionally broken domains should fail to
   resolve and should result in a SERVFAIL error.

  Even though this is a "de facto standard" technical term, I know
  some people hate it to be used in public documents as it's an
  "implementation-specific jargon".

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

--
JINMEI, Tatuya