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

From: Tim Wicinski <[email-masked]>
Date: Thu, 12 Sep 2019 09:51:25 -0400

All

We had such great comments the first time we did a Working Group
Last Call for draft-ietf-dnsop-extended-error, that the chairs decided
a second one would be even better.

Before we start, a few comments:

- Viktor's comments from 11 September will be rolled into the WGLC
  comments, which means I'll be tracking them with the authors.

- The chairs are not doing to add more codes to the IANA registry
  in the document.  However, the process is laid out in section 5.2,
  with three different ranges (Expert Review; First Come, First Serve;
  and Experimental).

- We're pretty sure all comments have been addressed one way or another,
  but we still may have missed some.  Please speak up if that is the case.

This starts a Working Group Last Call for draft-ietf-dnsop-extended-error

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  26
September 2019.

thanks
tim

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Sep 2019 11:34:06 -0400

>   comments, which means I'll be tracking them with the authors.

Much appreciated, thanks!

FWIW, on the hot topic of conflict between RCODE and extended RCODE,
Paul Hoffman's latest comment:

    Proposal: add the following sentence to the end of the abstract:
    "Extended error information does not change the processing of
    RCODEs."

    Proposal: add to the end of the Introduction: Applications MUST
    NOT change the processing of RCODEs in messages based on extended
    error codes.

seems to align with my take on the interaction of EDEs as a (to
coin a phrase) diagnostic refinement rather than "replacement" of
the RCODE.

>From a related nomenclature perspective, I wonder whether there
might be any confusion between the existing high 8 bits of RCODE
in the EDNS OPT pseudo-header (MSB octet of the TTL) and the proposed
new "Extended DNS Error Code".  Perhaps "Extended RCODE" and "Extended
DNS Error Code" are sufficiently similar terms to warrant a brief
comment to the effect that the proposed EDEs are diagnostic refinements
of the existing "Extended RCODE", which is distinct from EDEs and
remains the definitive status of the response...

-- 
	Viktor.

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 12 Sep 2019 20:11:55 +0400

On Thursday, September 12, 2019, Tim Wicinski <[email-masked]> wrote:

> I'm ok with the latest revision. Just a small request: John Todd from
quad9 sent his feedback, so it's fair to credit him in the next revision of
the draft.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 17 Sep 2019 09:56:20 +0200

On Thu, Sep 12, 2019 at 09:51:25AM -0400,
 Tim Wicinski <[email-masked]> wrote 
 a message of 90 lines which said:

> Last Call for draft-ietf-dnsop-extended-error, that the chairs
> decided a second one would be even better.

IMHO, the document is good. I like the fact there is no longer a
limitation of a given EDE to some RCODEs (it makes things simpler).

Some details, all editorial:

* it could be a good idea to add more specific references for the
EDE. For instance, 3 "Stale Answer" could have a reference to
draft-ietf-dnsop-serve-stale.

* I think that many people will be confused with 15, 16, 17 and 18.
Suggestions:
  * remove 18, which is redundant with 15 (if the user chooses the
  resolver, and he should have the right to do so, 15 and 18 are the
  same). 18 is meaningful only if the user does have a simple way to
  change this behaviour.
  * Add to the definition of 15 "The policy was decided by the server administrators"
  * Add to the definition of 16 "This means that the policy was
  not decided by the server administrators, and it is probably useless
  to complain to them".

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Tue, 17 Sep 2019 20:46:14 +0000

In section 3.21

3.21.  Extended DNS Error Code 20 - Lame

   An authoritative server that receives a query (with the RD bit clear)
   for a domain for which it is not authoritative SHOULD include this
   EDE code in the SERVFAIL response.  A resolver that receives a query
   (with the RD bit clear) SHOULD include this EDE code in the REFUSED
   response.

The above case is not consistent with current authoritative server behavior.

The authoritative servers I have tested all return REFUSED, not
SERVFAIL, regardless of the query RD bit, when the server does not allow
recursion, and the server is not authoritative for the zone.

I would change to:

3.21.  Extended DNS Error Code 20 - Not Authoritative

   An authoritative server that receives a query (with the RD bit clear,
   or when not configured for recursion) for a domain for which it is
   not authoritative SHOULD include this EDE code in the REFUSED
   response.  A resolver that receives a query (with the RD bit clear)
   SHOULD include this EDE code in the REFUSED response.

IMO, while "lame" is a valid term, quite frankly, it's not nearly as
clear in meaning as just saying "not authoritative". To me, "lame" is at
the delegation (referring server), not the targeted server.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: Puneet Sood <[email-masked]>
Date: Fri, 20 Sep 2019 17:17:03 -0400

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.

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.

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."

2. Extended Error EDNS0 option format
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.

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".

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.

Thanks,
Puneet

On Thu, Sep 12, 2019 at 9:52 AM Tim Wicinski <[email-masked]> wrote:
> If someone feels the document is *not* ready for publication, please speak out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  26 September 2019.
>
> thanks
> tim
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 22 Sep 2019 01:07:39 -0400

> On Sep 20, 2019, at 5:17 PM, Puneet Sood <[email-masked]> wrote:
> 

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...

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 14:16:46 -0700

Loganaden Velvindron <[email-masked]> writes:

> I'm ok with the latest revision.

Awesome, thanks!

> Just a small request: John Todd from quad9 sent his feedback, so it's
> fair to credit him in the next revision of the draft.

Yep, fixed.  Thanks for that.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 16:40:55 -0700

Puneet Sood <puneets=[email-masked]> writes:

Hi Puneet,

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

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

* 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

  [https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE]

  + 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/

  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?

  + 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

* 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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 16:41:59 -0700

Stephane Bortzmeyer <[email-masked]> writes:

Thanks Stephane,

14.3 DONE Stephane Bortzmeyer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

14.3.1 DONE it could be a good idea to add more specific references for the
---------------------------------------------------------------------------

  + Rseponse that seems popular; I'll try to do this where I can.

14.3.2 DONE I think that many people will be confused with 15, 16, 17 and 18.
-----------------------------------------------------------------------------

  Suggestions:

  * Add to the definition of 15 "The policy was decided by the server
  administrators"

  + Response: Those three codes were supplied in a previous comment
    round and they are supposed to indicate policies being applied from
    different sources.  Can you check the new text of them to see if
    they are more understandable now?

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 16:41:24 -0700

"Michael J. Sheldon" <[email-masked]> writes:

Thanks Michael,

14.4 DONE Michael J. Sheldon" <[email-masked]>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

14.4.1 DONE In section 3.21
---------------------------

  An authoritative server that receives a query (with the RD bit clear)
  for a domain for which it is not authoritative SHOULD include this EDE
  code in the SERVFAIL response.  A resolver that receives a query (with
  the RD bit clear) SHOULD include this EDE code in the REFUSED
  response.

  The above case is not consistent with current authoritative server
  behavior.

  The authoritative servers I have tested all return REFUSED, not
  SERVFAIL, regardless of the query RD bit, when the server does not
  allow recursion, and the server is not authoritative for the zone.

  I would change to:

  An authoritative server that receives a query (with the RD bit clear,
  or when not configured for recursion) for a domain for which it is not
  authoritative SHOULD include this EDE code in the REFUSED response.  A
  resolver that receives a query (with the RD bit clear) SHOULD include
  this EDE code in the REFUSED response.

  IMO, while "lame" is a valid term, quite frankly, it's not nearly as
  clear in meaning as just saying "not authoritative". To me, "lame" is
  at the delegation (referring server), not the targeted server.

  + Response: good catch and I like (and have put in) you replacements.
    I've never liked the "lame" name either, as I don't think it's
    descriptive to someone that isn't in the inner circle of DNS.

-- 
Wes Hardaker
USC/ISI

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 28 Sep 2019 09:03:40 +0200 (CEST)

> Il 28 settembre 2019 01:41 Wes Hardaker <[email-masked]> ha scritto:
> 

I think there was an editorial glitch, so now you have two errors #17 and no #18 - 3.19 should become #18 again. 

Regarding the substance, I think that the text is reasonably clear; especially the difference between #15 and #18-aka-3.19 (which was the subject of Stephane's comment) is that in #15 the resolver is blocking the specific queried name while in #18 the resolver is blocking the specific client, and I think that this is still a useful distinction to make.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Sep 2019 14:07:10 -0700

Vittorio Bertola <[email-masked]> writes:

> I think there was an editorial glitch, so now you have two errors #17
> and no #18 - 3.19 should become #18 again.

Yep, fixed.  Thanks.

-- 
Wes Hardaker
USC/ISI