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

From: [email-masked]
Date: Mon, 11 Mar 2019 15:08:10 -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-05.txt
	Pages           : 15
	Date            : 2019-03-11

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.

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-05
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-05

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

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: Puneet Sood <[email-masked]>
Date: Wed, 13 Mar 2019 17:02:41 -0400

My comments on the latest version.

General: Thanks for writing this - it provides useful information for
our public DNS resolver implementation.

> Section 1. Introduction and background
> Para 4. "Authoritative servers MAY parse and use them ..."
Comment: Why talk about auth servers parsing this since this field is
only meant to be present in responses?

> Section 3.1 The R (retry) flag
> Para  2. "implementations may receive EDE codes that it does not understand.
>   The R flag allows implementations to make a decision as to what to do
>   if it receives a response with an unknown code - retry or drop the
>   query."

Comment: It is unclear what should be done if a response contains
multiple EDE options and the R flag value is different across them.

Comment: On a related note, what is the reasoning for allowing
multiple instance of the EDE option in a response versus encoding all
the (Response-CODE, INFO-CODE, EXTRA-TEXT) tuples in a single EDE
option? A single EDE option would avoid having different values for
the R flag and any new flag in the future. 16-bit length field means
that total size of all EDE options should fit in a single option.

> Section 4.1.3 and 4.1.3.1 NOERROR Extended DNS Error Code 3 - Stale Answer
Comment: 4.1.3.1 should be 4.1.3?

> Section 4.2 INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2)
Comment: There are a number of INFO-CODEs here for DNSSEC failures.
Over time it will be extra work for implementations to stay up to date
with new INFO-CODEs added for DNSSEC failures. The R bit signals
whether a resolution should be retried. Do we want also want a bit for
signalling DNSSEC validation failures? Only needed if some DNSSEC
related behavior needs to be different from the R bit value.

> Section 6. Security Considerations
> Para 2: "but until we live in
>   an era where all DNS answers are authenticated via DNSSEC or other
>   mechanisms, there are some tradeoffs."
Comment: Not clear how DNSSEC would help here since the OPT RR is not
protected by any DNSSEC mechanism.

> Appendix A.
Editorial: Missing diff summaries for new versions.

-Puneet

On Mon, Mar 11, 2019 at 6:09 PM <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 24 Mar 2019 12:10:41 +0100

On Mon, Mar 11, 2019 at 03:08:10PM -0700,
 [email-masked] <[email-masked]> wrote 

> 	Filename        : draft-ietf-dnsop-extended-error-05.txt

At the IETF 104 hackathon in Prague, Vladimír Čunát and myself
implemented it in the Knot resolver
<https://www.knot-resolver.cz/>. You can see the result in the git
merge request
<https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/794>
(branch extended_error
<https://gitlab.labs.nic.cz/knot/knot-resolver/tree/extended_error>).

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

Isn't there an error here? 4.1 is the section for NOERROR. What
should be returned for DNSSEC Indeterminate? NOERROR or SERVFAIL? (In
the first case, change the text, in the second, move this paragraph to
4.2.)

Now, implementation experience. We tested with Wireshark and dig (did
not try to develop a client using the extended error code, just the server).

As expected, producing extended error codes is quite simple and the
draft is clear. The camel will be happy.

The biggest issue is of course to find out what to put in the extended
error code. On some resolvers (at least on Knot), the place where the
error is noticed can be quite far from the place where the answer is
built, with its EDNS options. In practice, we had to add data to the
request object, for the extended error information to be carried to
the module that emits the extended error code EDNS option. So, the
real difficulty is not in the draft, but in knowing and understanding
your resolver.

Some details:

* no resolver will use all the response-code/info-codes because some
are never reached for this resolver, or are mixed with other
issues. Generic errors (such as "SERVFAIL Extended DNS Error Code 1 -
DNSSEC Bogus") are useful for when you cannot reliably find the problem.

* the draft is silent about the laying out of bits in info-code. Not
many IETF protocols have an integer field which is larger than a byte
but not byte-aligned.

* the draft has a passing mention that multiple extended error options
are allowed but I don't see how it could be used by the poor client
trying to figure out what happened. I suggest to disallow it.

* the draft has (rightly so) two info-codes for NXDOMAIN/Blocked and
NXDOMAIN/Censored but Knot cannot use it currently since the policy
module (written in Lua) has no way today to be configured to express
the difference. Not a problem in the draft but it will be probably a
common case that the resolver cannot make use of *all* codes.

Let's end with a few examples:

4.2.2.  SERVFAIL Extended DNS Error Code 2 - Signature Expired

% dig  @::1 -p 9053 A servfail.nl         
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12100
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 00 00 20 02 44 4e 53 53 45 43 20 65 78 70 69 72 65 64 20 73 69 67 6e 61 74 75 72 65 73 (".. .DNSSEC expired signatures")
...

4.2.7.  SERVFAIL Extended DNS Error Code 7 - No Reachable Authority

% dig  @::1 -p 9053 A brk.internautique.fr
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38620
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 80 00 20 07 6e 6f 20 4e 53 20 77 69 74 68 20 61 6e 20 61 64 64 72 65 73 73 (".. .no NS with an address")
...

(Not an ideal message but this is quite generic code in Knot.)

4.5.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked

% dig  @::1 -p 9053 A googleanalytics.com 
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1189
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 80 00 30 01 4e 6f 20 74 72 61 63 6b 69 6e 67 ("..0.No tracking")
;; QUESTION SECTION:
;googleanalytics.com.	IN A

;; AUTHORITY SECTION:
googleanalytics.com.	10800 IN SOA googleanalytics.com. nobody.invalid. (
				1          ; serial
				3600       ; refresh (1 hour)
				1200       ; retry (20 minutes)
				604800     ; expire (1 week)
				10800      ; minimum (3 hours)
				)

;; ADDITIONAL SECTION:
explanation.invalid.	10800 IN TXT "No tracking"