Subject: [DNSOP] Implementations of extended error?

From: Wes Hardaker <[email-masked]>
Date: Fri, 01 Feb 2019 09:32:40 -0800

Folks,

We (some definite of we, possibly including you) are curious who is
planning (or has already) implemented the Extended Error EDNS0 extension [1]?
As DNSOP is preferring RFCs that have been implemented already, it would
be good to know what plans exist or have been completed.

[1]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

-- 
Wes Hardaker
USC/ISI

---

From: Shane Kerr <[email-masked]>
Date: Fri, 01 Feb 2019 18:38:54 +0100

Wes,

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. 

On 1 February 2019 18:32:40 CET, Wes Hardaker <[email-masked]> wrote:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 01 Feb 2019 13:21:09 -0800

Shane Kerr <[email-masked]> 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.
-- 
Wes Hardaker
USC/ISI

---

From: Anbang Wen <[email-masked]>
Date: Sat, 02 Feb 2019 11:04:47 -0800

Hi Wes,

At Cloudflare, we are testing our crude implementation on our public
resolver which is built on top of knot-resolver. It would be good to
nudge others into working on it.

-- 
Anbang Wen

---

From: Shane Kerr <[email-masked]>
Date: Mon, 4 Feb 2019 11:32:59 +0100

Anbang Wen,

> nudge others into working on it.

Is it already on GitHub or GitLab or something like that? Nudging is 
easier if the first thing to do is "git clone". 😉

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Mon, 4 Feb 2019 11:51:03 +0100

Wes,

> 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

---

From: Dick Franks <[email-masked]>
Date: Mon, 4 Feb 2019 12:06:34 +0000

There is not yet a proper IANA allocated option code for this.

Might I suggest that all interested parties settle on 65015 from the
local/experimental block until the real thing arrives.

Dick Franks
________________________

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Feb 2019 09:03:49 -0800

> local/experimental block until the real thing arrives.

That seems reasonable.

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Feb 2019 09:03:07 -0800

Shane Kerr <[email-masked]> writes:

> 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)

> 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

---

From: Petr Špaček <[email-masked]>
Date: Wed, 6 Feb 2019 17:34:27 +0100

> about what he thinks is valuable in this area).

Thank you for reminding me, Shane!

My personal goal is to provide advice to users "who to call" because
neither user or tech support lines want to waste time on issues they
cannot fix. (ISP is not going to fix botched bank domain, and vice
versa.) It should not (only) a diagnostics tool for DNS geeks!

Let me elaborate:

We at CZ.NIC experience what it is like to be registry (CZ), software
vendor (Knot Resolver), and DNS support team (for Turris routers) at the
same time...

Based on this experience I came to conclusion that it would have
tremendous value if we can split DNS problems to two coarse categories:
far/local end problems. Of course more information is bonus for geeks.

Ideally the error code should provide the client software with enough
information to decide what message should be shown to end-user:

a] inform your system/network admin/ISP
- when a "local" problem is detected
- examples:
-- local time is likely off (. NS signature expired/not yet valid?!)
-- everything times out
-- everything is REFUSED (client blocked for abuse)

b] inform site owner (your bank), do not call your ISP!
- e.g. all auths return REFUSED, botched DNSSEC signatures, ...

I can imagine 4 possibilities:
00 - do not call anyone (no-error messages)
01 - call network admin/ISP
10 - call domain owner
11 - call someone, we do not know what happened

This obviously does not conflict with detailed information in current
proposal, I have nothing against it.

Does it seem useful to others?

-- 
Petr Špaček  @  CZ.NIC