Subject: Re: [DNSOP] Implementations of extended error?
From: Wes Hardaker <[email-masked]>
To: Shane Kerr <[email-masked]>
Cc: Wes Hardaker <[email-masked]>, [email-masked]
Date: Tue, 05 Feb 2019 09:03:07 -0800
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

Shane Kerr <[email-masked]> writes:

> My own thinking is that extended error is much more important on the
> resolver side than on the authoritative side, so that's what I was
> asking about.

That's fair; it's a generic mechanism but authoritative servers have less
reason to return most of the codes (though I cloud see Prohibited and
Blocked being useful for authoratatives).

(And actually, I just read the "Lame" description in the draft, and it's
actually broken.  It should talk about what to do for both.  I've now fixed
that and will push a new version)

> There was some discussion that it might be tricky to get correct
> information out of the bowels of a resolver that wasn't designed with
> this sort of reporting in mind.

Yeah, I suspect there are some code bases that this simply won't work with EDE
without a major rearchitecture.  If they're currently returning a
single error code from the depths of a stack trace, they won't be able
to easily return either a double-code or potentially modify their
codes to be more descriptive.  Then we get to "error text" as well and
it gets worse.

> Here's what I took away (people can and should correct me where I am wrong):

Thanks for the summary!  Sounds like it was a good discussion.

-- 
Wes Hardaker
USC/ISI