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

[Vladimír Čunát <[e-mail]>]

On 9/30/19 11:47 PM, Warren Kumari wrote:
> On Mon, Sep 30, 2019 at 7:54 AM Tony Finch <[e-mail]> 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