[dns-operations] DNS error reporting

[Robert Edmonds]

Petr Spacek wrote:
> On 11.2.2016 12:21, Tony Finch wrote:
> > Robert Edmonds <edmonds at mycre.ws> wrote:
> >>
> >> But, see draft-ietf-appsawg-http-problem for a take on fixing up the
> >> problem in the HTTP world, for HTTP APIs.  If JSON is used to report DNS
> >> errors, there might be some ideas worth borrowing in that draft.
> > 
> > If we use a URL to provide more information then we can avoid re-inventing
> > HTTP. The nice thing about URLs is that the resource can provide a
> > machine-readable application/problem+json response or a human-readable
> > text/html response depending on accept headers.
> 
> I think that URI in response is a good idea but it cannot suffice. Most
> importantly, if local recursive resolver is dead the URI with a host name will
> simply not work :-)

You don't necessarily need to dereference the URI, though.  At least in
draft-ietf-appsawg-http-problem, the "type" URI is used as an
identifier, that "is encouraged to provide human-readable documentation
for the problem type".  It could even be a relative URI.  But the
primary purpose of the "type" URI is to be a stable identifier, IIUC.

draft-ietf-appsawg-http-problem also specifies an "instance" field which
is a URI that can return more information for this particular instance
of the problem.

> E.g. I have seen cases where current time was incorrectly configured on the
> local recursive resolver (1 year in the past, a typo ...) so even the root
> zone did not validate and all queries resulted in SERVFAIL.
> 
> 
> Also, sending human-readable texts does not really work in multi-lingual
> environment.

Comedy option: "EDNS client language" option code :-)

> Can we invent something which is structured enough so the end node can
> translate the message for the user? Or even advise what might be wrong?

Yes, you could have a problem report identified by a stable URI, and
include some structured data like:

    {
    "type": "/dnssec/signature-validity-period",
    "title": "A signature has an unacceptable validity period",
    "now": "20150211123945",
    "name": ".",
    "inception": "20160211040000",
    "expiration": "20160221050000"
    }

(Which is 196 bytes of minimized JSON, BTW.)

The end node then might have a localized template for DNS problems with
type URI "/dnssec/signature-validity-period" that it can pass the JSON
document to and obtain a formatted, localized problem report document
(perhaps plain text if the user agent is a command-line tool, or HTML if
the UA is a browser).

> E.g. if the SERVFAIL from validator with incorrect time contained information
> that validity period started 1 year and 15 days ago and ended 1 year and 5
> days ago the user interface could display the information to the me and I
> would not bang my head against the wall for that long.
> 
> (This was quite surprising because I was constantly looking at time and
> day/month but ignored the year ... :-))

-- 
Robert Edmonds