Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-extended-error-08

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Sep 2019 21:05:34 -0700

Paul Hoffman <[email-masked]> writes:

Hi Paul,

Thanks for the comments and good suggestions.  Responses below inside my
todo list of action:

12 Paul Hoffman
===============

  Greetings again. The changes here generally help the document, but
  they also highlight some of the deficiencies. A few comments on the
  current draft:

12.1 NOCHANGE what error codes?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - The spec does not say anything about the kinds of responses where it
  is allowed to send particular extended error codes. For example, if a
  response has an RCODE of NOERROR, what does it mean for it to also
  have a EDE? Or if the RCODE is FORMERR, can it have an EDE that
  relates to DNSSEC validation failure? The exact semantics for the
  receiver need to be specified.

  + The EDE was specifically meant to be an "addition" to an existing
    reply of *any* RCODE, including NOERROR codes.  There is no
    restriction about when you might include one.  Similarly, it makes
    no sense for some codes to be returned for some RCODES, but any good
    receiver shouldn't segfault either.  I don't think we can specify
    all potential combinations in any meaningful way.

12.2 DONE extend vs annotate
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - In the introduction, it says: This document specifies a mechanism to
    extend (or annotate) DNS errors to provide additional information
    about the cause of the error.
  "extend" and "annotate" have very different meanings. This is the crux
  of the use of the mechanism, so it needs to be clearer.

  + response: I've removed (or annotate)

    (though it didn't bother me)

12.3 DONE ...
~~~~~~~~~~~~~

  - In the introduction, it says: These extended error codes are
    specially useful when received by resolvers, to return to stub
    resolvers or to downstream resolvers.  Authoritative servers MAY
    parse and use them, but most error codes would make no sense for
    them.  Authoritative servers may need to generate extended error
    codes though.

  This is confusing because many authoritative servers also send queries
  when they are doing AXFR and so on. Instead, I propose:

  These extended error codes described in this document can be used by
  any system that sends DNS queries. Different codes are useful in
  different circumstances, and thus different systems (stub resolvers,
  recursive resolvers, and authoritative resolvers) might receive and
  use them.

  + Response: thanks for the text.  Adopted!

12.4 DONE stop repeating yourself
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - Sections 3.1 and 3.2 repeat the information at the end of Section 2,
  and thus should be eliminated. Instead, leave Section 2 as is, and
  simply include the the first paragraph of Section 3, and then
  eliminate Section 3 altogether.

  + Good point; thanks.  It was a bit more work than that to combine
    them, but I've done so.

12.5 DONE flippant language
~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - There are many places where the document uses flippant language that
  could confuse readers who don't understand English idioms. Although
  they are somewhat humorous, these could lead to confusion and should
  be removed.

  + Response: I've removed the ones I found, and may remove more after a
    final pass if I missed any in a skim.
-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Sep 2019 14:07:45 +0000

> Thanks for the comments and good suggestions.  Responses below inside my

Being silent on this is also bad. Proposed text for the introduction:

This document does not allow or prohibit any particular extended error codes and information be matched with any particular RCODEs. Some combinations of extended error codes and RCODEs may seem nonsensical (such as resolver-specific extended error codes in responses from authoritative servers), so systems interpreting the extended error codes MUST NOT assume that a combination will make sense.

Having said that, I think not having restrictions on which EDE can be used with which RCODE with systems in particular roles is actively dangerous. We know that software developers *will* make such assumptions, and attackers will use those wrong assumptions in the future.

--Paul Hoffman

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Sep 2019 16:02:49 -0700

Paul Hoffman <[email-masked]> writes:

> This document does not allow or prohibit any particular extended error
> codes and information be matched with any particular RCODEs. Some
> combinations of extended error codes and RCODEs may seem nonsensical
> (such as resolver-specific extended error codes in responses from
> authoritative servers), so systems interpreting the extended error
> codes MUST NOT assume that a combination will make sense.

I think that works.  I extended it with one more sentence:

      <t>This document does not allow or prohibit any particular
      extended error codes and information be matched with any
      particular RCODEs. Some combinations of extended error codes and
      RCODEs may seem nonsensical (such as resolver-specific extended
      error codes in responses from authoritative servers), so systems
      interpreting the extended error codes MUST NOT assume that a
      combination will make sense.  Receives MUST be able to accept
      EDE codes and text in all messages, including even those with a
      NOERROR RCODE.</t>

-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Sep 2019 00:42:53 +0000

>      EDE codes and text in all messages, including even those with a

Thanks. However, I still think this opens a lot of security holes if developers try to be "smart" by assuming that some EDEs only make sense with some RCODEs. If I'm in the rough, I'll be quiet.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 10 Sep 2019 20:58:25 -0400

it sounds to me that a discussion on assumptions with EDEs and RCODES would
be useful in the security considerations section as well.

and Wes, it should be "Receivers MUST be" and not "Receives MUST be" in
your last sentence.

Tim

On Tue, Sep 10, 2019 at 8:43 PM Paul Hoffman <[email-masked]> wrote:

> Thanks. However, I still think this opens a lot of security holes if
> developers try to be "smart" by assuming that some EDEs only make sense
> with some RCODEs. If I'm in the rough, I'll be quiet.
>
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Evan Hunt <[email-masked]>
Date: Wed, 11 Sep 2019 05:21:14 +0000

> with some RCODEs. If I'm in the rough, I'll be quiet.

Sorry, I'm a bit slow tonight; can you explain in more detail the
security hole you foresee, and how Wes's suggestion fails to address
it?

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Sep 2019 14:52:20 +0000

> security hole you foresee, and how Wes's suggestion fails to address

A simple case:

A developer writes code that assumes that EDE X must go with RCODE Y because the text for EDE X indicates that. The get a response with EDE X and RCODE Z. The code rejects that, and does not act on RCODE Z.

If the WG believes that Wes' text will prevent developers from ever assuming that EDEs need to match RCODEs, that's fine, but I note that TimW suggested that there be a Security Consideration about this as well. 

--Paul Hoffman

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Sep 2019 16:02:18 -0700

Tim Wicinski <[email-masked]> writes:

> it sounds to me that a discussion on assumptions with EDEs and RCODES
> would be useful in the security considerations section as well. 

I'll look at wording along those lines.

Note, however, that EDE codes are specifically meant as supplemental
information and shouldn't be "acted" upon.  Hence

Paul> A developer writes code that assumes that EDE X must go with RCODE Y
Paul> because the text for EDE X indicates that. The get a response with EDE
Paul> X and RCODE Z. The code rejects that, and does not act on RCODE Z.

"does not act on RCODE Z" is already the right approach, since it's
unauthenticated in the first place (which is discussed in the
document).

> and Wes, it should be "Receivers MUST be" and not "Receives MUST be" in your
> last sentence. 

Yeah, fixed that already (and multiple people have pointed that one out
at this point...  you folks have good eyes)
-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Sep 2019 01:13:31 +0000

> unauthenticated in the first place (which is discussed in the

I do not understand this. Many receivers of RCODEs act on them even though they are unauthenticated. A recursive resolver receiving a message with RCODE of SERVFAIL will look at other authoritative servers, for example.

--Paul Hoffman

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Sep 2019 21:50:24 -0700

Paul Hoffman <[email-masked]> writes:

> I do not understand this. Many receivers of RCODEs act on them even
> though they are unauthenticated. A recursive resolver receiving a
> message with RCODE of SERVFAIL will look at other authoritative
> servers, for example.

You implied said ""RCODE Z" but implied "RCODE Z but also looked at EDE
code X", and deliberately didn't act on Z because the presence of EDE
code X.  This document isn't (and shouldn't) change the processing
behavior of RCODEs; it only augments an additional message with
additional information which can be reported to the user or log or ...
It's not supposed to affect decision processing.

[arguably with the R bit in place, it was; but we removed that]

-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Sep 2019 14:52:59 +0000

> It's not supposed to affect decision processing.

But that sentence doesn't appear anywhere in the document.

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.

--Paul Hoffman

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 12 Sep 2019 18:42:28 +0200 (CEST)

> Il 12 settembre 2019 16:52 Paul Hoffman <[email-masked]> ha scritto:
> 

But isn't the foremost motivation of this document to allow the client to tell between SERVFAIL due to DNSSEC validation failure and SERVFAIL due to resolver issues, and try another resolver in the latter case but not in the former? How would this not be "changing the processing of RCODEs in messages based on extended error codes"?

Or do you mean that the stub resolver library can do that, but not the application that is calling it? But what do you do when the two things are in fact the same, e.g. with DoH clients?

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Sep 2019 14:10:02 -0400

> On Sep 12, 2019, at 12:42 PM, Vittorio Bertola <[email-masked]> wrote:
> 
> But isn't the foremost motivation of this document to allow the client to tell between SERVFAIL due to DNSSEC validation failure and SERVFAIL due to resolver issues, and try another resolver in the latter case but not in the former?

That's the crux of the matter and, in short, *no*, that's not (or should
not be) the motivation.

SERVFAIL means,  and will continue to mean, I can't help you, better luck next
time (or elsewhere).

The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not
override RCODEs.  They are not a more fine-grained RCODE one might "act on".
If we want more fine-grained *actionable* codes, there's plenty of room for
more values in the 12-bit EDNS RCODE.

[ I chatted off-list with Wes, the above appears to match his take, with a bit
  luck also rough WG consensus... ]

-- 
	Viktor.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 13 Sep 2019 12:16:55 +0100

>    luck also rough WG consensus... ]

The very first two sentences of the draft are (to my reading) at odds 
with that:

"There are many reasons that a DNS query may fail, some of them
  transient, some permanent; some can be resolved by querying another
  server, some are likely best handled by stopping resolution.
  Unfortunately, the error signals that a DNS server can return are
  very limited, and are not very expressive."

Ray

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Sep 2019 13:38:02 +0000

On Sep 13, 2019, at 4:16 AM, Ray Bellis <[email-masked]> wrote:
> The very first two sentences of the draft are (to my reading) at odds with that:
> 

Fully agree. That's why I'm pressing for clarification by addition of determinative text, not just removal of confusing text.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 13 Sep 2019 13:02:07 -0400

> On Sep 13, 2019, at 9:38 AM, Paul Hoffman <[email-masked]> wrote:
> 

If more fine-grained RCODEs are needed, then perhaps bite
the bullet and add them as EXTENDED-RCODEs in the currently
unassigned range:

       23 - 3,840
   0x0017 - 0x0F00

with the limitation that new EXTENDED-RCODE values are for
legacy clients implicitly refinements of SERVFAIL, since a
client that does not understand a new RCODE can only treat
it as some sort of unknown failure.

With EDEs as largely diagnostic refinement, the EXTENDED-RCODE
remains unchanged and dispositive, and the EDE do not generally
change client behaviour.

There are perhaps cases where a client might choose to not retry
a query that returned REFUSED when the EDE is:

  3.16. Extended DNS Error Code 15 - Blocked
  3.17. Extended DNS Error Code 16 - Censored
  3.18. Extended DNS Error Code 17 - Prohibited
  3.19. Extended DNS Error Code 18 - Filtered
  3.22. Extended DNS Error Code 21 - Deprecated

or not retry a SERVFAIL when the EDE is:

  3.21. Extended DNS Error Code 20 - Lame

if it is reasonable to expect the same response from any
other nameservers one might use in retries.  Is it the
intent of this draft that the above or similar would
be used by some clients to make retry/abort decisions?

If so, perhaps it then makes sense to specify the EXTENDED-RCODE + EDE
combinations that go beyond mere diagnostic information, and would be
potential "permanent" errors.

If an iterative resolver encounters a REFUSED from its upstream,
in combination with one of the "permanent" EDEs, might it then
in turn return REFUSED with the same EDE to its client (without
retrying) rather than SERVFAIL after exhausting all upstream
servers (presumably its present behaviour)?

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Sep 2019 21:01:33 +0100

Some questions about the intended meanings...

3.6.  Extended DNS Error Code 5 - DNSSEC Indeterminate

If I remember correctly, there isn't a consistent definition of what
"indeterminate" means. Perhaps it's worth adding a reference to the
intended definition.

[ actually maybe all the codes could have citations to where the error
cases are mentioned in existing specifications, perhaps with a comment
that the citations are not intended to be exhausive ]

3.5.  Extended DNS Error Code 4 - Forged Answer
3.16.  Extended DNS Error Code 15 - Blocked
3.17.  Extended DNS Error Code 16 - Censored
3.19.  Extended DNS Error Code 18 - Filtered

I don't understand the shades of meaning that these are supposed to
distinguish.

wrt "filtered", the description implies vaguely RPZ flavoured filtering,
but it mentions a REFUSED RCODE which isn't what a sensible implementation
would use for that purpose, so I am more confused.

If I understand correctly, the four above are about the qname whereas this
is about the client? The ordering is a bit confusing.

This needs to be split into two: server doesn't know about the zone
queried for (typically RCODE=REFUSED), and server knows about the zone but
it has expired (typically RCODE=SERVFAIL).

Resolvers handling RD=0 queries typically answer from cache or would
answer REFUSED/Prohibited, I would have thought.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: West, backing south for a time, 4 to 6, increasing 7 to
severe gale 9, occasionally storm 10 in Hebrides. Rough or very rough,
becoming high or very high. Rain or showers. Good, becoming moderate or poor.

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 16 Sep 2019 17:20:15 +0200

>   luck also rough WG consensus... ]

My understanding was that it was meant for resolvers to change e.g.
their retrying behavior based on the EDEs in some cases, even after
removing that "Retry flag".  I did consider that a significant part of
the (original) motivation, even we did not implement that in the first
prototype (as only server-side was done).

I certainly agree this issue should better be explicitly stated in the
final text.  At least assuming the WG consensus will be that they don't
want resolvers acting on the EDE codes in any way except for diagnostics
(possibly with RFC2119 qualifier).

--Vladimir

---

From: Eric Orth <[email-masked]>
Date: Tue, 17 Sep 2019 14:13:52 -0400

Any suggestions of making absolute requirements of how the application
"acts on" EDE codes sounds way too restrictive to me.  Most of how the
application acts on any error codes is up to the application, and it would
be unnecessarily limiting to pretend otherwise.  Seems to me it would lead
to silliness like "this application processes SERVFAIL by sometimes
continuing to other servers and sometimes not" and then claiming they
aren't changing that processing by using EDE codes to determine the actual
continuation behavior.

Specific thoughts:
*The text currently in the draft ("systems interpreting the extended error
codes MUST NOT assume that a combination will make sense") seems
reasonable.  Not overly restrictive.  Just a reasonable warning of a
potential false assumption of how the recursive resolver may act.
*Something like "applications MUST continue to follow requirements from
applicable specs on how to process rcodes no matter what EDE is also
received" also seems reasonable.  Clarifies that those cases where
requirements do exist on how an application acts on errors still apply but
doesn't pretend that the EDE spec now tells the application what to do in
all cases.
*Something like "applications SHOULD interpret EDE as supplemental to rcode
rather than as a replacement" also seems reasonable.  Clarifies the
communicated meaning of the code without over prescribing how the
application acts on that meaning.
*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.

---

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

Thanks Paul,

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

14.8 DONE Paul Hoffman previously
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

14.8.1 DONE Proposal: add the following sentence to the end of the abstract:
----------------------------------------------------------------------------

  "Extended error information does not change the processing of RCODEs."

14.8.2 DONE Proposal: add to the end of the Introduction: Applications MUST NOT
-------------------------------------------------------------------------------

  change the processing of RCODEs in messages based on extended error
  codes.

-- 
Wes Hardaker
USC/ISI

---

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

> Some questions about the intended meanings...

Thanks Tony,

14.9 DONE Tony Finch in a sub thread to Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

14.9.1 DONE 3.6.  Extended DNS Error Code 5 - DNSSEC Indeterminate
------------------------------------------------------------------

  + Response: good point.  I'll use a reference to 4035.  We'll have to
    collect references for the rest...  That's a good (and painful)
    idea.

14.9.2 DONE 3.5.  Extended DNS Error Code 4 - Forged Answer
-----------------------------------------------------------

  3.16.  Extended DNS Error Code 15 - Blocked 3.17.  Extended DNS Error
  Code 16 - Censored 3.19.  Extended DNS Error Code 18 - Filtered

  wrt "filtered", the description implies vaguely RPZ flavoured
  filtering, but it mentions a REFUSED RCODE which isn't what a sensible
  implementation would use for that purpose, so I am more confused.

  If I understand correctly, the four above are about the qname whereas
  this is about the client? The ordering is a bit confusing.

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

14.9.3 DONE 3.21.  Extended DNS Error Code 20 - Lame
----------------------------------------------------

  This needs to be split into two: server doesn't know about the zone
  queried for (typically RCODE=REFUSED), and server knows about the zone
  but it has expired (typically RCODE=SERVFAIL).

  + Response: I created an "Invalid Data" error code to handle this.
    Does this work for you?

-- 
Wes Hardaker
USC/ISI

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Sep 2019 12:42:09 +0100

>     they are more understandable now?

The filtering / blocking explanations are much more clear now, thanks!

> 14.9.3 DONE 3.21.  Extended DNS Error Code 20 - Lame

Oh, funny, that sounds to me like an error from a primary server
complaining about a malformed zone file. So that's a third kind of
lameness!

I like the 'not authoritative" explanation.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Northeast backing north 5 or 6. Moderate occasionally rough.
Showers. Good.