IETF Logo Mail Archive

Re: [DNSOP] Clarifying referrals (#35)

Tony Finch <dot@dotat.at> Wed, 29 November 2017 23:13 UTC

Return-Path: <dot@dotat.at>
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 9F5A51201FA for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 15:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 h1KcV106eR6j for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 15:13:09 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D911D127A90 for <dnsop@ietf.org>; Wed, 29 Nov 2017 15:13:08 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 51F95209D1; Wed, 29 Nov 2017 18:13:08 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 29 Nov 2017 18:13:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=r6jg01 0epxf+2If6vqBxaUDzmOioXcI+y5r+41uMo6g=; b=VpeR8KzyJInU0Ymg3nvox4 yXEu7aJoI6IwaZGK/jkkZI+uLPuwz7U2j9Ef5k7ZejnmXd5h//5lVI5LpKyiOKrK iIgrio75hp6dtTv+nGQaQy8vxKc6GRY3bCjTYavDNbgb0y1kLD2UnGKbWAhvFvDl VILLkq21KO3An6GeQTuzOz5GVil6kK27AjoOhww+nNWGLNonNB90BEHF/2tl5ZM6 No53US+D84sieorhbVad5ipqxItzppyUKqBFCRg8wagsDy8bf+aZUhhjMMKwC/AF 35Eh7J5z1ABuePWuj2N7TPIxdHLZ1ZUezAjHcyw1XshJe9VXVSR9rOVdTX5MVAPw ==
X-ME-Sender: <xms:BD8fWlMJNB40GpHXWCpMWCPm91CibNEurmHc33SRCEQTvHCUOlXW9A>
Received: from [192.168.1.128] (unknown [195.147.34.210]) by mail.messagingengine.com (Postfix) with ESMTPA id DC2F924751; Wed, 29 Nov 2017 18:13:07 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail-39F49EBD-7EA4-4060-8FD5-3D8CA3CCD577"
Mime-Version: 1.0 (1.0)
From: Tony Finch <dot@dotat.at>
X-Mailer: iPhone Mail (15B202)
In-Reply-To: <CAKW6Ri4T1h0n2r-Zp5xUUvW4n+u4oFPww2SDRnqwQMBF_wjY0g@mail.gmail.com>
Date: Wed, 29 Nov 2017 23:13:06 +0000
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>, IETF DNSOP WG <dnsop@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at>
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> <CAKW6Ri4T1h0n2r-Zp5xUUvW4n+u4oFPww2SDRnqwQMBF_wjY0g@mail.gmail.com>
To: Dick Franks <rwfranks@acm.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YkHAkeEt7Zrmfpv2S-saNqiX0eY>
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 23:13:11 -0000

> On 29 Nov 2017, at 21:18, Dick Franks <rwfranks@acm.org> wrote:
>> On 29 November 2017 at 12:17, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>> 
>> 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"?
> 
> And said referral could be to an arbitrary node in the DNS tree,  i.e. possibly "upward"?
> 
> Or am I missing something?

In this case we’re dealing with an authoritative answer containing a CNAME pointing out of the server’s authoritative data.

If the server is authoritative only, then there are three cases: (1) the CNAME points to a child zone, so the authority section contains a referral - this is the partial answer plus referral case that Mark described; (2) the CNAME points to a different non-child zone and the server provides full answers, in which case the authority section contains the apex records of the zone containing the CNAME owner; or (3) same as (2) but the server sends minimal answers with an empty authority section.

If it is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 requires the same referral in case (1) because there is a “delegation from authoritative data”; in case (2) you get an implicit referral from the cache (which can be upwards).

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at

v2.23.0 | Report a Bug | By Email