Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[神明達哉 <[e-mail]>]

At Mon, 27 Apr 2015 18:58:10 -0400,
Tim Wicinski <[e-mail]> wrote:

> This starts a Working Group Last Call for Adoption for
> draft-ietf-dnsop-negative-trust-anchors

(I guess this is "for Publication", not "for Adoption").

Also, have we decided to publish it as an Informational document?  I'm
not opposed to it, but this document contains some normative text and
affects inseparability in some sense, so a standard truck seems to be
a more appropriate choice for me.

> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
>
> https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons

I do not think it's ready for publication yet.

I'd like to see a discussion on whether it really makes sense that an
NTA for a domain name even disables a positive trust anchor below the
name.  I made more specific comment on this in a separate message:
http://www.ietf.org/mail-archive/web/dnsop/current/msg14170.html
(with some other comments on the 04 version of the draft).

I also think Appendix B needs more editorial cleanups.  Those
editorial matters may not be a showstopper by themselves, but I guess
it's better to fix them before sending it to the IESG.

A couple of other comments on version 4:

- Section 4:
   It is therefore
   recommended that NTA implementors should periodically attempt to
   validate the domain in question, for the period of time that the

  I guess this 'recommended' may be better RFC2119 capitalized, i.e.,
  "RECOMMENDED".  Not a strong opinion, but it seems to me to be more
  aligned with general tone and other usage of RFC2119 keywords of
  this section.

- Section 4: likewise, maybe s/should/SHOULD/
   When removing the NTA, the implementation should remove all cached
   entries below the NTA node.

Editorial and minor comments:

- Section 3: there's an awkward blank line (and spaces) before the
  reference:
   names for a Negative Trust Anchor.  For example, Unbound calls their
   configuration "domain-insecure."

   [Unbound-Configuration]

- Section 7.1: s/has have/has/
   Thus, there may be a gap between when a domain has have been re-

- Appendix B: s/servers/server's/ (?)
   domain is consistency and history.  It therefore is good if you have
   the ability to look at the servers DNS traffic over a long period of

- Appendix B: s/them install/install them/
   most of these tools are open source so you can them install locally
   if you want.

- Appendix B: this sentence doesn't parse well to me...

   Using the tools over the Internet has the advantage though that as
   these are not located in the same part of the network you already
   will have more than local view by using different tools.

- Appendix B: s/server.s/servers./
   consistently around the world and from all authoritative server.s Use

- Appendix B: s/an guarantee/a guarantee/
   attack, although that is not an guarantee.  Also if the output from

- Appendix B: it's now a dnsop wg document
   EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to
   the domain.

- Appendix B: this sentence doesn't parse well to me...

   Again if the data is the same this
   is an indication that the error is operator caused not an guarantee.

- Appendix B: s/parents/parent's/ (or "parent zone's ?)
   o  DNSKEYs in child zone don't match parents zone DS record.  There

- Appendix B: these two sentences seem too informal grammatically, if
  not broken:
      Has the existed before and was used?
      Was there a change in the DNSKEY RRSet recently (indicating a key
      rollover) and of course has the actual data in the zone changes.

- Appendix B:
   o  Data in DS or DNSKEY doesn't match the other.  This is more common
      in initial setup when there was a copy and paste error.  Again
      checking history on data is the best you can do there.  It's not
      possible to give a checklist just to run through to decide if a
      domain is broken because of an attack or an operator error.

  Is the "It's not possible..." sentence supposed to belong to the
  bullet?  This sentence seems to talk about something general, and
  seem to make more sense if it's part of the sentence that follows:

   All of the above is just a starting point for consideration when
   having to decide to deploy or not deploy a trust anchor.

--
JINMEI, Tatuya