Re: [DNSOP] Clarifying referrals (#35)

Mark Andrews <marka@isc.org> Tue, 28 November 2017 20:40 UTC

Return-Path: <marka@isc.org>
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 A4F57127078 for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 12:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2VWaODlQ6ci2 for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 12:40:07 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6245E124239 for <dnsop@ietf.org>; Tue, 28 Nov 2017 12:40:07 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 736CF3ABB53; Tue, 28 Nov 2017 20:39:44 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2E8DC16007A; Tue, 28 Nov 2017 20:39:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2190B160079; Tue, 28 Nov 2017 20:39:43 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NDzbJOY1N9uF; Tue, 28 Nov 2017 20:39:43 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 43A46160047; Tue, 28 Nov 2017 20:39:42 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
Date: Wed, 29 Nov 2017 07:39:42 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <FAA4A6D6-1454-4705-B87F-1FB96CC50658@isc.org>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZhVJdoY8AG0_aZ00cH0h_rmZ7lQ>
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, 28 Nov 2017 20:40:08 -0000

The AA bit may or may not be set depending upon whether the response contains
a CNAME/DNAME or not.  

> On 29 Nov 2017, at 6:50 am, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> 
> Dear colleagues,
> 
> Joe Abley and I have just submitted a draft
> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
> 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:
> 
> ---%<---cut here---
> 
> Referral: A type of response in which a server, signalling that it is
> not authoritative for an answer, provides the querying resolver with
> an alternative place to send its query.  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.
> 
> 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 second is an upward referral (sometimes described as "root
> referral" or just "referral response", as distinct from the delegation
> response above), 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 strictly speaking required to
> work, and in practice some authoritative server operators will not
> return referral responses beyond those required for delegation.
> 
> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
> only include this reference if the other draft reaches WG consensus
> before terminology-bis]
> 
> ---cut here--->%---
> 
> Comments, please.  Also, Joe and I solicit comments on the referrals
> draft proper, but it would be nice to put that in a different thread.
> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> ajs@anvilwalrusden.com
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org