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

From: Tim Wicinski <[email-masked]>
Date: Mon, 21 Oct 2019 13:18:16 -0400

All

The second WGLC period ended, and I needed a bit of time to go over all the
comments and make sure they were all addressed, and that appears to be true.

The only thing I see are some comments were raised after the -12 version.
They've been addressed and can be updated on its way to IETF LC.  If
someone thinks
I am incorrect please speak up.

I'll confirm with the authors and finish the shepherd write up

Tim

On Mon, Sep 30, 2019 at 5:07 PM Wes Hardaker <[email-masked]> wrote:

> Vittorio Bertola <[email-masked]> writes:
>
> > > Il 28 settembre 2019 01:41 Wes Hardaker <[email-masked]> ha
> scritto:
> > >
> > >   + 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?
> >
> > 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
>

---

From: Petr Špaček <[email-masked]>
Date: Mon, 21 Oct 2019 19:48:01 +0200

On 21. 10. 19 19:18, Tim Wicinski wrote:
> 
> All
> 
> The second WGLC period ended, and I needed a bit of time to go over all the comments and make sure they were all addressed, and that appears to be true.
> 
> The only thing I see are some comments were raised after the -12 version.  They've been addressed and can be updated on its way to IETF LC.  If someone thinks

I hate to rain on this parade, but I think the draft in its current form has two major problems:

1. Forwarding semantics is unclear, as was pointed out in
https://mailarchive.ietf.org/arch/msg/dnsop/PAiQOsYfYQHrL7SeGWZn-jtJrTs
and elsewhere during WGLC.

Personally I think that omiting forwaring is a major mistake because the EDE code is most useful for diagnostics when forwarding is taking place!

2. Second problem is that it is uncelar if there is going to be a consumer: Did *anyone* from stub resolvers said a word about this draft? Is it useful as it is? Is there an experimental implementation in stub to consume this information?
dnsop has history of tweaks which never get used by stubs, and this draft in particular is very expensive to implement in resolver code.

Besides technical points above I oppose publishing this as standards-track document before it is fully implementated at least once. Previous implementation excercise at IETF 104 hackaton uncovered nasty corner cases and significantly influenced the draft (removal of rcode field etc.). It would be mistake to publish it without re-implementing it again before publication, we might find other significant problems.

Thank you.
Petr Špaček  @  CZ.NIC

> On Mon, Sep 30, 2019 at 5:07 PM Wes Hardaker <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Vittorio Bertola <[email-masked] <mailto:[email-masked]>> writes:
> 
>     > > Il 28 settembre 2019 01:41 Wes Hardaker <[email-masked] <mailto:[email-masked]>> ha scritto:
>     > >
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 21 Oct 2019 13:53:48 -0400

Petr

Thanks for clarifying.  I was going through so many notes, and needed a
check.

1. Forwarding Semantics

Let me think on this one with the authors and chairs.

2. Stub Resolvers.

OK

3. Standards-Track vs Not

That's more than reasonable.

Tim

On Mon, Oct 21, 2019 at 1:48 PM Petr Špaček <[email-masked]> wrote:

> > The second WGLC period ended, and I needed a bit of time to go over all
> the comments and make sure they were all addressed, and that appears to be
> true.
> >
> > The only thing I see are some comments were raised after the -12
> version.  They've been addressed and can be updated on its way to IETF LC.
> If someone thinks
> Personally I think that omiting forwaring is a major mistake because the
> EDE code is most useful for diagnostics when forwarding is taking place!
>
>
> 2. Second problem is that it is uncelar if there is going to be a
> consumer: Did *anyone* from stub resolvers said a word about this draft? Is
> it useful as it is? Is there an experimental implementation in stub to
> consume this information?
> dnsop has history of tweaks which never get used by stubs, and this draft
> in particular is very expensive to implement in resolver code.
>
>
> Besides technical points above I oppose publishing this as standards-track
> document before it is fully implementated at least once. Previous
> implementation excercise at IETF 104 hackaton uncovered nasty corner cases
> and significantly influenced the draft (removal of rcode field etc.). It
> would be mistake to publish it without re-implementing it again before
> publication, we might find other significant problems.
>
> Thank you.
> Petr Špaček  @  CZ.NIC
>
> >
> >     Vittorio Bertola <[email-masked] <mailto:
> [email-masked]>> writes:
> >
> >     > > Il 28 settembre 2019 01:41 Wes Hardaker <[email-masked]
> <mailto:[email-masked]>> ha scritto:
> >     > >

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Oct 2019 11:49:36 +0100

Petr Špaček <[email-masked]> wrote:
> consumer: Did *anyone* from stub resolvers said a word about this draft?
> Is it useful as it is?

I expect almost no-one can do anything with EDE without
getaddrinfo() EAI_ return code extensions.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate later in
west. Mainly fair. Good.

---

From: Puneet Sood <[email-masked]>
Date: Tue, 22 Oct 2019 21:22:48 -0400

> getaddrinfo() EAI_ return code extensions.

At a minimum dig should be able to support it. Does any of the dig
variants have support for EDE yet?

> west. Mainly fair. Good._______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Puneet Sood <[email-masked]>
Date: Tue, 22 Oct 2019 21:49:14 -0400

Wes,

I read and diffed version 12 but did not find text addressing some of
my comments.

On Fri, Sep 27, 2019 at 7:41 PM Wes Hardaker <[email-masked]> wrote:
>
> 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
> ~~~~~~~~~~~~~~~~~~~~~
>
>   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.
LGTM

>
>
> * 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?

Independent of the decision on EDE forwarding and caching, the I-D
needs to have some guidance for it. The EXTRA-TEXT field may be
obtained from configuration and it is possible that the resulting DNS
message will exceed UDP message size limit in the request.

>
>   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.
I do not see text mentioning this.

Thanks,
Puneet

>   Thanks, Puneet

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 Oct 2019 12:10:18 -0400

extended codes are pretty important in the DoH space - which doesn't
require library intermediaries. IIRC the very important use case was
disambiguating DNSSEC validation errors from other errors (as retry
behavior could very well be different). So this has been eagerly
anticipated.

---

From: Eric Orth <[email-masked]>
Date: Thu, 24 Oct 2019 13:24:22 -0400

> getaddrinfo() EAI_ return code extensions.

In many cases, especially when DoH is in use, Chrome uses its own built-in
stub resolver.  So EDE is certainly a reasonable option for us without any
changes to getaddrinfo().

> in particular is very expensive to implement in resolver code.

Chrome DNS has no specific plans decided for EDE yet.  But we do think it's
generally a good idea and are looking forward to it.  I don't have any
implementation-ability concerns with the current draft.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 24 Oct 2019 13:56:39 -0400

> getaddrinfo() EAI_ return code extensions.

I would personally find this to useful if only dig (or drill or delve
or...) supported this -- it's currently hard to actually debug weird
DNS failures, and simply providing information to a human using
diagnostic tools would be helpful.
This and the "DNSSEC bogus -> ask another resolver" are to my mind the
primary uses...
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Fri, 25 Oct 2019 02:06:43 +0000

Hi,

I realize I’m late to this, but this should probably be fixed:

In section 2, Extended DNS Error EDNS0 option format, it states that the OPTION-LENGTH should be “4 + the length of the EXTRA-TEXT section… .” This appears to be a remnant from when the option included a flag word. I think it should be changed to “2 + the length of the EXTRA-TEXT field… .” I also changed “EXTRA-TEXT section” to “EXTRA-TEXT field,” since the draft call these items “fields.”

Otherwise, I approve of draft.

Thanks,

Jan.

From: DNSOP <[email-masked]> on behalf of Tim Wicinski <[email-masked]>
Date: Thursday, September 12, 2019 at 9:52 AM
To: dnsop <[email-masked]>
Subject: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

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: Petr Špaček <[email-masked]>
Date: Fri, 25 Oct 2019 15:29:17 +0200

On 24. 10. 19 19:24, Eric Orth wrote:
> On Tue, Oct 22, 2019 at 6:49 AM Tony Finch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> In many cases, especially when DoH is in use, Chrome uses its own built-in stub resolver.  So EDE is certainly a reasonable option for us without any changes to getaddrinfo().
> 
> On Mon, Oct 21, 2019 at 1:48 PM Petr Špaček <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Chrome DNS has no specific plans decided for EDE yet.  But we do think it's generally a good idea and are looking forward to it.  I don't have any implementation-ability concerns with the current draft.

Excellent, I'm glad to hear that!

This draft creates a new registry with info-codes, and content of the registry is very geeky, so it seems necessary to somehow map error codes to categories which can be communnicated to users in terms of "a random web browser user".

Would it be possible to get some time allocation of your UX design folks, before we set the protocol in stone?

This draft evolved several times when it comes to error categorization, and I believe we will never know if we (= dnsop geeks) got the categorization right until someone attempts to design UX for it.

History of draft-ietf-dnsop-extended-error:
- version 00 - categorization by FLAG
- version 01 - categorization by FLAG + RCODE
- version 07 - no categorization at all

There were other proposals for categorization which did not appear in draft text:
- Shane Kerr - HTTP-like categorization like 1xx, 2xx, 3xx, ...
https://mailarchive.ietf.org/arch/msg/dnsop/DMtP4XuqN132Jxt8O0BTZPFsokg

- Petr Spacek (me) - dichotomy local (near) error vs. remote (far) end error
https://mailarchive.ietf.org/arch/msg/dnsop/b3wtVj_aWm24PXyHr1M9NMj3LJ0

It would be super helpful if an experienced UX designer can have look at give back feedback:

- Is the current version with "no categorization" okay?
- Will it be okay in future if dnsop starts adding new codes?
- Or should we add some inherent categorization into the protocol to make it future-proof?
- If a categorization is needed, what form is best for UX? (please suggest!)

Thank you very much for your time!

-- 
Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Fri, 25 Oct 2019 15:48:35 +0200

> This and the "DNSSEC bogus -> ask another resolver" are to my mind the

In my personal experience most of "hard to debug errors" involve forwarding (because lack of visibility into forwarding chain), so I do not see extended-errors being super useful in its current form.

As a result, from my perspective exposing EDE information only in dig (and other tools for geeks) *does not* justify the investment needed on resolver side.

On the other hand, *if the information is exposed to end-users* in a form which actually helps to direct complains from users to appropriate places, then the cost/benefit situation is completely different and I'm all for it!

-- 
Petr Špaček  @  CZ.NIC

---

From: Eric Orth <[email-masked]>
Date: Thu, 31 Oct 2019 15:08:24 -0400

> before we set the protocol in stone?

Not likely, unfortunately.  Downside of not having specific plans yet.
Makes it difficult to allocate UX experts.

> - If a categorization is needed, what form is best for UX? (please

Speaking for myself from a non-UX perspective (and I am not a UX expert),
forward compatibility of error codes is a common pitfall in many similar
systems.  Once error receivers start relying on specific error codes to
produce specific essential behavior, expandability often gets locked out
because you can't replace those codes with new ones that receivers might
not immediately recognize.  And having a receiver only know "unknown" error
is usually pretty bad.  Attempts to solve these issues usually involve
stuff like categorization, user-visible messages, and multiple ordered
errors, but my anecdotal experience is that it's pretty rare for such
mitigations to be fully supported by all sides to the level where it
actually helps and expandability still ends up limited.

But specifically to EDE, I think the general circumstances make us fine
without taking any specific steps to mitigate forward compatibility.  It's
mostly been designed just for "supplemental" signalling.  And at least for
the general use cases, eg browsers, I doubt enough recursives will ever (or
be able to) support it for the stub to rely on receiving a recognized EDE.
It will always need to be a nice-to-have with the receiver able to provide
good behavior if no EDE (or an unrecognized new EDE) is received.

So no, I don't think categorization is necessary to make EDE useful.  In
fact, I think it would probably make things more complicated than necessary.