Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Wes Hardaker <[e-mail]>]

Puneet Sood <puneets=[e-mail]> writes:

Hi Puneet,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.5 TODO Puneet Sood
~~~~~~~~~~~~~~~~~~~~~

  I got around to review the draft only recently and have made an
  attempt to avoid points of discussion that have been resolved since
  IETF Prague. Apologies in advance for any duplicates.


* 14.5.0.1 DONE 1. Introduction and background

  Para 2: "A good example of issues that would benefit ..."  Comment:
  The paragraph leads up to the conclusion that the EDE codes will be
  helpful to a client to decide between retry and stopping.  Since the
  consensus is that the EDEs are purely diagnostic, it would be good to
  reiterate that at the end of this paragraph.

  + Response from Viktor: For the record, while that was
  "diagnostic" was my take on the purpose of these codes, reading other
  responses, I am not sure that's yet the consensus view...  I could
  also live with these being actionable, provided the text is then more
  clear on how to do that correctly

  If the actions based on these codes are arbitrary choices for each
  implementation, with not even a clear correspondence with associated
  RCODEs, that feels like too much rope to me...

  Eric Orth's comment from Sept 17 is also relevant here (no one has
  responded to it yet). Quoting the last bullet from his response here
  for reference:
  [https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE]
  *Something like "applications MUST NOT act on EDE" or "applications
  MUST NOT change rcode processing" does not seem reasonable to me.  Way
  too unclear what "diagnostic" processing is reasonable and allowed or
  not.  And potentially limits applications from doing processing based
  on very reasonable or obvious interpretations of the received
  rcode/EDE combinations."

  + Response: Paul H. gave us language to put in both the abstract and
    introduction to address this.  Let me know if you think it doesn't
    address this issue.


* 14.5.0.2 TODO 2. Extended Error EDNS0 option format / forwarding /etc/

  Final para: "The Extended DNS Error (EDE) option can be included in
  any response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to a
  query that includes OPT Pseudo-RR [RFC6891]. ..."

  Comment: Given the level of discussion around behavior when
  sending/receiving the EDE option, there should be some more text
  giving guidance on behavior.

  a. For recursive resolvers, it may be worth pointing that it is not
  expected to copy/forward EDE values received from authoritative
  nameservers to their clients.  b. What is the expectation on caching
  for the EDE code generated by a recursive resolver in response to a
  query? My expectation is that it will be cached (if the answer itself
  is cached) so the next response has the same EDE code.  c. Truncation:
  In case a response including the EDE option with EXTRA-TEXT filled in
  exceeds the effective UDP payload size, what is the desired behavior
  for the EDE option? Should the EXTRA-TEXT field be left empty in favor
  of filling in other RR types? Should the response be marked truncated
  to require a re-query over TCP?

  This is unlikely for failures but could happen when DNSSEC validation
  could not be performed due to unsupported digest type.

  + Response: good questions, and I think the WG needs to think about
    whether to add that much more data.


* 14.5.0.3 DONE 3.14 Extended DNS Error Code 13 - Cached Error

  The resolver has cached SERVFAIL for this query.

  Comment: To match the text the name should be "Cached SERVFAIL".


* 14.5.0.4 NOCHANGE 5. Security Considerations

  Para 2: "This information is unauthenticated information, and an
     attacker (e.g a MITM or malicious recursive server) could insert an
     extended error response into already untrusted data ..."  Comment:
     Agree with some other comments that this is not relevant since no
     action is expected to be taken based on EDEs.  Comment: There are
     ideas in the thread to have links to info in the EXTRA-TEXT and
     possibly display it to users. I guess the usual warnings to not
     click on potentially unsafe links apply.

  + Yeah, it really would be remiss to leave out that point.  There may
    be nothing we can do, but the whole point of a security
    consideration is to properly disclose any known threats/issues.

  Thanks, Puneet




-- 
Wes Hardaker
USC/ISI