Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Petr Špaček <[e-mail]>]

On 24. 10. 19 19:56, Warren Kumari wrote:
> On Tue, Oct 22, 2019 at 6:49 AM Tony Finch <[e-mail]> wrote:
>>
>> Petr Špaček <[e-mail]> 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