Re: [DNSOP] Clarifying referrals (#35)

Bob Harold <rharolde@umich.edu> Tue, 16 January 2018 20:33 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87A812EB05 for <dnsop@ietfa.amsl.com>; Tue, 16 Jan 2018 12:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7mkLPZuinbh for <dnsop@ietfa.amsl.com>; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C095F12EAFA for <dnsop@ietf.org>; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
Received: by mail-pl0-x22a.google.com with SMTP id q3so7040176plr.8 for <dnsop@ietf.org>; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; 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; d=1e100.net; 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 10.84.232.9 with SMTP id h9mr27219555plk.46.1516134792209; Tue, 16 Jan 2018 12:33:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.139.5 with HTTP; Tue, 16 Jan 2018 12:33:11 -0800 (PST)
In-Reply-To: <20180115213920.ukw3wxxdarapzfop@mx4.yitter.info>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20180115213920.ukw3wxxdarapzfop@mx4.yitter.info>
From: Bob Harold <rharolde@umich.edu>
Date: Tue, 16 Jan 2018 15:33:11 -0500
Message-ID: <CA+nkc8D2=08kY0Yktq6Xe6jGee9G7hVR1qsWf4jW90VfnVfVcw@mail.gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19771ab8bcfc0562eaa341"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OGkhHkKgeaoXNFWV-sjXsKEtirs>
Subject: Re: [DNSOP] Clarifying referrals (#35)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 20:33:18 -0000

On Mon, Jan 15, 2018 at 4:39 PM, Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:

> 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
> ajs@anvilwalrusden.com
>


That sounds clear and complete to me!

-- 
Bob Harold