Re: [DNSOP] draft-ietf-dnsop-extended-error status
On Wed, Oct 2, 2019 at 2:43 AM Vladimír Čunát wrote: > > On 9/30/19 11:47 PM, Warren Kumari wrote: > > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch 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
Re: [DNSOP] draft-ietf-dnsop-extended-error status
On 9/30/19 11:47 PM, Warren Kumari wrote: > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch 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
Re: [DNSOP] draft-ietf-dnsop-extended-error status
On Mon, Sep 30, 2019 at 7:54 AM Tony Finch wrote: > > Wes Hardaker wrote: > > > > 2) One outstanding topic of discussion that I think we need to decide to > > handle or table till a future document: how do we handle forwarding, > > chained resolvers, and caching. > > 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. Thank you, W > Perhaps if the upstream problems are consistent with each other, the > resolver can return a single extended error code to its client; otherwise > fall back to a "multiple errors" catch-all? > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Malin: East backing northeast 5 to 7. Moderate or rough. Showers. Good. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-extended-error status
Wes Hardaker wrote: > > 2) One outstanding topic of discussion that I think we need to decide to > handle or table till a future document: how do we handle forwarding, > chained resolvers, and caching. 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). Perhaps if the upstream problems are consistent with each other, the resolver can return a single extended error code to its client; otherwise fall back to a "multiple errors" catch-all? Tony. -- f.anthony.n.finchhttp://dotat.at/ Malin: East backing northeast 5 to 7. Moderate or rough. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-extended-error status
I've gone through everyone's (wonderful) comments and have addressed almost all of them, and published a -10. Please let me know if you think I missed anything. Responses to the comments will be sent out shortly. (and sorry for the delay on this ; day-job hit me over the head hard in the last three weeks ) Two outstanding topics: 1) A number of people have suggested adding references to other RFCs/documents to many of the error codes. This is probably a good idea. A beer or other drink in Singapore to anyone willing to do the work to give me a list of references to add for each code. 2) One outstanding topic of discussion that I think we need to decide to handle or table till a future document: how do we handle forwarding, chained resolvers, and caching. Puneed brought this up most recently in his comments. In the past we've pseudo-agreed that it will be rather complex to document how to handle forwarding, etc, when some of the error context will change upon a forward, for example. IE, forwarding/caching/whatever rules may end up being code specific and may require a *lot* more thought. So, IMHO, we have choices: A) Label these situations as "undefined behavior" and define it in a future document after we get more experience with deployment. This is typically where I've landed opinion-wise in the past, and still do mostly now. B) Document globally how to handle various cases (and we'll need to enumerate them) C) Document how to handle each one independently (or as an override if needed to a global policy) D) Your option here So really, this first comes down to how important is it we handle this case set before it goes out the door? -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
