Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error status

From: Vladimír Čunát <[email-masked]>
Date: Wed, 2 Oct 2019 08:42:41 +0200

On 9/30/19 11:47 PM, Warren Kumari wrote:
> On Mon, Sep 30, 2019 at 7:54 AM Tony Finch <[email-masked]> wrote:
>> Difficult. In general there will be multiple upstream servers, even in
>> the simplest case of a stub talking to a recursive server talking directly
>> to authoritative servers. So there can be an arbitrary combination of
>> upstream errors, and they might not relate directly to the QNAME, (e.g.
>> problems with a parent zone, problems chasing down nameserver addresses).
> RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) speaketh thusly:
>
> "EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
> negotiated between each pair of hosts in a DNS resolution process,
> for instance, the stub resolver communicating with the recursive
> resolver or the recursive resolver communicating with an
> authoritative server."
>
> and also sayeth:
> "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from
> master files."
>
> I *think* that this covers the issue for many cases; EDE is not
> intended to be a silver bullet, more something which provides useful
> information for troubleshooting / debugging.
> We would not (and cannot :-)) preclude other work from further
> defining this, but I think that it's beyond the scope of this document
> / we will better be able to understand things once we've had some
> deployment experience.

My understanding is that the hop-by-hop condition is just the default
and as suggested we could define/allow e.g. that if all upstreams return
"filtered", we send the same downstream.  I expect we could first
publish RFC without propagation of these errors in mind, but there's a
risk that when we later want to add that, we'll need to make too big
changes, e.g. we may miss something like the near/far flag mentioned
earlier.

If we/you don't want to deal with the propagation now, reserving some
bits for future use (MUST zero now) might be a nice compromise, assuming
we at least have some vague idea that a few of them are likely to be
useful in future.  Another plan might be to do nothing now and later we
might: (1) define another EDNS0 extension that will *separately* carry
information in addition to this EDE or (2) define new flags within the
current EDE and utilize the allowance of sending multiple EDEs.  These
options sound a bit messier to me, but they seem doable.

--Vladimir

---

From: Puneet Sood <[email-masked]>
Date: Tue, 22 Oct 2019 21:55:11 -0400

> options sound a bit messier to me, but they seem doable.

To me the authors' consensus seems to be towards getting EDE into the
real world and learning from its experience to improve it/build
something better. That sounds like EXPERIMENTAL to me. That way
leaving the caching/forwarding behavior unspecified is fine. Based on
experience in the real world, we come back and define/implement EDEv2
and deprecate EDEv1.

Too naive?

For Google Public DNS, EDE or something like it which makes it easier
for users to self-diagnose problems with our responses would be a
great thing.

-Puneet

>
> --Vladimir
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop