Re: [DNSOP] Clarifying referrals (#35)

Tony Finch <> Wed, 29 November 2017 11:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44193124319 for <>; Wed, 29 Nov 2017 03:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3mWEw7TiSsvP for <>; Wed, 29 Nov 2017 03:16:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07A691205F1 for <>; Wed, 29 Nov 2017 03:16:31 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:49956) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eK0Ls-000XwR-2G (Exim 4.89) (return-path <>); Wed, 29 Nov 2017 11:16:28 +0000
Date: Wed, 29 Nov 2017 11:16:28 +0000
From: Tony Finch <>
To: Andrew Sullivan <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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: Wed, 29 Nov 2017 11:16:34 -0000

Andrew Sullivan <> wrote:
> Joe Abley and I have just submitted a draft
> (
> that is intended to capture the discussion here about referrals and
> how to describe them.  It is intended for BCP, and it discourages
> upward referrals by authoritative servers.
> That leaves the task of the referrals definition.  I have some new
> text below:

Regarding the definition of referrals from older RFCs, see my
terminology review from May 2015:

As far as I can tell, RFC 1034 uses the term "referral" for downward
referrals. For instance, section 4.2.1:

  To fix this problem, a zone contains "glue" RRs which are not
  part of the authoritative data, and are address RRs for the servers.
  These RRs are only necessary if the name server's name is "below" the
  cut, and are only used as part of a referral response.

Section 4.3.1:

     A referral to name servers which have zones which are closer
     ancestors to the name than the server sending the reply.

I think that quote implies that other less formal uses of "closer"
specifically mean downward in the DNS tree.

The downward meaning is most clear in the algorithm in section 4.3.2.
Step 3 deals with authoritative data, and says:

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a

Step 4 is where upward referrals come from (when the cache only contains
root hints and no authoritative zone matches the qname), but it does NOT
use the term "referral":

   4. Start matching down in the cache.  If QNAME is found in the
      cache, copy all RRs attached to it that match QTYPE into the
      answer section.  If there was no delegation from
      authoritative data, look for the best one from the cache, and
      put it in the authority section.  Go to step 6.

So I think unqualified "referral" means "downward referral" (from
authoritative data); it's OK to use the term "upward referral" to mean a
response from the cache that looks like a referral but doesn't help to
answer the query. I have also seen the term "implicit referral" meaning
the authority section from a recursive response, since the idea was that a
downstream cache might use those records to answer future queries more
efficiently (though doing that is no longer considered safe).

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Fisher: Northerly 3 or 4, increasing 5 or 6, then becoming cyclonic later.
Moderate, occasionally rough in west. Showers, wintry later. Good,
occasionally poor later.