[dns-operations] DNS error reporting (was: DNS at FOSDEM 2016)

[Mukund Sivaraman]

Hi Shane

On Wed, Feb 10, 2016 at 12:19:09PM +0100, Shane Kerr wrote:
> Still, possibly some people would want multiple languages. In Holland
> we'd likely use Dutch + English. In the US, some places would want
> English + Spanish. In Belgium, French + Dutch + German + English (!!!).
> It might make sense to (optionally?) include an ISO 639 language code
> for each message so errors could be presented in a rational way to the
> user.

If UTF-8 is to be presented to the user, a language code would be
strongly desired due to Han unification. See this table for an example:

https://en.wikipedia.org/wiki/Han_unification#Examples_of_language-dependent_glyphs

> If you really wanted to provide information about multiple errors, a
> slight modification could fix this:
> 
> 0.error.server CH TXT "code: 701"
> 0.error.server CH TXT "info: Signature of abcd.is expired 30 days ago."
> 1.error.server CH TXT "code: 666"
> 1.error.server CH TXT "info: NSEC3 iterations 200, 150 is maximum for 1024 bit ZSK"

It seems a generic JSON RR type would be suitable for such cases (and
more), with JSON as presentation format and some binary representation
of JSON as wire format.

The topic of a JSON RR type came up recently after we saw JSON being
mentioned in the context of catalog zones on some Twitter feeds. We
discarded it as we didn't want to make something up just for the sake of
it and are also removing RR types from catalog zones. The tree structure
of domain name space (RFC 1034 language) itself is like a map, but it
isn't possible to enumerate it via QUERY, except using NSEC and multiple
queries. A JSON RR on its own would have no meaning, much like TXT has
no meaning, but it allows communication of structured data. I fully
expect it to be controversial. :-)

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160210/de047d53/attachment.sig>