Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

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

At Tue, 25 Jul 2017 12:04:04 -0400,
tjw ietf <[e-mail]> wrote:

> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
>
> The draft is available here:
> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02
>
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.

I support the adoption of the draft, if only to provide a way of
signalling more helpful DNSSEC-related errors than a plain SERVFAIL.
I may or may not support the specific proposal for that goal in the
end, though (I simply don't know at this moment).

I've reviewed draft-wkumari-dnsop-extended-error-02 and am willing to
review followup versions.

My comments on 02:

- I wonder what if a forwarding recursive server receives a response
  containing an extended error (especially from an upstream validating
  resolver sending an error regarding DNSSEC validation).  Is it
  expected to forward it back to the downstream client?

- Can more than one extended error code be included in a single
  message?

- One possible idea of another extended error code: one that indicates
  a type-ANY query is responded with just one type of RRset when there
  can be more.  Technically it may not be considered to be an "error",
  but at least it indicates some special condition, so I think it's
  worth discussing.  (This may also be related to question 1 of
  Section 6).

- Section 1

Editorial

- Section 1

   When a
   stub resolver queries a DNSSEC bogus name (using a validating
   resolver), the stub resolver receives only a SERVFAIL in response.
   [...]

  If this is a major motivation of this proposal, it may not be very
  effective depending on how modern the stub resolver is.  I suspect
  many existing stub resolver implementations still don't even include
  EDNS(0) in their queries (at least by default).  It doesn't
  necessarily mean this proposal is completely useless, but we may
  have to note it won't be as effective until and unless the majority
  of stub resolvers become more modern.

- Section 2

   o  FLAGS, 2 octets.

  We might just define the R bit and keep the remaining 15 bits
  "reserved", unless we know we'll definitely use these as "flags".

Editorial nits:

- Section 1

   - e.g the answer was marked REFUSED because of a lame delegation, or
   because there is a lame delegation or because the nameserver is still

  "or because there is a lame delegation" is redundant and should be
  removed?

- Section 7

   and do don't get any of the protections which DNSSEC should provide.

  s/do don't/don't/

--
JINMEI, Tatuya