Subject: [DNSOP] changes to extended errors based on your comments

From: Wes Hardaker <[email-masked]>
Date: Fri, 09 Aug 2019 22:30:51 -0700

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

---

From: Shane Kerr <[email-masked]>
Date: Mon, 26 Aug 2019 23:53:49 +0200

Wes,

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

I guess on balance always having the information is the simplest 
approach. If there is a specific concern this can be changed.

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

I looked through RFC 6973 Section 7 - 
https://tools.ietf.org/html/rfc6973#section-7 - and didn't see anything 
that stuck out obviously to me.

Possibly the only real concern is with extra text. It currently reads:

    The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold
    additional information useful to network operators.

Quad9's proposal to include various helpful information like how 
dangerous a particular answer might be made me think that we should be 
careful not to leak information in this channel. For example, a response 
should not say something like, "daily query limit reached for account 
7452-54".

Possibly the description could be changed to something like:

    The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold
    additional information useful to network operators. Care should be
    take not to leak private information that an observer would not
    otherwise have access to, such as account numbers.

Cheers,

--
Shane

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Aug 2019 16:23:16 -0700

>    otherwise have access to, such as account numbers.

I like that.  I've put it in, thanks!
-- 
Wes Hardaker
USC/ISI