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

From: [email-masked]
Date: Tue, 05 May 2020 13:51:27 -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-16.txt
	Pages           : 15
	Date            : 2020-05-05

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

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

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: Thu, 14 May 2020 01:48:39 -0400

Google Public DNS is planning to implement this draft in responses
from us (recursive resolver) to clients.

*** Question: When can we expect to have an EDNS option code assigned
for the EDE option?

*** Request for clarification on Section 3. Extended DNS Error Processing
The text in this section (and in the introduction) implies that a
response with a NOERROR RCODE may contain an EDE option.
"Receivers MUST be able to accept EDE codes and EXTRA-TEXT in
 all messages, including those with a NOERROR RCODE, but need not act
 on them"

Scenario: Response has a NOERROR RCODE and contains some response RRs.
If the client sent an EDE option and the server supports EDE, is the
expectation that the server should always include the EDE option?

If the server includes an EDE option in the response, what is the
right EDE code to use? EDE code 0 [other] seems the closest but it
still implies an error. Also the description for it suggests including
EXTRA-TEXT which would not be useful.

If the server does not include an EDE option in the response, the
response looks A-OK to the client. However if the client is attempting
to detect EDE option support on the server it might incorrectly assume
the server does not support EDE.

To simplify the NOERROR scenario, can we have a no error EDE code
similar to the NOERROR RCODE? With this a server can include an EDE
option in all responses to queries containing an EDE option.

Thanks,
Puneet

On Tue, May 5, 2020 at 4:52 PM <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 May 2020 16:09:34 +1000

> On 14 May 2020, at 15:48, Puneet Sood <puneets=[email-masked]> wrote:
> 

It’s already assigned. See the IANA registry.  The value is 15.

> expectation that the server should always include the EDE option?

No.  While not explicitly specified a server would only include a EDE
if it have something extended to report.

There is also no requirement for there to be a EDE in the request
before sending a EDE in a response.  If EDE was expected to be in the
request then there would have been a request format specified.  All
EDNS clients should handle unknown EDNS options in responses as that
is a requirement of the base EDNS specification.

> the server does not support EDE.

There is no reliable way to determine if a server supports EDE.  There is
no requirement to return any given EDE.  Which EDE return (if any) is up to
the server developer.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Puneet Sood <[email-masked]>
Date: Thu, 14 May 2020 14:51:55 -0400

> is a requirement of the base EDNS specification.

Thanks for clarifying this. Makes the resolver response logic much simpler.
I had incorrectly remembered that the client had to specify this option in
the request.

-Puneet

> PHONE: +61 2 9871 4742 <+61%202%209871%204742>              INTERNET:
> [email-masked]
>
>