[dns-operations] DNS error reporting
edmonds at mycre.ws
Thu Feb 11 18:06:16 UTC 2016
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
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:
"title": "A signature has an unacceptable validity period",
(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 ... :-))
More information about the dns-operations