[dns-operations] DNS error reporting

[Tony Finch]

Paul Hoffman <phoffman at proper.com> wrote:
> On 15 Feb 2016, at 16:10, Tony Finch wrote:
> > Warren Kumari <warren at kumari.net> wrote:
> > >
> > > Can someone remind me again what is wrong with simply have a 16 bit error
> > > code, and having this reference an IANA operated registry?
> >
> > If someone invents a new blocking policy, they want to be able to deploy
> > it without going through IANA, and still provide meaningful help to
> > clients who want to understand why.
>
> That doesn't have to come in the error code. It is trivial to create an
> error code that says "repeat this query with RRtype=FULLERRORTEXT" to
> deliver the message.

A secondary request to get the full reason could work OK, yes, and it has
the advantage of separating debug activity from normal traffic. Changing
the RRtype will not work because the error can be type-dependent.

> > It would be nice not to repeat the mistakes of SMTP.
>
> SMTP allows text messages in error responses, so I'm not what this
> means.

SMTP errors are a disaster area.

The error codes are too coarse-grained to be of any practical use in cases
that users care aboue, so you have to rely on the free text to know what
actually went wrong. But the intent of enhanced status codes was that they
should be comprehensive enough that software could reasonably ignore or
replace the free text (e.g. for localization). This turned out to be
wrong, but even so, a lot of software follows this intent and mangles or
destroys the free text explanation, which makes debugging much harder
than it should be.

A valid point of enhanced status codes was that a small ASCII-only field
is hopeless for i18n. But in practice (especially in the last 10 years or
so) the most successful use of the field has been to hold a URL. Then a
web server can do the heavy i18n work making the problem moot, and this
also lifts the bureaucratic limit on how many reasons there might be for
breakage. The status code can then be a rough category rather than being
the entire explanation you can get.

A lot of the proliferation of reasons for failure in SMTP were to do with
attempts to stop or mitigate abuse. Abuse is now something the DNS has to
deal with so it will also have to cope with collateral damage from lots of
wild new "clever" anti-abuse mechanisms.

For example, at the moment it's normal for hostmasters who deploy RPZ to
block sites by returning a CNAME pointing at a helpful web server. This
does not work well with DNSSEC: the hostmaster is stuck with a choice
between sending bogus data, sending SERVFAIL, or sending evil data.

It would be very nice if the server could say, "SERVFAIL (p.s. reason type
XYZ)", then the client could say, "tell me the details of your reason",
and get the helpful URL. Seems like a fair combination of safety and
honesty to me.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Lundy, Fastnet, Irish Sea: Variable 4, becoming southwest 5 to 7 increasing
gale 8 at times later. Moderate or rough, occasionally very rough later. Rain
later. Good, becoming moderate or poor later.