[dns-operations] Error codes or next steps - was Re: DNS at FOSDEM 2016
paul at redbarn.org
Tue Feb 16 02:26:17 UTC 2016
Marek Vavruša wrote:
> 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... :)
this sounds right to me.
More information about the dns-operations