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

[Marek Vavruša]

Hi,

On 15 February 2016 at 22:20, Shane Kerr <shane at time-travellers.org> wrote:
> Edward,
>
> At 2016-02-12 22:39:41 +0000
> Edward Lewis <edward.lewis at icann.org> wrote:
>> 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).
>
> The DNS system doesn't need anything. The DNS system is fine. :)
>
> But as a USER of the DNS system, I'd really like some more information
> about what is failing. I don't think the idea of providing codes which
> define actions makes sense, because that assumes the server has some
> idea of why I am making a query and what I want to do about failure.
>
> Honestly, whatever text eventually reaches a human being will get cut &
> paste into Google... which is actually probably not a bad thing.
>
> Basically, I like Evan's proposed approach of creating an IANA registry
> of error codes, which will also include what additional data they
> provide. It really needs to be something that can be more-or-less
> easily extended because a lot of stuff will be missed (I just noticed
> that there doesn't seem to be a code for having too many NSEC3
> iterations defined, for example; also I'm not sure what would be
> sent if a client had too many active queries to a server; and so on).

Why not use (e)RCODE for this then? DNS Update already did that, TSIG
did that as well.
Recs are not going to act upon the text explanation anyway, and
debugging is a weak argument for yet-another OPTion.
If I'm investigating what's wrong, then I'm happy if I see a text in
the resolver's response regardless of the format.
People brought up i18n and other things. I think we're overengineering
it - the better codes will serve good purpose for resolvers and
browsers alike, fine. For human debugging it's okay if I fire dig and
see this:

$ kdig @192.168.0.1 AAAA company.is
;; ->>HEADER<<- opcode: QUERY; status: MAINTENANCE; id: 52049
;; Flags: rd qr ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
;; ADDITIONAL
msg.error. IN TXT "Hey this is Bob, I accidentally broke this resolver."

Resolvers are designed to be running close to the end-user. If we're
building DNS towards centralized resolver farms, then I think we have
more pressing issues than internationalising jsonified error messages,
for example not bothering with the whole hierarchy at all.

> I wonder if we could get a Google summer of code project to go through
> BIND 9 and Unbound and PowerDNS Recursor and Knot Resolver and map all
> of the SERVFAIL points in the code to specific errors... :)
>
> Cheers,
>
> --
> Shane

I'm happy to do do that if we agree at least on errcode classes.

Marek
 _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs