On 24. 10. 19 19:56, Warren Kumari wrote: > On Tue, Oct 22, 2019 at 6:49 AM Tony Finch <[email protected]> wrote: >> >> Petr Špaček <[email protected]> wrote: >>> >>> 2. Second problem is that it is uncelar if there is going to be a >>> consumer: Did *anyone* from stub resolvers said a word about this draft? >>> Is it useful as it is? >> >> I expect almost no-one can do anything with EDE without >> getaddrinfo() EAI_ return code extensions. >> > > I would personally find this to useful if only dig (or drill or delve > or...) supported this -- it's currently hard to actually debug weird > DNS failures, and simply providing information to a human using > diagnostic tools would be helpful. > This and the "DNSSEC bogus -> ask another resolver" are to my mind the > primary uses...
In my personal experience most of "hard to debug errors" involve forwarding (because lack of visibility into forwarding chain), so I do not see extended-errors being super useful in its current form. As a result, from my perspective exposing EDE information only in dig (and other tools for geeks) *does not* justify the investment needed on resolver side. On the other hand, *if the information is exposed to end-users* in a form which actually helps to direct complains from users to appropriate places, then the cost/benefit situation is completely different and I'm all for it! -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
