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

From: [email-masked]
Date: Tue, 01 Oct 2019 16:43:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Extended DNS Errors
        Authors         : Warren Kumari
                          Evan Hunt
                          Roy Arends
                          Wes Hardaker
                          David C Lawrence
	Filename        : draft-ietf-dnsop-extended-error-12.txt
	Pages           : 14
	Date            : 2019-10-01

Abstract:
   This document defines an extensible method to return additional
   information about the cause of DNS errors.  Though created primarily
   to extend SERVFAIL to provide additional information about the cause
   of DNS and DNSSEC failures, the Extended DNS Errors option defined in
   this document allows all response types to contain extended error
   information.  Extended DNS Error information does not change the
   processing of RCODEs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Oct 2019 16:46:53 -0700

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.  This draft is a work item of the Domain Name System
> Operations WG of the IETF.

This version addresses, I believe, all comments from the WG LC.
-- 
Wes Hardaker
USC/ISI

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 Oct 2019 13:01:31 +0100

I have had another read through.

In the intro, one of the example uses for EDE is a server returning errors
because it has not finished starting up, but there is no EDE code for this
case.

Re. EDE 0 "other", is it supposed to cover the situation when there are
multiple errors, e.g. different authoritative servers have different
problems?

Re. EDE 5 indeterminate, RFC 4035 says:

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.

Is this not also covered by EDE 9 (DNSKEY missing) and EDE 10 (RRSIG
missing)?

[ I'm still not convinced "indeterminate" is a coherent validation state... ]

Re. EDE 11 no DNSKEY zone bit, why is there a special case for this and
not for DNSKEY protocol not equal to 3? Are either of these errors that
anyone has seen in the wild? (If so I would love to know how that came to
pass!)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
contribute to the process of peace and disarmament, the elimination
of world poverty, and the collective safeguarding of democracy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Oct 2019 17:12:23 -0400

> On Oct 2, 2019, at 8:01 AM, Tony Finch <[email-masked]> wrote:
> 

No it is not.  The indeterminate state happens when DS RRset lookups
servfail, for the zone or one of its ancestors, this could be a lookup
timeout or a validation issue.  So not identical with DNSKEY missing.

> [ I'm still not convinced "indeterminate" is a coherent validation state... ]

It happens when glue NS records are available, but DS RRsets are not.

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Oct 2019 14:37:49 -0700

> I have had another read through.

Thanks for the extra pass.

(we still have IETF-wide last call to wade through too, FYI)
 
> because it has not finished starting up, but there is no EDE code for this

It's this one:

   3.15.  Extended DNS Error Code 14 - Not Ready

      The server is unable to answer the query as it is not fully
      functional (yet).

> multiple errors, e.g. different authoritative servers have different

One, the latest version talks about servers MAY put in more than one
EDE.  But 0/other was "not in the list", IE there is not currently
defined code that would help me but I want to include an error message
that better describes it in the text section.

> [ I'm still not convinced "indeterminate" is a coherent validation state... ]

I think you're irght that 9/10 are specific cases of indeterminate.
There might be implementation specific reasons too, though, so 5 is a
fallback if you don't have anything more specific (and 0 is a fallback
from that :-) ).  Anyway, I've always hated the indeterminate marking
because I agree it's incomplete and conflicts in definition between the
two rfcs.  I've devoted multiple slides in presentations to that issue.

> anyone has seen in the wild? (If so I would love to know how that came to

It was suggested to be added, so I did.  It does make some sense...  but
no, I've never seen it in the wild either.

-- 
Wes Hardaker
USC/ISI

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Oct 2019 12:11:14 +0100

> timeout or a validation issue.  So not identical with DNSKEY missing.

So EDE 22 or 23 then? You can't handwave "validation issue" here because
the point of these error codes is to explain what kind of validation
issue.

> It happens when glue NS records are available, but DS RRsets are not.

That is "insecure".

I think the definitions of the terms in RFC 4033 are a lot more clear than
RFC 4035. By the 4033 definitions the distinction between insecure and
indeterminate is whether you have a covering trust anchor or not, so
nothing is indeterminate any more for normal validator configurations.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: South 4 or 5, veering west 5 to 7, perhaps gale 8 later. Slight
or moderate, becoming moderate or rough, occasionally very rough later in
Wight. Fair then rain. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Oct 2019 12:23:52 +0100

>    3.15.  Extended DNS Error Code 14 - Not Ready

D'oh!

> EDE.

Oh wow, that will be fun...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay, Southeast Fitzroy: Southwesterly 5 or 6, veering northwesterly 3 to 5.
Moderate at first in Biscay, otherwise rough or very rough. Occasional rain.
Good, occasionally poor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Oct 2019 11:29:17 -0400

> On Oct 3, 2019, at 7:11 AM, Tony Finch <[email-masked]> wrote:
> 

No, by "available" I meant lookup succeeded (returning valid records,
NODATA or NXDOMAIN, with DoE as appropriate).  By "unavailable", I
meant a timeout, ServFail, bogus reply, ...

> nothing is indeterminate any more for normal validator configurations.

A clear but vacuous/redundant definition is not useful.  In RFC7672 I
chose the 4035 variant, because it is actually useful:

   https://tools.ietf.org/html/rfc7672#section-2.1.1

The RFC4033 definition of "indeterminate" is not usefully different
from "insecure", and as you note, with the root signed, is mostly no
longer applicable.

This state is different from "bogus", "insecure" or "secure". The
resolver has an answer whose security status is unknown (indeterminate),
because the records needed to determine that status could not be
obtained (which is different from "missing").

-- 
	Viktor.