Re: [DNSOP] Clarifying referrals (#35)

Bob Harold <> Tue, 16 January 2018 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A87A812EB05 for <>; Tue, 16 Jan 2018 12:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H7mkLPZuinbh for <>; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C095F12EAFA for <>; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
Received: by with SMTP id q3so7040176plr.8 for <>; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R5UxF8CTpijrDvVEV3OeYwx9mr/1KFMFR/Jg88iCgro=; b=jlRk4J7Xu7SJ5A2wkKjMJZrGGU3KyL7CuMTtjxXkm5Y4ElGJukFM4uo5UN2wbDpfMW CM6HvWWFbkqtY+OPMG1uqXRbCZZxpPgX5Pu8RIgK+tNsVB8DWJAnHgaVmY4T4BZR0rE6 ORn9BdMMzO9G60xwhY+o6/5fRPoPNBBGb4bLcWwKZ2Tzex5yuTCcFJtQxiefFkxL6RGq YrzuflFkt/Kfs/6Kfm0pMZAFsx/Gdi0Qv/00YmYn6eClkadJJWtKcdHubO5eGr/dXmCV KNHVnh17zgiLudXUb498lJS4FVy1A2+lVmvH05DcovgFVNOSPJGSgqju8CbJMfKibas8 clMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R5UxF8CTpijrDvVEV3OeYwx9mr/1KFMFR/Jg88iCgro=; b=IpmUPQbl1cqzBUCjG4W2y+r+72TyLA0HIUnS5GPu7XVawYpiIGAPAmpCs3nTrAue+p iaJL3+pF9pATeKIlx7yg+Ua/gIF3meW2VhjIl0tVSZLzFszEXOisBYOq3IQKduKabsGW jIFlCcBv1PIHWqjrn77Nv/XAvYZOiqTSKPBShpHEfcVhAeJrYJPG7Sj8z7ZNGLGVjfVC K5kwYmP4VX91WEmrW1OJPghL6c1J1raEfLMU5O8eIEOq0yWf0QS9JBaiDKZya2cnf7+x 9dWp5Irhc3eeE5uVXBcQMg+auZLMe+asSuJ39TyM9e/93vdErD2O/qDJ2cnUChVZxxz8 Xapw==
X-Gm-Message-State: AKwxyteAPPhW0rUQF6iZcErLPds03EKBRzMLgl4DO/J/k+tWww2YdCee z5qgAS/nBHA+wvGQ7PG7HH6mVbXGZG+18LFBtAW/8w8J
X-Google-Smtp-Source: ACJfBosVFmlLk+HjU34MVUQySAbPP0bQn/EaXpb+N0P0oaSKJYtXafC6IgyFU97dm23Tm5XO2j+Q9OFyn2INZHO2JTc=
X-Received: by with SMTP id h9mr27219555plk.46.1516134792209; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 Jan 2018 12:33:11 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Bob Harold <>
Date: Tue, 16 Jan 2018 15:33:11 -0500
Message-ID: <>
To: Andrew Sullivan <>
Content-Type: multipart/alternative; boundary="94eb2c19771ab8bcfc0562eaa341"
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, 16 Jan 2018 20:33:18 -0000

On Mon, Jan 15, 2018 at 4:39 PM, Andrew Sullivan <>

> Hi all,
> Some of you will perhaps recall that previous efforts at text on
> referrals were unsuccessful.  I've had another go.  I _think_ it
> addresses all the comments so far, without actually causing the
> terminology draft to drift into prescribing protocol.  It is
> unfortunately quite a bit longer, but that seems to be the cost of
> making all the points from the discussion.  Thoughts are solicited:
>    Referral:  A type of response in which a server, signalling that it
>       is not (completely) authoritative for an answer, provides the
>       querying resolver with an alternative place to send its query.
>       Referrals can be combined with partial answers.
>       A referral arises when a server is not performing recursive
>       service while answering a query.  It appears in step 3(b) of the
>       algorithm in [RFC1034], Section 4.3.2.
>       There are two types of referral response.  The first is a downward
>       referral (sometimes described as "delegation response"), where the
>       server is authoritative for some portion of the QNAME.  The
>       authority section RRset's RDATA contains the name servers
>       specified at the referred-to zone cut.  In normal DNS operation,
>       this kind of response is required in order to find names beneath a
>       delegation.  The bare use of "referral" means this kind of
>       referral, and many people believe that this is the only legitimate
>       kind of referral in the DNS.
>       The second is an upward referral (sometimes described as "root
>       referral"), where the server is not authoritative for any portion
>       of the QNAME.  When this happens, the referred-to zone in the
>       authority section is usually the root zone (.).  In normal DNS
>       operation, this kind of response is not required for resolution or
>       for correctly answering any query.  There is no requirement that
>       servers send them.  Some people regard upward referrals as a sign
>       of a misconfiguration or error.
>       A response that has only a referral contains an empty answer
>       section.  It contains the NS RRset for the referred-to zone in the
>       authority section.  It may contain RRs that provide addresses in
>       the additional section.  The AA bit is clear.
>       In the case where the query matches an alias, and the server is
>       not authoritative for the target of the alias but it is
>       authoritative for some name above the target of the alias, the
>       resolution algorithm will produce a response that contains both
>       the authoritative answer for the alias, and also a referral.  Such
>       a partial answer and referral response has data in the answer
>       section.  It has the NS RRset for the referred-to zone in the
>       authority section.  It may contain RRs that provide addresses in
>       the additional section.  The AA bit is set, because the first name
>       in the answer section matches the QNAME and the server is
>       authoritative for that answer (see [RFC1035], section 4.1.1).
> --
> Andrew Sullivan

That sounds clear and complete to me!

Bob Harold