[DNSOP] changes to extended errors based on your comments

[Wes Hardaker <[e-mail]>]

Thanks for your feedback about the extended errors draft.  Below are
responses to some of your previously raised points in email to dnsop:

8.3 Shane Kerr
~~~~~~~~~~~~~~

  Several folks have worked on implementing the
  draft-ietf-dnsop-extended-error at the IETF Hackthon yesterday and
  today. This is my own feedback on the draft based on trying to get it
  added to dnsdist.

  ----------------------------------------------------------------------

  Stéphane Bortzmeyer pointed out that it wasn't clear how to encode the
  INFO-CODE into the 12 bits allocated to it. I think that the idea is
  that it should be represented in network (MSB) order, but probably it
  should be specified.

  ----------------------------------------------------------------------


8.3.1 DONE Minor suggestion: text for the descriptions should be consistent
---------------------------------------------------------------------------

  regarding capitalization. So:

  * Forged answer -> Forged Answer
  * DNSKEY missing -> DNSKEY Missing
  * RRSIGs missing -> RRSIGs Missing

  ----------------------------------------------------------------------

  + Response: Good point, thanks!  done.


8.3.2 NOCHANGE For some reason NXDOMAIN(3)-specific codes are listed after
--------------------------------------------------------------------------

  NOTIMP(4)-specific and REFUSED(5)-specific codes in the draft. I think
  it would make more sense to just include these in order.

  + Response: Good point...  though because we removed rcode-binding
    this sort of is resolved

  ----------------------------------------------------------------------


8.3.3 DONE Numbering is a bit weird in section 4.1.3:
-----------------------------------------------------

  4.1.3.  INFO-CODEs for use with RESPONSE-CODE: NOERROR(3) 4.1.3.1.
  NOERROR Extended DNS Error Code 3 - Stale Answer

  Probably the idea is just to have:

  4.1.3. NOERROR Extended DNS Error Code 3 - Stale Answer

  + Response: Yep.  Fixed in the latest version (and simplified)

  ----------------------------------------------------------------------


8.3.4 DONE multiple RCODE issues
--------------------------------

  + Response: The response code has been dropped, as noted above

    RESPONSE-CODE: 3 (NOERROR) INFO-CODE: 3 Purpose: Answering with
    stale/cached data Reference: Section 4.1.3.1
  -> should be RESPONSE-CODE 0

  ----------------------------------------------------------------------

     RESPONSE-CODE: 2 (SERVFAIL) INFO-CODE: 7 Purpose: No NSEC records
     could be obtained Reference: Section 4.2.8 -> should be "No
     Reachable Authority", 4.2.7

  ----------------------------------------------------------------------

  This code is missing in the table:

  RESPONSE-CODE: 2 (SERVFAIL) INFO-CODE: 8 Purpose: No NSEC records
  could be obtained Reference: Section 4.2.8

  ----------------------------------------------------------------------

     RESPONSE-CODE: 4 (NOTIMP) INFO-CODE: 1 Purpose: Reference: Section
     4.4.2 -> should be "Deprecated"

  ----------------------------------------------------------------------


8.3.5 NOCHANGE Finally, I note that the suggestion of requiring that the sender have
------------------------------------------------------------------------------------

  some signal indicating that it is interested in extended errors was
  not adopted. I don't insist on it, but I think it would be useful to
  avoid bloating packets unnecessarily. It's a bit like the useless
  additional section data that lots of servers insist on appending to
  answers... why send something that will not be seen?

  OTOH I realize that having this information available may be useful
  for humans debugging things, even if the sender does not ask for it.

  + Response: If there sufficient support, we'd certainly add it.  This
    is primarily intended to be used for extreme cases and only when
    problems/unusual are detected.  Most DNS messages won't contain EDE
    options and when they do they'll likely fall below the DNSSEC
    amplification factors that are out there.  We think the benefit of
    including the extra information outweighs the problems with sending
    it.  But we'd certainly love to hear more feedback from the
    community to see if there is agreement one way or another here.


8.3.6 NOCHANGE On the gripping hand, adding unasked-for information may have privacy
------------------------------------------------------------------------------------

  implications. Possibly adding a "Privacy Considerations" section would
  be useful?

  + response: What would you like us to add to such a section?  The
    question/answers section likely has most of the sensitive
    information.  If you'd provide text to clarify your thinking, we'd
    gladly include it.

-- 
Wes Hardaker
USC/ISI