Loganaden & all,
On 10/08/2019 07.37, Loganaden Velvindron wrote:
On Sat, Aug 10, 2019 at 9:14 AM <internet-dra...@ietf.org> 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
David C Lawrence
Filename : draft-ietf-dnsop-extended-error-07.txt
Pages : 13
Date : 2019-08-09
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
I went to talk to quad9. Here is the reply they sent.
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
DNSOP mailing list