Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie <> Thu, 30 November 2017 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AD45124BFA for <>; Wed, 29 Nov 2017 18:43:59 -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 aSiVeEBxWb3D for <>; Wed, 29 Nov 2017 18:43:58 -0800 (PST)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 027DC120454 for <>; Wed, 29 Nov 2017 18:43:57 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id CAABF61FA2; Thu, 30 Nov 2017 02:43:55 +0000 (UTC)
Message-ID: <>
Date: Wed, 29 Nov 2017 18:43:51 -0800
From: Paul Vixie <>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Andrew Sullivan <>
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: Thu, 30 Nov 2017 02:43:59 -0000

andrew, et al, i see that the discussion continued overnight (i'm here 
in beijing) and i hope you can reach a consensus on the matter. here's 
my input to the terminology of referrals.


According to RFC 1034 section 4.3.2 step 3 substep B, a referral 
"happens when we encounter a node with NS RRs marking cuts along the 
bottom of a zone" and is constructed by copying "the NS RRs for the 
subzone into the authority section of the reply" and putting "whatever 
addresses are available into the additional section, using glue RRs 
if the addresses are not available from authoritative data or the 
cache." By this definition, an answer whose answer section is empty and 
whose authority section contains an NS RR set, is only a "referral" if 
the NS RRs refer to a subzone of an authority server's zone data.


in other words, we need not argue about what a supposedly reasonable 
person may be able to understand or misunderstand from the RFC 1034 text 
and then rephrase it in some way that may raise or lower the risk of 
misunderstanding, or change the results of understanding. all we need to 
is quote the actual 1034 text and hope that whatever supposedly 
reasonable person reads this document, will come to the same conclusions 
they came to when reading 1034.