[dns-operations] Error codes or next steps - was Re: DNS at FOSDEM 2016

[Edward Lewis]

On 2/12/16, 9:27, "dns-operations on behalf of Florian Weimer"
<dns-operations-bounces at dns-oarc.net on behalf of fw at deneb.enyo.de> wrote:

>It's particularly bad for the stub resolver because it's not clear if
>you should try another name server if you receive a SERVFAIL response
>from the first one.

Interesting thought - should the error return indicate "what happened" or
should it indicate "what you should do next."

In an prototype DNSSEC validator ('90's vintage), I'd come up with about a
dozen major errors and about fifty minor errors (meaning, 50 more specific
reasons of what went wrong).  Ranging from "couldn't get a needed data
set" to "the time is before the start-date of the signature" and so on.
Considering that the returned value from a request for, say, the address
of a host might involve about a dozen signatures, each of which might be
rejected for a number of reasons, trying to give a specific answer got
unwieldy fast.

What I mean to say is that early in the DNSSEC development, there was
consideration for better error reporting, but there was no solution other
than "SERVFAIL" that scaled.

The situation was (then) and still is poor.  There are tricks to
triangulate the error but the skill needed to do this well is in
short-supply.  There's a need to have better error reporting, saying that
as an endorsement of the effort but offering no help.

The above comment though might turn the problem space around.  How about
defining codes that tell a querier to "try again" or "try later" or "try
another server" or "try a different authority" or "give up and go home."
That is, ultimately, what the DNS system really needs (even if it make the
GUI folks go begging for a reason to show the user).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160212/84d0eed0/attachment.bin>