Subject: Re: [DNSOP] Implementations of extended error?
From: Petr Špaček <[email-masked]>
To: [email-masked]
Date: Wed, 6 Feb 2019 17:34:27 +0100
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

On 04. 02. 19 11:51, Shane Kerr wrote:
> * 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).

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