Re: [DNSOP] Clarifying referrals (#35)

Mark Andrews <marka@isc.org> Wed, 29 November 2017 12:25 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 2DAC412762F for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 04:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 vMuZWFo4losc for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 04:25:03 -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 0F0F51270AE for <dnsop@ietf.org>; Wed, 29 Nov 2017 04:25:03 -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 BBA433ABF03; Wed, 29 Nov 2017 12:24:31 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 68C32160072; Wed, 29 Nov 2017 12:24:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B49C160055; Wed, 29 Nov 2017 12:24:30 +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 ObyrDm53MZkY; Wed, 29 Nov 2017 12:24:30 +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 9E651160053; Wed, 29 Nov 2017 12:24:29 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info>
Date: Wed, 29 Nov 2017 23:24:27 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <414CA6BA-092D-48C0-859C-834A1B326145@isc.org>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <FAA4A6D6-1454-4705-B87F-1FB96CC50658@isc.org> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <AE976F3F-0270-4484-BCE4-FE0E9BF9D03E@isc.org> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PsVRABeu4BYOvBO3k8W63wp4j3c>
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: Wed, 29 Nov 2017 12:25:06 -0000

> On 29 Nov 2017, at 11:17 pm, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> 
> On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote:
>> When the CNAME refers to a name that is out of zone and the target zone is below
>> a zone that the server serves you will have CNAME (DNAME) + referral.
>> 
>> 4.3.2 loops.
> 
> This part I got.
> 
>> 	pass 1 -> 3a  (adds CNAME, AA is set as it matches the question section, QNAME is updated).
> 
> This is the CNAME response, yes, ok.
> 
>> 	pass 2 -> 3b  (we have a partial match with a bottom of zone cut which adds the referral).
>> 
> 
> Right, and the authoritative server can't proceed, but the referral is
> necessary.  Good, this is helpful, thanks.  This also means, of
> course, that in such a response the answer section isn't empty.  Is
> this why you call it a "partial referral”?  

I said “partial answer + referral”, and yes.

> Best regards,
> 
> A
> 
>>> On 29 Nov 2017, at 1:03 pm, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>>> 
>>> Hi Mark,
>>> 
>>> On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote:
>>>> You can answer only responses, you can have referral only responses,
>>>> you can partial answer + referral responses.
>>> 
>>> Where in the algorithm in section 4.3.2 of 1034 (or other, derived
>>> cases like DNAME) is this "partial answer + referral responses"
>>> described?  If this is well-defined somewhere, I want to refer to it.
>>> If it is not, I wish to describe it clearly, because it seems pretty
>>> obvious given the amount of discussion we've had on this topic that
>>> the notion of referral is nowhere near as clear as people seem to
>>> think it is.  I'm not sure I understand your cryptic remark above, but
>>> I am certain  I can't make it more comprehensible to others without
>>> you telling me that I'm wrong and need to do it over.  So I'm
>>> appealing to you to try to make your view as clear as possible.
>>> 
>>> 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