Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Feb 2019 16:47:01 +0100

On 08. 01. 19 17:30, Wes Hardaker wrote:
> [email-masked] writes:
> 
>>         Title           : Extended DNS Errors
>> 	Filename        : draft-ietf-dnsop-extended-error-04.txt
> 
> FYI, updates from 03 to 04 include:
> 
> 1. moving the unsupported algorithm codes to "NOERROR"
> 2. changing the text encoding to UTF-8 (was ASCII)
> 
> The authors know of no more outstanding issues.  Time for LCv2?

Hello and sorry for being late,

first of all I believe this is useful and suppor the work, but still
needs more work *and implementation experience* before going to LC.

Here is couple specific changes to version 04.

--- Minor changes/clarifications ---

> 2.  Extended Error EDNS0 option format
>    o  The RESERVED bits, 15 bits: these bits are reserved for future
>       use, potentially as additional flags.  The RESERVED bits MUST be
>       set to 0 by the sender and SHOULD be ignored by the receiver.
IMHO "SHOULD be ignored" is asking for trouble. We just went through DNS
flag day to clean up implementations which insisted on some fields being
zero. Can we please use this instead?
      set to 0 by the sender and MUST be ignored by the receiver.

> 3.  Use of the Extended DNS Error option
>    The Extended DNS Error (EDE) is an EDNS option.  It can be included
>    in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that
>    includes an EDNS option.
Why "EDNS option" (at very end of the sentence) and not "OPT Pseudo-RR"?
AFAIK it is perfectly fine to send EDNS0 OPT without any options inside.
Proposed text (only the last line was changed):
   The Extended DNS Error (EDE) is an EDNS option.  It can be included
   in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that
   includes OPT Pseudo-RR [RFC 6891].

> 3.2.  The RESPONSE-CODE field
>    This 4-bit value SHOULD be a copy of the RCODE from the primary DNS
>    packet.  Multiple EDNS0/EDE records may be included in the response.
>    When including multiple EDNS0/EDE records in a response in order to
>    provide additional error information, other RESPONSE-CODEs MAY use a
>    different RCODE.
This paragraph worries me for multiple reasons:
0) Terminology: EDE is an EDNS option, not record!
a) If I am an implementer, in what cases I might want to go against
"4-bit value SHOULD be a copy of the RCODE"?
b) Terminology: Where is a definition of "primary DNS packet"?
c) When I read this now, many months after the initial draft, I have
trouble understanding logic why we are duplicating RCODE here. There
might be a good reasons but we need to state them explicitly otherwise
it will get ignored (or misunderstood).

Unfortunatelly I have trouble understanding intent behind this
description so I'm not able to draft a better text.

> 4.1.1.  NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm
> 
>    The resolver attempted to perform DNSSEC validation, but a DNSKEY
>    RRSET contained only unknown algorithms.  The R flag should be set.
> 
> 4.1.2.  NOERROR Extended DNS Error Code 2 - Unsupported DS Algorithm
> 
>    The resolver attempted to perform DNSSEC validation, but a DS RRSET
>    contained only unknown algorithms.  The R flag should be set.

Why R flag? This is not an error, resolution suceeded, and there is
nothing to retry. I propose change both cases to
"The R flag should not be set."

> 4.2.2.  SERVFAIL Extended DNS Error Code 2 - DNSSEC Indeterminate
> 
>    The resolver attempted to perform DNSSEC validation, but validation
>    ended in the Indeterminate state.  The R flag should not be set.

This should be in NOERROR category.

AFAIK Indeterminate state is not an error, it is most likely a
configuration choice on the resolver. E.g. DNSSEC-validating resolver
running without any trust anchor is in Indeterminate state.

--- New code points ---

I propose to add couple more codes:

+ SERVFAIL Extended DNS Error Code 8 - NSEC Missing
   The resolver attempted to perform DNSSEC validation, but the
   requested data were missing and covering NSEC was not provided.
   RETRY=0

+ SERVFAIL Extended DNS Error Code 9 - Cached Error
   The resolver has cached SERVFAIL for this query.
   RETRY=1
Often the SERVFAIL comes from cache which is unlikely to contain
specific error details, but it is still useful to distinguish "proper"
cached SERVFAIL from other weird errors like running out of file
descriptors etc. Info text could contain remaining TTL ...

+ SERVFAIL Extended DNS Error Code 10 - Server Not Ready
    Server is not up and running (yet). RETRY=1

+ NOTIMP Extended DNS Error Code 1 - Deprecated
Requested operation or query is not supported because it was deprecated.
Retrying request elsewhere is unlikely to yield any other results.
RETRY=0
Intended use:
- OPCODE=IQUERY
- OPCODE=QUERY QTYPE={ANY, RRSIG, MAILA, MAILB} etc.

--- More adventurous proposals ---
a) Two more bits to implement "advice for user" (longer explanation can
be found in archives
https://mailarchive.ietf.org/arch/msg/dnsop/b3wtVj_aWm24PXyHr1M9NMj3LJ0)

I believe this will make the draft way more useful for everyone and not
just geeks.

Proposed addition to text:

> 2.  Extended Error EDNS0 option format
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   4: | R | N | F |                  RESERVED                         |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   o  The NEAR flag, 1 bit; the NEAR bit (N) indicates a flag defined
      for use in this specification.
   o  The FAR flag, 1 bit; the FAR bit (F) indicates a flag defined
      for use in this specification.

> 3.  Use of the Extended DNS Error option

3.2.  The N (Near) flag   The N (Near) flag indicates that the error
reported is likely caused
   by conditions "near" the sender. Value 1 is a hint for user interface
   that user should contact administrator responsible for local DNS.

   For example, an DNS resolver running on CPE will set N=1 in its
   error responses if it detects that all queries to upstream DNS
   resolver timed out. This likely indicates a link problem and must be
   fixed locally.

   Another example is an DNSSEC-validator which detects that query
   ". IN NS" fails DNSSEC validation because signature is expired
   or not yet valid. This most likely indicates misconfigured system
   time and needs to investigated and fixed locally.

3.3. The F (Far) flag
   The F (Far) flag indicates that the error reported is likely caused
   by conditions on the "far" end, i.e. typically authoritative side or
   upstream forwarder. Value 1 is a hint for user interface to display
   message suggesting user to contact operator of the "far end" because
   it is unlikely that local operator can fix the problem.

   For example, an DNS resolver might set F=1 if all authoritative
   servers for a given domain are lame.

b) Another thing to consider is adding optional TTL value to EDE option.
E.g. there is no point in retrying the query again and again until bogus
response is cached. It is much better to display error message "try
again in 10 seconds, if the problem persists call X" than just "try again".

What do you think?

-- 
Petr Špaček  @  CZ.NIC

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 20:25:37 +0100

On Thu, Feb 07, 2019 at 04:47:01PM +0100,
 Petr Špaček <[email-masked]> wrote 
 a message of 129 lines which said:

> Why R flag? This is not an error, resolution suceeded,

But without the AD flag.

> and there is nothing to retry. I propose change both cases to "The R
> flag should not be set."

In both cases, because another resolver may know other, different
algorithms and therefore succeed to validate.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 20:51:25 +0100

On Mon, Jan 07, 2019 at 12:30:10PM -0800,
 [email-masked] <[email-masked]> wrote 
 a message of 44 lines which said:

>         Authors         : Warren Kumari
>                           Evan Hunt
>                           Roy Arends
>                           Wes Hardaker
>                           David C Lawrence

Some remarks but before, note I think that it is very important that
we have a way to report more detailed error causes. One of the biggest
problems of DNSSEC is that there is no easy way for the resolver to
report to the application about a DNSSEC problem. So, the work on this
draft is essential.

Now, the problems:

It seems to me that this draft is mostly for resolvers, most planned
extended codes are useless for authoritative servers (except may be
REFUSED/Lame?).

I suggest to make that clear in the introduction:

These extended error codes are specially useful for resolvers, to
return to stub resolvers or to downstream resolvers. Authoritative
servers MAY use them but most error codes would make no sense for
them.

> Unless a protective transport mechanism (like TSIG [RFC2845] or TLS
> [RFC8094])

Why 8094, which does not have even one implementation, instead of
7858?

> 4.2.3.  SERVFAIL Extended DNS Error Code 3 - Signature Expired
>
>   signature was expired.

I suggest to replace "the signature was expired" by "a signature in
the validation chain was expired".

Rationale: which signature? What if a DS at the parent is sign with an
expired signature?

> 4.2.5.  SERVFAIL Extended DNS Error Code 5 - DNSKEY missing
>
>   A DS record existed at a parent, but no DNSKEY record could be found
>   for the child.

I suggest to replace "no DNSKEY record could be found for the child"
by "no DNSKEY record for this specific key could be found for the
child".

Rationale : the current text seems to imply this code is only when
there is no DNSKEY at all.

> 4.4.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked
>
>   The resolver attempted to perfom a DNS query but the domain is
>   blacklisted due to a security policy.  The R flag should not be set.

The last sentence is touchy. If a stub is configured with two
resolvers, and one is fast but known for lying in some cases that you
disagree with, you may ask a cookie from the other parent (no, resolver).

> 4.4.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked
>
>   The resolver attempted to perfom a DNS query but the domain is
>   blacklisted due to a security policy.

I tend to think it would be a good idea to separate the case where the
policy was decided by the resolver and the case where the policy came
from outside, typically from the local law (see RFC 7725 for a similar
case with HTTP).

Rationale: in the first case (local policy of the resolver), the user
may be interested in talking with the resolver admin if he or she
disagrees with the blocking. In the second case, this would be useless.

Otherwise, I suggest to add an error code:

NOERROR Extended DNS Error Code 3 - Forged answer

   For policy reasons (legal obligation, or malware filtering, for
   instance), an answer was forged.  The R flag should not be set.

Rationale: there is "NXDOMAIN Extended DNS Error Code 1 - Blocked" but
policy-aware resolvers (lying resolvers, in plain english) do not
always forge NXDOMAIN, they can also forge A or AAAA answers.

See also the issue just before, about the need to differentiate
resolver policy from "upper" policy, law, for instance.

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Thu, 14 Feb 2019 20:12:15 +0000

> there is no DNSKEY at all.
 I disagree. There are going to be cases where DS and DNSKEY are not
fully in sync due to key rollovers, prestaging, etc. This is not a fatal
error.
So long as one DS matches one (supported) DNSKEY, the domain is
resolvable, and is not a SERVFAIL. It is only SERVFAIL if *no* DS match
useable keys.

I would suggest "No supported matching DNSKEY record could be found for
the child"

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: Warren Kumari <[email-masked]>
Date: Thu, 14 Feb 2019 15:33:23 -0500

> report to the application about a DNSSEC problem. So, the work on this
Thank you, I / we certainly think so.

> servers MAY use them but most error codes would make no sense for

Yup, at the moment the majority of these are resolver errors - I don't
think we necessarily expected / thought that through when starting this.
I'm guessing that the majority of these will be resolver errors on the
future as well, but how about:
"The majority of these extended error codes are primarily useful for
resolvers, to
return to stub resolvers or to downstream resolvers. Authoritative
servers may also use this technique to annotate errors (for example,
REFUSED), but as of publication there are not as many of these defined"
or something?

> Why 8094, which does not have even one implementation, instead of

I believe that that was an oversight / error.

> Rationale: which signature? What if a DS at the parent is sign with an
LGTM.

> by "no DNSKEY record for this specific key could be found for the
LGTM.

> disagree with, you may ask a cookie from the other parent (no, resolver).

Yup. The R flag is entirely, 100% simply a hint - you are perfectly allowed
to ignore it, and in this case, you may want to (keep reading!)
So, why bother having the flag at all? Primarily it exists so that, if an
implementation gets an extended error code which it doesn't understand (e.g
42), it can choose to take the hint, or not.
If an implementation *does* understand the code, it can decide it knows
better.

Now, in this particular case, I think you are right - unless anyone
objects, I'm a gonna flip that to "the R flag should be set".

> resolver policy from "upper" policy, law, for instance.

Errr... I like the idea / concept, but I'd really like to avoid the word
"Forged" -- while you and I (and probably almost everyone else on the list)
would agree that this is forged, I think that the pejorative nature of the
word would make it that people are forced to forge answers might not be
allowed to tag it as such.
Can anying think of a better word? I was hoping to find something in the
HTTP 451 Error Code page - https://en.wikipedia.org/wiki/HTTP_451, but no
luck.
Fictional answer? Alternative fact? Supposititious answer?

Thank you for your comments and text,
W

>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
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: Brian Dickson <[email-masked]>
Date: Thu, 14 Feb 2019 14:27:51 -0800

>> by "no DNSKEY record for this specific key could be found for the

I disagree; I concur with Michael Sheldon (my colleague).

I think the semantics that need to be expressed are:
"No matching DS/DNSKEY pairs could be found for the child."

It doesn't necessarily require the absence of specific DS records in the
parent,
or DNSKEY records in the child, or the complete absence of e.g. DNSKEYs.

It may or may not make any sense to call out other sources of error leading
to this condition, e.g. in the EXTRA-TEXT field.
(No DNSKEYs; No valid DNSKEYs; No valid DS records; Valid DS with Expired
RRSIG; Valid DNSKEY with Expired RRSIG, etc.)

And it definitely should only be SERVFAIL iff no matching, valid DS/DNSKEY
pairs (i.e. DNSSEC validated DNSKEY, with matching, understood algorithms
and non-expired signatures exist).

Brian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2019 10:02:35 +0100

On Thu, Feb 14, 2019 at 03:33:23PM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 388 lines which said:

> but how about:
> resolvers, to return to stub resolvers or to downstream
> resolvers. Authoritative servers may also use this technique to
> annotate errors (for example, REFUSED), but as of publication there
> are not as many of these defined"

OK

> > I tend to think it would be a good idea to separate the case where
> > the policy was decided by the resolver and the case where the
> > policy came from outside, typically from the local law (see RFC
> > 7725 for a similar case with HTTP).
> >
> > Rationale: in the first case (local policy of the resolver), the
> > user may be interested in talking with the resolver admin if he or
> > she disagrees with the blocking. In the second case, this would be
> > useless.

You did not reply to this one. It is inspired by a message from Petr
Špaček
<https://mailarchive.ietf.org/arch/msg/dnsop/b3wtVj_aWm24PXyHr1M9NMj3LJ0>
explaining how extended DNS errors would be great to tell the user
whose fault it is (signature expired == no need to tell the resolver's
operator). I really think it is important to make the difference between:

* I blocked your request because that's _my_ policy
* I blocked your request because I'm compelled to do so, don't
  complain, it would be useless.

> I'd really like to avoid the word "Forged"

I did not know it was pejorative (in french, "forgée", which has the
same origin, is not). So, what about "substituted answer"? Neutral
enough?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2019 10:09:46 +0100

On Thu, Feb 14, 2019 at 08:51:25PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> Otherwise, I suggest to add an error code:

Ooops, I forgot one:

SERVFAIL Extended DNS Error Code 8 - No reachable authority 

   The resolver could not reach any of the authoritative name servers
   (or they refused to reply).  The R flag should be set.

Rationale: in draft -04, all SERVFAIL extended error codes are for
DNSSEC issues. In my experience, SERVFAIL happens also (and quite
often) for routing issues (most zones have all their authoritative
name servers in only one AS, sometimes even one prefix or, worse, one
rack).

We set the R flag because another resolver may not have the same
routing issues, BGP not being consistent between all sites.

True, an extended error code could be added after the RFC is
published, through "Specification required" but 1) it is easier to do
it now 2) it gives to the people who will implement the RFC a wider
view of the possible uses.

---

From: Jim Reid <[email-masked]>
Date: Fri, 15 Feb 2019 09:34:16 +0000

> On 15 Feb 2019, at 09:02, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> I really think it is important to make the difference between:
> 

Why? From the client's perspective, there's no effective difference between these. Their request was rejected for some policy reason and it doesn't really matter whose policy has been applied.

Besides in situations where blocking is being done because of someone else's say so, it's highly likely that the DNS operator will be subject to some sort of injunction which prevents them from disclosing that such blocking is taking place. Think warrant canaries.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2019 10:46:31 +0100

On Fri, Feb 15, 2019 at 09:34:16AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 19 lines which said:

> Why? From the client's perspective, there's no effective difference
> between these.

In the first case, you can talk with someone which you have some
relationship with (the ISP, typically).

> Their request was rejected for some policy reason and it doesn't
> really matter whose policy has been applied.

Well, it certainly matters to me. Think responsability,
accountability, consumer choice...

> Besides in situations where blocking is being done because of
> someone else's say so, it's highly likely that the DNS operator will
> be subject to some sort of injunction which prevents them from
> disclosing that such blocking is taking place.

Not "highly likely". It depends. Some censors are open in their
censorship (otherwise, RFC 7725 would be useless.)

Case study: in France, the list of "terrorist" domain names whose
blocking is mandatory is not public, but the fact that a domain is
blocked because of this list is not: the ISP returns a forged (sorry,
"substituted") specific IP address.

---

From: Petr Špaček <[email-masked]>
Date: Wed, 20 Feb 2019 12:26:40 +0100

> I propose to add couple more codes:

Yet another code propodsl:
* answer with stale data

   The resolver was unable to resolve answer within its time limits and
   decided to answer with stale data instead of answering with an error.
   This is typically caused by problems on authoritative side, possibly
   as result of an DoS attack. Retrying is likely to cause load and not
   yield a fresh answer, RETRY=0.

Here is a problem that this code point is applicable to NOERROR as well
as NXDOMAIN answers so I'm not sure how to categorize it. This
reinforces my unanswered question why the draft proposes to copy RCODE
into EDE.

-- 
Petr Špaček  @  CZ.NIC

---

From: Dick Franks <[email-masked]>
Date: Thu, 21 Feb 2019 01:17:49 +0000

On Wed, 20 Feb 2019 at 11:27, Petr Špaček <[email-masked]> wrote:
8<

> reinforces my unanswered question why the draft proposes to copy RCODE

This seems to be a good argument in favour of a one-dimensional error table.

--Dick