[dns-operations] DNS error reporting (was: DNS at FOSDEM 2016)
dot at dotat.at
Wed Feb 10 10:33:39 UTC 2016
Jim Reid <jim at rfc1035.com> wrote:
> > On 9 Feb 2016, at 11:21, Marek Vavruša <marek at vavrusa.com> wrote:
> > - Each code SHOULD have a free-form explanation on what actually
> > happened. This is what humans want to see.
> If so, this is something DNS tools should do. It doesn’t belong in the
> protocol or server-specific code IMO. ie Whatever is returned on the
> wire gets turned into human-friendly text by tools which are
> specifically designed to do that job.
However if there's some policy reason for the rejection it is very helpful
if the server imposing the policy has some way to provide an explanation,
e.g. a URL. A fixed set of codes is hopeless.
(Fixed codes with free text hasn't worked very well in SMTP, but URLs
embedded in the free text compensated for the brokenness.)
To take a recent example, say an operator decided to refuse RRSIG queries
but wanted to provide an explanation. They would like to be able to do
this without having to get a reason code allocated and get all tools
updated to understand it.
> > I'm inclined towards
> > RFC4892 TXT in reserved name reporting (chaos class or not), as it's
> > simple, existing tools will be able to parse and display it and it's
> > flexible enough. Something like:
> > error.server. CH TXT "701"
> > error.server CH TXT "Signature of abcd.is expired 30 days ago.”
> Hmmm. Wouldn’t those (on the fly?) TXT records need to be signed and
> validated somehow?
This is transaction-related information not zone information so it'll be
checked if you are using TSIG or SIG(0). If this isn't going to be an EDNS
option it would be better to allocate a meta-type to make it clear these
records should not appear in zones.
(I agree with Jim's other points, which I seem to have restated!)
Also, shouldn't this be on the DNSOP list? :-)
f.anthony.n.finch <dot at dotat.at> http://dotat.at/
Thames, Dover: West or northwest 5 to 7, decreasing 4 at times later. Moderate
or rough, becoming slight at times later. Showers. Good.
More information about the dns-operations