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

[Shane Kerr <[e-mail]>]

Loganaden & all,

On 10/08/2019 07.37, Loganaden Velvindron wrote:
> On Sat, Aug 10, 2019 at 9:14 AM <[e-mail]> 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 
structured?

Cheers,

--
Shane