Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan <> Thu, 30 November 2017 01:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59D581287A3 for <>; Wed, 29 Nov 2017 17:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=BETYr7Tc; dkim=pass (1024-bit key) header.b=WHNUEA4Z
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6573c_1KaLJU for <>; Wed, 29 Nov 2017 17:59:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1787127136 for <>; Wed, 29 Nov 2017 17:59:35 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85138BD337 for <>; Thu, 30 Nov 2017 01:59:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1512007144; bh=p/Rtz3TBbf4gb5I/s0ZqW6zoRemIdd4m71fjIFHRJgQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BETYr7TcTD4GXjKRCWuOdwBJJIL2ZErn+o9o9P4ZSQZWOL2uw1Pk8VA3mPakEYWr4 Wgc56FYdczPqCG8dPsyvvnKdpjkF7pswU3oEx/xYwBR1+7Uam1/JFa/B4EweG6vyio QNCdGkcz/77cUrzMpKx+/5OyCTcGBcVJI7dTKipw=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1sCqvcWKT0it for <>; Thu, 30 Nov 2017 01:59:02 +0000 (UTC)
Date: Wed, 29 Nov 2017 20:59:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1512007142; bh=p/Rtz3TBbf4gb5I/s0ZqW6zoRemIdd4m71fjIFHRJgQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=WHNUEA4ZvQwkeBUK6noanUuS9emey2VVwCm+BR/9boTD+QiJaoVuUw28ToC1T+bEj sAhqv2hRmwGoO1bV0MJGr6oGtaZf6ZjlriG/4S45GcbUJnNDKPwGMPDuU5Ew041MdM TBGVfcElBl7s8s/vjW4mZwRlC4WP4dV+6waITgSY=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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: Thu, 30 Nov 2017 01:59:37 -0000

On Wed, Nov 29, 2017 at 11:34:12PM +0000, Tony Finch wrote:
> Normal (downward) referrals come from authoritative data, and indicate the server is saying to the client, you need to ask here next; on the other hand these special kinds of referrals come from the cache. An implicit referral comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the client where the answer came from; if RD=0 or RA=0 you can get an upward referral, which indicates the server is telling the client where the server would ask next in order to fill its cache.

I think that's correct.  But what is not plain to me in my reading,
insistent noises on the list notwithstanding, is whether the second ¶
in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still
part of what "a referral" means.  The ordinary English meaning, as far
as I can tell, of that 3.b subsection is that everything one does as
part of step 3.b is a referral response.

The problem is that "Go to step 4" is part of that last ¶, not a new
¶, and so what I think is obscure in the algorithm text is whether the
stuff you're copying into the response in step 4.

I tend to agree that the other parts of STD 13 argues in favour of at
least "upward referrals are a degenerate case" and maybe even "upward
referrals are _not_ referrals in the bare word sense."

But while I find that reading persuasive, there are two important
facts to consider: for a long time, that was not actually the reading
people adhered to, and there does not seem to have been a lot of
complaining about it (indeed, even djb's remarks about DNS barely
suggest this is a fault of the server, and AFAICT he thought that BIND
was responsible for bubonic plague when he wrote those notes).
Second, we should not expect, in fairness, an earnest reader to do the
same synoptic reading that others have done, or to reach the same
conclusion.  It's at least as likely that such a reader will conclude
that RFCs 1034 and 1035 are written with a certain lack of
terminological rigour -- which is perhaps borne out by the effort we
apparently need to make to clarify a term as fundamental as

I don't think anyone in this discussion disagrees about how things
_ought_ to operate.  But in the terminology document, I think we have
tried to preserve the meanings that persist on the Internet.  I find
it very hard to convince myself either that upward referrals are dead,
or even that lots of people don't use "referral response" to mean
"referral to the root".  I encounter both of these ways of speaking
with some regularity.  Maybe my sample is really skewed; but I think
it is at least as plausible that people who are clued into the DNS
think that upward referrals are bad and that therefore all referrals
must be down.

> implicit referrals and upward referrals are supposed to be cache-filling gossip (in the distributed systems sense of gossip protocols).

I like this observation.  Thanks.

Best regards,


Andrew Sullivan