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

Shane Kerr <> Mon, 26 August 2019 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D59B712011C for <>; Mon, 26 Aug 2019 13:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2GN1UBOfeBD for <>; Mon, 26 Aug 2019 13:34:05 -0700 (PDT)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A431B12004D for <>; Mon, 26 Aug 2019 13:34:05 -0700 (PDT)
Received: from ([2001:470:78c8:2::9]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1i2Lgi-0007IK-1e for; Mon, 26 Aug 2019 20:34:04 +0000
References: <> <>
From: Shane Kerr <>
Message-ID: <>
Date: Mon, 26 Aug 2019 22:34:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-07.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2019 20:34:08 -0000

Loganaden & all,

On 10/08/2019 07.37, Loganaden Velvindron wrote:
> On Sat, Aug 10, 2019 at 9:14 AM <> wrote:
>> 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-07.txt
>>          Pages           : 13
>>          Date            : 2019-08-09
>> 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.
> I went to talk to quad9. Here is the reply they sent.
> Fwd:
> 1) I see at least one more model that needs to be supported, which is
> how to handle edns extended codes that are generated by a remote
> server, i.e. passthrough. Layering multiple forwarding resolvers
> behind each other is common, and some way to notify the end user that
> the originating message was not generated by the first resolver would
> be important.  I don't know if there needs to be some way to indicate
> how "deep" the error was away from the end user; it seems just two
> levels (locally generated or non-locally generated) would be
> sufficient with only minor thought on it.
> Re: 1) This is a good point, but implementation will likely run afoul
> of existing standards or else require duplicative response codes or
> use of an additional flag in the INFO-CODES section.
> Perhaps a new flag type, similar to AA, which can be used to say that
> this recursor will return this result reliably/deterministically.
> Attempting to provide depth is perhaps unlikely, but flags for
> stub/forwarder/recursive/intermediate recursive or a subset of those
> might make sense.
> Perhaps a non-descript flag such as 'DR' for Deterministic Response.
> Obviously INFO-CODES can support many different flags, of which IR
> (Intermediate Resolver) or such could be included
> at the point of response generation, with the last server providing
> actual data in the chain being the one to authoritatively set the
> flag, which then must not be modified by further
> downstream resolvers in the process of returning the response.

Yeah. In principle EDNS0 is hop-by-hop, so getting more information like 
this doesn't really fit in the protocol.

Maybe EDNS1 should include information indicating which hop is 
responsible for any particular bit of EDNS? 😊

> 3) Really, I'd like to see a definition of some of the EXTRA TEXT
> strings here, since that will be almost immediately an issue that
> would need to be sorted out before this could be useful. There have
> been some discussions (sorry, don't know if it's a draft or just
> talking) about browsers consuming "extra" data in DNS responses that
> can do a number of things.  As an example that is important to Quad9
> (or any blocking-based DNS service) it might be the case that upon
> receiving a request for a "blocked" qname/qtype, we would hand back a
> forged answer that leads to a splash page as the default result.
> However, if the request was made from a resolver stack that had the
> EDNS extensions, we might include the "real" result in the EXTRA TEXT
> field, as well as a URL that points the user to an explanation of why
> that particular qname/qtype was blocked.  Or we might add a risk
> factor, or type of risk ("risk=100, risktype=phishing")  or the like.
> This allows a single query to be digestable by "dumb" stacks that we
> want to have do the most safe thing, but also allow "smart" resolver
> stacks to present a set of options to the end user.
> Re: 3) Seems reasonable.

I think this sort of structured information can and probably should be 
included today using the private EDNS option space. Rather than 
embedding parsable information in the EDE equivalent of a TXT record, 
why not just add a new option with this data, which can be defined and