Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 29 November 2017 12:17 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 690B4127201 for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 04:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-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=gTmZPyzv; dkim=pass (1024-bit key) header.d=yitter.info header.b=lmH6n9b5
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 xs8NwQN4eOWj for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 04:17:43 -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 3A6B6120725 for <dnsop@ietf.org>; Wed, 29 Nov 2017 04:17:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8F759BD337 for <dnsop@ietf.org>; Wed, 29 Nov 2017 12:17:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511957832; bh=dW8rY7xwPFOMtF0xzngKdOvINWY6fxs9KWC6t6TREwM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gTmZPyzvad1GCTl51/RlADQIgdi4TVU69ashy2eVZi3HzXCwZnwgL/D3748bvw78Y qajRplcxVVH76RX9a7VgMa1qTf/r8FW0BKLuh/khDk057Zm1rteUn1udwm9lCST8I5 3uZdjw/FhDc1FC+/m7xNjjZckGyDunxm5cLJgHbo=
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 YvRGvTt3UMjq for <dnsop@ietf.org>; Wed, 29 Nov 2017 12:17:06 +0000 (UTC)
Date: Wed, 29 Nov 2017 07:17:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511957826; bh=dW8rY7xwPFOMtF0xzngKdOvINWY6fxs9KWC6t6TREwM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lmH6n9b5cZbpcKk/zZ4j/+JE/IvWVf0+s/812AnWeR3Obrn3h/wfJMXa761VgRy5B wGwIv1LuLGQeo0eDlN3s9XWmDPkZfNNCB5v+o5s2Gi2OBoFD1flfm2JBLPGzFagIpn qNvdqLUgZ2QCsPOjCvTzz1/n+cs+8jxVmLOcicwU=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kieNnnfTKSggBd-YymkSrQNX1Fs>
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:17:44 -0000

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"?  

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