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

[Tim Wicinski]

I'd just like to say as co-chair of DNSOP, I'm glad people have revived 
and enhanced Evan's initial draft.

tim

On 2/15/16 4:49 PM, Warren Kumari wrote:
>
>
> On Fri, Feb 12, 2016 at 6:09 PM Edward Lewis <edward.lewis at icann.org
> <mailto: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
>     <mailto:dns-operations-bounces at dns-oarc.net> on behalf of
>     fw at deneb.enyo.de <mailto: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
>     <mailto: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
>
>
>
> _______________________________________________
> 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
>