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. --Vladimir _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
