[dns-operations] Error codes or next steps - was Re: DNS at FOSDEM 2016

[Warren Kumari]

On Fri, Feb 12, 2016 at 6:09 PM Edward Lewis <edward.lewis at icann.org> wrote:

> On 2/12/16, 9:27, "dns-operations on behalf of Florian Weimer"
> <dns-operations-bounces at dns-oarc.net on behalf of fw at deneb.enyo.de> wrote:
>
> >It's particularly bad for the stub resolver because it's not clear if
> >you should try another name server if you receive a SERVFAIL response
> >from the first one.
>
> Interesting thought - should the error return indicate "what happened" or
> should it indicate "what you should do next."
>
> In an prototype DNSSEC validator ('90's vintage), I'd come up with about a
> dozen major errors and about fifty minor errors (meaning, 50 more specific
> reasons of what went wrong).  Ranging from "couldn't get a needed data
> set" to "the time is before the start-date of the signature" and so on.
> Considering that the returned value from a request for, say, the address
> of a host might involve about a dozen signatures, each of which might be
> rejected for a number of reasons, trying to give a specific answer got
> unwieldy fast.
>
> What I mean to say is that early in the DNSSEC development, there was
> consideration for better error reporting, but there was no solution other
> than "SERVFAIL" that scaled.
>
> The situation was (then) and still is poor.  There are tricks to
> triangulate the error but the skill needed to do this well is in
> short-supply.  There's a need to have better error reporting, saying that
> as an endorsement of the effort but offering no help.
>
> The above comment though might turn the problem space around.  How about
> defining codes that tell a querier to "try again" or "try later" or "try
> another server" or "try a different authority" or "give up and go home."
> That is, ultimately, what the DNS system really needs (even if it make the
> GUI folks go begging for a reason to show the user).
>


Well, in the (revived) Evan draft (
https://github.com/wkumari/draft-wkumari-dnsop-extended-error) we had:
"o  FLAGS, 2 octets.

o  CODE, 2 octets.

Currently the only defined flag is the R flag.

R - Retry  The R (or Retry) flag provides a hint to the receiver if
it should retry the query, possiably by querying another server.
If the R bit is set (1), the sender believes that retrying the
query may provide a sucessful answer, if the R bit is clear (0),
the sender believes that it should not ask another resolver.

The remaining bits in the flags field MUST be set to 0 by the sender
and MUST be ignored by the receiver."

This doesn't provide the granularity that you were suggesting, but may get
close - I cannot think of many situations where a particular machine may
return an error now, but believe that it will know a useful answer "soon".
I'd considered the "I'm still booting / loading my zones from disk" as one
possible instance of this, and a "Help, I'm being DoSed, please back off"
as another, but both feel like corner cases / best solved in other ways.

My main idea for the use of the flag was more of a "Please *don't* retry."
- this way, if e.g: some monkey has delegated a zone to me which I *know*
I'm not authoritative for I can return the Extended Error EDNS option with
the bit cleared, and folk would know not to bother poking other
name-servers.

W



> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160215/fad7843d/attachment.html>