Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie <> Tue, 14 November 2017 08:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09FCC128D19 for <>; Tue, 14 Nov 2017 00:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id unKLLzy1ayqS for <>; Tue, 14 Nov 2017 00:21:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98308127077 for <>; Tue, 14 Nov 2017 00:21:12 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 82ABB61FA2; Tue, 14 Nov 2017 08:21:12 +0000 (UTC)
Message-ID: <>
Date: Tue, 14 Nov 2017 00:21:11 -0800
From: Paul Vixie <>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Evan Hunt <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] Clarifying referrals (#35)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2017 08:21:14 -0000

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