Re: [DNSOP] Clarifying referrals (#35)

Robert Edmonds <> Mon, 13 November 2017 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41769129B39 for <>; Mon, 13 Nov 2017 12:20:22 -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 ph_JsgcYFFdg for <>; Mon, 13 Nov 2017 12:20:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4215A1241F3 for <>; Mon, 13 Nov 2017 12:20:21 -0800 (PST)
Received: by (Postfix, from userid 1000) id 84CF012C1555; Mon, 13 Nov 2017 15:20:20 -0500 (EST)
Date: Mon, 13 Nov 2017 15:20:20 -0500
From: Robert Edmonds <>
To: Paul Vixie <>
Cc: Matthew Pounsett <>, "" <>,, Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <> <20171113085235.2fddd72a@p50.localdomain> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
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: Mon, 13 Nov 2017 20:20:22 -0000

Paul Vixie wrote:
> Matthew Pounsett wrote:
> > I haven't got the time this morning to search release notes, but I'm
> > fairly sure that in 2012, when you wrote that article, current versions
> > of BIND were already handing out REFUSED to indicate "I'm not
> > authoritative for that."  At the very least it began doing that not long
> > after.
> the implication of REFUSED is that if someone else asked this question, we
> might be able to answer. so if BIND is doing what you say, it's wrong.

In theory, any authoritative nameserver could secretly also be a
resolver that will answer from cache if the right client sends it the
same question. Does that make it OK, then?

The REFUSED RCODE is documented as:

    Refused - The name server refuses to perform the specified operation
    for policy reasons.  For example, a name server may not wish to
    provide the information to the particular requester, or a name
    server may not wish to perform a particular operation (e.g., zone
    transfer) for particular data.

In this case the server's policy would be that it doesn't perform a
particular operation (i.e., QUERY) for particular data (i.e., data that
it's not authoritative for).

Where does the implication that REFUSED is only appropriate if the
server might be able to answer if "someone else" asks the question come

Robert Edmonds