Re: [DNSOP] Implementations of extended error?

[Shane Kerr <[e-mail]>]

Wes,

On 01/02/2019 22.21, Wes Hardaker wrote:
> Shane Kerr <[e-mail]> writes:
> 
>> I was thinking about adding some support for this at the IETF hackathon, but I'll be
>> meeting with some of the open source DNS folks this weekend at FOSDEM, and seeing if
>> that collides with their existing plans.
> 
> Excellent!  I look forward to hearing the reports of the conversations.

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. The stub side is also super-important, so maybe I should 
look at that too.

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. I'm not so worried about that, as any 
additional information seems better than SERVFAIL to me. 😉

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

* ISC has no specific plans for BIND, but will implement extended error 
codes eventually. "Looks like a reference implementation if you stand 
back a bit and squint."

* CZ.NIC has no plans for Knot Resolver, and still have to look 
carefully at the latest draft (although Petr has some interesting ideas 
about what he thinks is valuable in this area).

* NLnetLabs has no specific plans, but Willem thinks that it is cool and 
wants to work with me on it at the Hackathon. Maybe I can work on 
Unbound and he can work on getdns, so we can have inter-operable tests 
(admittedly from a single company).

I forgot to ask anyone from PowerDNS, which is kind of stupid of me 
since they did 99% of the work for the DNS devroom at FOSDEM (especially 
Peter van Dijk).

As far as the stub side, I also didn't ask anyone from the 
systemd-resolverd side, but given that they apparently disable basically 
all DNS functionality introduced after RFC 1035 by default, I don't know 
how useful support there would be.

And finally also on the stub side, I did not talk to anyone on the glibc 
team or anyone of the distribution folks depending on it.

Apologies for any incorrect reporting here, and for anyone that I omitted.

Cheers,

--
Shane