<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 12, 2016 at 6:09 PM Edward Lewis <<a href="mailto:edward.lewis@icann.org">edward.lewis@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2/12/16, 9:27, "dns-operations on behalf of Florian Weimer"<br>
<<a href="mailto:dns-operations-bounces@dns-oarc.net" target="_blank">dns-operations-bounces@dns-oarc.net</a> on behalf of <a href="mailto:fw@deneb.enyo.de" target="_blank">fw@deneb.enyo.de</a>> wrote:<br>
<br>
>It's particularly bad for the stub resolver because it's not clear if<br>
>you should try another name server if you receive a SERVFAIL response<br>
>from the first one.<br>
<br>
Interesting thought - should the error return indicate "what happened" or<br>
should it indicate "what you should do next."<br>
<br>
In an prototype DNSSEC validator ('90's vintage), I'd come up with about a<br>
dozen major errors and about fifty minor errors (meaning, 50 more specific<br>
reasons of what went wrong).  Ranging from "couldn't get a needed data<br>
set" to "the time is before the start-date of the signature" and so on.<br>
Considering that the returned value from a request for, say, the address<br>
of a host might involve about a dozen signatures, each of which might be<br>
rejected for a number of reasons, trying to give a specific answer got<br>
unwieldy fast.<br>
<br>
What I mean to say is that early in the DNSSEC development, there was<br>
consideration for better error reporting, but there was no solution other<br>
than "SERVFAIL" that scaled.<br>
<br>
The situation was (then) and still is poor.  There are tricks to<br>
triangulate the error but the skill needed to do this well is in<br>
short-supply.  There's a need to have better error reporting, saying that<br>
as an endorsement of the effort but offering no help.<br>
<br>
The above comment though might turn the problem space around.  How about<br>
defining codes that tell a querier to "try again" or "try later" or "try<br>
another server" or "try a different authority" or "give up and go home."<br>
That is, ultimately, what the DNS system really needs (even if it make the<br>
GUI folks go begging for a reason to show the user).<br></blockquote><div><br></div><div><br></div><div>Well, in the (revived) Evan draft (<a href="https://github.com/wkumari/draft-wkumari-dnsop-extended-error">https://github.com/wkumari/draft-wkumari-dnsop-extended-error</a>) we had: </div><div><div>"o  FLAGS, 2 octets.</div><div><br></div><div>o  CODE, 2 octets.</div></div><div><br></div><div>Currently the only defined flag is the R flag.</div><div><br></div><div>R - Retry  The R (or Retry) flag provides a hint to the receiver if</div><div>it should retry the query, possiably by querying another server.</div><div>If the R bit is set (1), the sender believes that retrying the</div><div>query may provide a sucessful answer, if the R bit is clear (0),</div><div>the sender believes that it should not ask another resolver.</div><div><br></div><div>The remaining bits in the flags field MUST be set to 0 by the sender</div><div>and MUST be ignored by the receiver."</div><div><br></div><div>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".</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>W</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
dns-jobs mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a></blockquote></div></div>