Re: [DNSOP] Clarifying referrals (#35)

Dick Franks <rwfranks@acm.org> Wed, 29 November 2017 23:29 UTC

Return-Path: <rwfranks@gmail.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 15E2012700F for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 15:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Lo0Kn1oAz8GC for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 15:29:01 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8C21286CA for <dnsop@ietf.org>; Wed, 29 Nov 2017 15:28:59 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id y82so38298400wmg.1 for <dnsop@ietf.org>; Wed, 29 Nov 2017 15:28:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GQuZ7DbMbUko/Ci9BbhbNkxkMjQIl+QckjBUhO644uw=; b=IOu+r04kygnBjeb9bt04HIw+LeVBt9ufFcK6EmSrLcMvzPIUQ655xJQGrPSwR95IAs C/TjVzMLqzJHLwcqBZG8nIDjCuFOUdFKQ9hiM+/nKNoIPlanlwMc6wD2hl2hzeFqJkXt AVz03tcsDT3hVLcfaj93SRIOjMRHmmQbthHelaZtSWwaxRwPpYhdwVhsoNn548r4p03R S302xEYqt0W4FmupysyM748VKGCakgbZyQxRFG6ORwzSSTekmnFcNp9i0MiU++IqY7Jn xC1wHcbmM7f4/9YiOww7lwxpFioT9Xcv/CJstKT8ofOTGqHzZRDBQL4qfcvbd/HR+3La LC3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GQuZ7DbMbUko/Ci9BbhbNkxkMjQIl+QckjBUhO644uw=; b=nPndDx00+BOjIqFqmY6JnOUw0Uf9es3fbUqXFaQadxm1sgUk90tb/PJEQYmGDujpao 94P86T7FCq7pQ/iuv9D+JOsK+TE+06piDzKTsp9t2PxhACFXeN9rF2rhzE3J2JbSt3ib DKU2h4NpVfiYVpbRXebEaaL06ZK4ecyiId4RVvC+xoa0yX7juveTuZDPe0ExvVylr/2b NoZPUdrmA6hvMLMYKuY9wlMlorHYap/iDGbqDXJtRXWHb7MoH66FM12Ar4XMK5gRbLYS cdOXHm6k8X1APLvVxYMj+2AVqX1DD+ZOgoSJeHxmfBNjqsLroZOFCNFC6Ie7aOX0jM0c 0t/A==
X-Gm-Message-State: AJaThX6Hjrdolbh8P5Y2TK5s8J0iQ5G5sVB4wEe0w46VLD/2iKeVyEvN QurbyheGRxBPTfAhLNKPbUznul56CqBf/G4efOQ=
X-Google-Smtp-Source: AGs4zMbK3bciNlwekxTREGh3KInaFf3irfzdLZmxRmUei8WzSepVtnyhaBRKvURJ//di43blcQmxdbdWPCmE0XOfioo=
X-Received: by 10.28.35.4 with SMTP id j4mr276325wmj.55.1511998138364; Wed, 29 Nov 2017 15:28:58 -0800 (PST)
MIME-Version: 1.0
Sender: rwfranks@gmail.com
Received: by 10.223.151.197 with HTTP; Wed, 29 Nov 2017 15:28:17 -0800 (PST)
In-Reply-To: <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> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at>
From: Dick Franks <rwfranks@acm.org>
Date: Wed, 29 Nov 2017 23:28:17 +0000
X-Google-Sender-Auth: ImvsKGGCSigpNqZtNVFLC3Yra6c
Message-ID: <CAKW6Ri7OLzjD6kd-BWwJ+OqXFXV-F2AqVPMNzxx9RyoM2nAhBA@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ea466f036c7055f277fcc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h8wMjk6UHxFLxgb2CragWltUiXI>
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:29:03 -0000

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

>
>
> 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).
>

I get the picture.  Many thanks