Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie <[e-mail]>]

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