Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 15 January 2018 21:39 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 29DDE12EC45 for <dnsop@ietfa.amsl.com>; Mon, 15 Jan 2018 13:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=F+I0pOnx; dkim=pass (1024-bit key) header.d=yitter.info header.b=F0R4Bnrj
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 PDEFFtp7s_Lk for <dnsop@ietfa.amsl.com>; Mon, 15 Jan 2018 13:39:22 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FC812EC72 for <dnsop@ietf.org>; Mon, 15 Jan 2018 13:39:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 2CD7ABDA57 for <dnsop@ietf.org>; Mon, 15 Jan 2018 21:39:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1516052362; bh=Fe4BOk/w86Z8l9gQE8WopwzM4YZgR1Pc2OvN71skOrA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=F+I0pOnxYmWuyEN1mO1ZWazYmSRY/rSxUzEj4ex+opN0Wki4jXKkFtLtR35s4qmDT V3YzVXj7paYbzopVCSew/GB4sCzciCPzoMM3riXCi0GNGvorcEGQbORs6/WvZVSom4 BQ5eMHZf7gBfoy7eXKYoBRT8gCXwMQotGcQu54EE=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi8M2j0gs2R6 for <dnsop@ietf.org>; Mon, 15 Jan 2018 21:39:21 +0000 (UTC)
Date: Mon, 15 Jan 2018 16:39:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1516052361; bh=Fe4BOk/w86Z8l9gQE8WopwzM4YZgR1Pc2OvN71skOrA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=F0R4BnrjqjZb7McdU2MpWUzlimn3wz0MKRxGeUJ8mO6TcHv5HuWq49QAviSN3BErH kZLhX+QVBJs+9wX8XzRKdSEC05Nd+if4HY8NNZ3ah3PY3Uh63WP6+RyhQ+g9TQJgI+ fc9Zchqn8TtUtUI/aMfqHQL/IacboOD60lXrPPzI=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180115213920.ukw3wxxdarapzfop@mx4.yitter.info>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RPrBGUsGisu1qSkWAFw7Gaz-2tI>
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: Mon, 15 Jan 2018 21:39:24 -0000

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