On Wed, Oct 2, 2019 at 2:43 AM Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote: > > On 9/30/19 11:47 PM, Warren Kumari wrote: > > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch <d...@dotat.at> 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.
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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
