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

Jim Reid jim at rfc1035.com
Tue Feb 9 20:46:28 UTC 2016

> On 9 Feb 2016, at 11:21, Marek Vavruša <marek at vavrusa.com> wrote:
> - Each code SHOULD have a free-form explanation on what actually
> happened. This is what humans want to see.

If so, this is something DNS tools should do. It doesn’t belong in the protocol or server-specific code IMO. ie Whatever is returned on the wire gets turned into human-friendly text by tools which are specifically designed to do that job. 

That said, it would be nice if there was a discrete error code to signal validation failures. But that train left the station a long time ago and it’s unlikely to ever return.

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

So develop diagnostic tools which can do that. Simple matter of programming. Says he who can’t code and is just hand-waving. :-)

> 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.”

Hmmm. Wouldn’t those (on the fly?) TXT records need to be signed and validated somehow?

> I'll be probably implementing something along these lines in Knot Resolver.

I’m not sure it’s a good idea to pile more stuff into the CHAOSNET class. It’s another step down a slippery slope: developing a “registry” of owner-names for error conditions (some of which will be implementation-specific and/or local policy-specifc), perhaps defining special RRtypes and their semantics, etc, etc. How would clients know which owner-names to lookup, or would these TXT-like records be automagically appended to the Additional Section of a reply?

Surely the RDATA would need to be standardised too so that implementations behave consistently when they handle these TXT records? If these messages were left to the discretion of developers, expect inconsistencies and/or ambigious/unclear text depending on which server answered or on its local configuration. For instance: “This answer didn’t validate. Don’t use it.”, “This answer didn’t validate. Do you feel lucky?”, “This answer didn’t validate. So you got no useful response data from me apart from this message.”. Then there’s the potential for American English v British English to add more scope for confusion. Or maybe having to feed Knot’s chatty answers in Czech (say) into google translate and hoping for the best.

There’s already a very wide spectrum of supposedly helpful text appended to the numeric error codes in SMTP and quite probably in HTTP too. I think it would be unfortunate to repeat that mistake in DNS.

More information about the dns-operations mailing list