> On Sep 13, 2019, at 9:38 AM, Paul Hoffman <paul.hoff...@icann.org> wrote:
>
>> "There are many reasons that a DNS query may fail, some of them
>> transient, some permanent; some can be resolved by querying another
>> server, some are likely best handled by stopping resolution.
>> Unfortunately, the error signals that a DNS server can return are
>> very limited, and are not very expressive."
>
> Fully agree. That's why I'm pressing for clarification by addition of
> determinative text, not just removal of confusing text.
If more fine-grained RCODEs are needed, then perhaps bite
the bullet and add them as EXTENDED-RCODEs in the currently
unassigned range:
23 - 3,840
0x0017 - 0x0F00
with the limitation that new EXTENDED-RCODE values are for
legacy clients implicitly refinements of SERVFAIL, since a
client that does not understand a new RCODE can only treat
it as some sort of unknown failure.
With EDEs as largely diagnostic refinement, the EXTENDED-RCODE
remains unchanged and dispositive, and the EDE do not generally
change client behaviour.
There are perhaps cases where a client might choose to not retry
a query that returned REFUSED when the EDE is:
3.16. Extended DNS Error Code 15 - Blocked
3.17. Extended DNS Error Code 16 - Censored
3.18. Extended DNS Error Code 17 - Prohibited
3.19. Extended DNS Error Code 18 - Filtered
3.22. Extended DNS Error Code 21 - Deprecated
or not retry a SERVFAIL when the EDE is:
3.21. Extended DNS Error Code 20 - Lame
if it is reasonable to expect the same response from any
other nameservers one might use in retries. Is it the
intent of this draft that the above or similar would
be used by some clients to make retry/abort decisions?
If so, perhaps it then makes sense to specify the EXTENDED-RCODE + EDE
combinations that go beyond mere diagnostic information, and would be
potential "permanent" errors.
If an iterative resolver encounters a REFUSED from its upstream,
in combination with one of the "permanent" EDEs, might it then
in turn return REFUSED with the same EDE to its client (without
retrying) rather than SERVFAIL after exhausting all upstream
servers (presumably its present behaviour)?
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
