[dns-operations] DNS error reporting (was: DNS at FOSDEM 2016)

[Evan Hunt]

On Tue, Feb 09, 2016 at 11:21:35AM +0000, Marek Vavruša wrote:
> I'd be happy to help as this is something I see as really important.
> Here's what I think:
> 
> - The code system with predefined code numbers makes a lot of sense.
> Personally, I would keep spaces between main error codes to make error
> classification easier later. For example 1XX would be server-internal
> failures (resource constraints, server-is-reloading state ...), 7XX
> would be signature-related failures etc. Like HTTP error codes really.
> This is what machines would like to see.

The classification system in draft-hunt-dns-server-diagnostics-00 
might be a starting place for this?  It's broken into internal server
errors, general DNS errors, and DNSSEC errors.

> - Each code SHOULD have a free-form explanation on what actually
> happened. This is what humans want to see.

Optional supplemental text is part of the proposed ESD option as
well.

> - EDNS is okay, but the drawback is that diagnostic tools like
> kdig/drill/dig or anything similar won't be able to interpret them and
> it won't probably live through forwarder hops. I'm inclined towards
> RFC4892 TXT in reserved name reporting (chaos class or not), as it's
> simple, existing tools will be able to parse and display it and it's
> flexible enough. Something like:
> 
> error.server. CH TXT "701"
> error.server CH TXT "Signature of abcd.is expired 30 days ago."

This is an interesting idea, but it would mean keeping state in
the server for the errors that have been reported recently, rather
than delivering the diagnostic information along with the SERVFAIL
response itself.  "error.server" only works if there's only been
a single error; you'd have to identify which error you're asking
about (e.g. <qname>.<qtype>.<qclas>s.<txid>.error.server/CH/TXT)
and keep a rolling list of answers on hand.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.