Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

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

At Wed, 10 Aug 2016 16:54:39 -0700,
"Paul Hoffman" <[e-mail]> wrote:

> [[ A month later, we're still eager to hear responses to the draft. We
> got a few that we have incorporated for a new version, but want to be
> sure we're on the right track before we move ahead. ]]

> > We understand that "specify more than one" is often an unpopular
> > choice in the IETF, about as unpopular as "don't get consensus on
> > one". This is a WG document so we need consensus even to go with two
> > ways. We look forward to hearing from you about this choice and how we
> > can move forwards.

On this specific point I don't have a strong opinion.  Personally, I
can live with the two-solution approach if it's deemed to be nearly
impossible to reach consensus on a single solution.  While I'd
definitely prefer a single solution, the current draft seems to
provide a reasonable explanation on why we have two at least for now.

Some specific comments on the 02 version follows:

- Section 1.1 (or for general discussion): another obvious downside of
  the QNAME-based approach is that it can't be used for all possible
  zone names because of the size limitation (255 octets) while adding
  extra label.  In practice, this is less likely to be a real issue
  since trust anchors would only be configured a higher level zones.
  But I think it's worth mentioning explicitly.

- Section 4.3

   A responder MUST NOT include the edns-key-tag option in any DNS
   response.

  I wonder whether it might be useful for a responder to signal its
  capability of understanding the option, either by including this
  option in the response or in some other way.  Then the resolver may
  use that information to suppress further unnecessary generation and
  inclusion of the key-tag option.  Not a strong opinion, but raising
  it just in case it's worth considering.

- Section 5.3

   Unless the zone operator has intentionally added
   "_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN
   response.

  Perhaps a pedantic comment, but I suspect this is not 100% accurate
  in that it could legitimately result in other response than
  NXDOMAIN, e.g., if there's a wildcard that would match the
  "_ta_xxxx" name even if (a record of) that specific name itself
  isn't added to the zone.  On the other hand, ignoring this
  nitpicking this requirement seems to be too obvious; if a name
  really doesn't exist in the zone, the server MUST surely return an
  NXDOMAIN, but it's not specific to this protocol, right?  So, in the
  end, I'd primarily suggest just removing this sentence.  Then we
  don't have to worry about making it very accurate, while IMO not
  leaving any obscure points.

- Section 5.3.1

   Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec-
   aggressiveuse] may also affect the quality of key tag signaling.

  (nit) nsec-aggressiveuse is now a dnsop wg document.

- Section 5.3.1

   When the response code for a key tag query is NXDOMAIN, DNS resolvers
   that implement aggressive negative caching will send fewer key tag
   queries than resolvers that do not implement it.

  In the context of the interaction with nsec-aggressiveuse, I think
  this should be more generalized than the response to a key tag query
  itself, e.g.:

   When a query results in an NXDOMAIN response with NSEC or NSEC3
   that covers the name of a key tag query, DNS resolvers that
   implement aggressive negative caching will send fewer key tag
   queries than resolvers that do not implement it.

--
JINMEI, Tatuya