Re: [DNSOP] Implementations of extended error?

2019-02-06 Thread Petr Špaček
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

2019-02-06 Thread Mukund Sivaraman
On Fri, Jan 18, 2019 at 06:55:16PM +0100, Benno Overeinder wrote:
> Please review this draft to see if you think it is suitable for
> adoption by DNSOP, and comments to the list, clearly stating your
> view.

Considering that the method is implementable without any changes at a
resolver, and that it doesn't require compatible behavior among DNS
implementations ("protocol" or best practice), I suppose it does not
matter if this draft is adopted or not as long as the idea has been
described somewhere.

Mukund

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop