Evan Hunt wrote:
On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote:
while specific guidance was not given as to resolver action in response
to each possible authority RCODE, i have both witnessed and implemented
full resolvers which treated REFUSED as a permanent failure whereas
SERVFAIL was a temporary failure.
What do you mean by "permanent" in this context?
i mean propagating REFUSED back to the stub so that it can return an
error to its application or user. in SMTP terms this would cause a 4xx
rather than a 5xx. in fact, SMTP might bounce the e-mail rather than
requeuing it for later retry, if an SMTP relay got REFUSED from DNS
rather than SERVFAIL when looking up an MX or AAAA or A to send to.
i have heard a number of folks argue that this logic is common, but i
have heard noone argue that it is superior to known alternatives. can we
hear someone who is in favour of this for reasons beyond "five million
frenchmen cannot be wrong"?
I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only
three answers that make any sense: NOERROR with upward referral, SERVFAIL,
REFUSED. We already disposed of upward referral. SERVFAIL gets you
spurious retries.
SERVFAIL's retries aren't spurious.
... REFUSED makes the querant go away for a sensible amount
of time;
SERVFAIL's have to be cached. perhaps we should document that fact as
part of explaining why REFUSED is wrong-headed for this signaling purpose.
... we have ten years of operational experience with it. I don't see
the problem.
i think we have to be very careful reasoning about nonexistence from an
absence of evidence. not everyone who could be having problems related
to BIND's use of REFUSED from this will recognize it as a BIND problem
or even as a DNS problem, and even if they do, they may not know to
contact ISC or to join this mailing list.
this is one of the few areas in which i agree with the robustness
principle. what you're not seeing doesn't matter nearly as much as what
the people you're not seeing may have coded by looking only at the spec.
at some time when we know how and why to increment the EDNS version
number we should start using NOTAUTH. until then we should be using
SERVFAIL. and we should document the need to cache SERVFAILs.
REFUSED has a well understood purpose when RD=1 and the server has an
ACL, which may mean a mixed-mode server has an "allow-query-cache" ACL.
let us please not treat that as a reason to repurpose REFUSED when RD=0.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
