Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

Paul Vixie <paul@redbarn.org> Thu, 16 December 2021 18:55 UTC

Return-Path: <paul@redbarn.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 DDD3D3A0E42 for <dnsop@ietfa.amsl.com>; Thu, 16 Dec 2021 10:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
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 DPMVmTpdORGh for <dnsop@ietfa.amsl.com>; Thu, 16 Dec 2021 10:55:31 -0800 (PST)
Received: from util.redbarn.org (util.redbarn.org [24.104.150.212]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C553A0E36 for <dnsop@ietf.org>; Thu, 16 Dec 2021 10:55:29 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 67E6818EA05; Thu, 16 Dec 2021 18:55:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1639680928; bh=g7j+PeQ7cYxJA37gJa1T0mpcm4/q4Ij/jZOmKnNoK8k=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=VdQDd8RRZz+dGGE/8sqI2OiIki+8KzT6CK1beVTxKb2eH+58dVQcxe8zPP8WweQBR Zu608ZElz4JmUKHBXSnvOsRbkxD9QTtJkAWpHUMe+i0yfLjZAOgPGwXOh5Y/yGx2/t 4KOzHiKy+SoyArtrneYi1YDxCRWkydixfLYtDLRA=
Received: from [IPv6:2001:559:8000:c9:f065:c89a:99f4:2ace] (unknown [IPv6:2001:559:8000:c9:f065:c89a:99f4:2ace]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 41D357597E; Thu, 16 Dec 2021 18:55:28 +0000 (UTC)
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
References: <B08E9361-B97B-4862-861C-4EF628C85E50@icann.org> <bb61304c-6ef9-7850-3dbb-19b624bc07b@nohats.ca> <60a11d97-8be4-91e-4880-999c1a57a75b@dotat.at> <FC138247-7BA2-4CCA-8E6C-A06423236A81@icann.org> <2009A9A9-4CF3-4AB6-8D6B-3474B15F0328@verisign.com> <CAHbrMsDpW=Z7R69Zn9Oqxfjo7SnhfuNpj_uL+VN6FS_5oXuA5g@mail.gmail.com> <315888CA-4429-4038-AB6F-0D38B95A2FA2@verisign.com> <CAHbrMsBj1F9rtFywZh-68JjCTUVOzAej_GLc15KGNOALQf28yg@mail.gmail.com>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <7bd5b32b-7070-cae8-8629-ee6c47674f38@redbarn.org>
Date: Thu, 16 Dec 2021 10:55:26 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.53
MIME-Version: 1.0
In-Reply-To: <CAHbrMsBj1F9rtFywZh-68JjCTUVOzAej_GLc15KGNOALQf28yg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TFyoLtX2h_VAV8W1UjWP-JWrBYM>
Subject: Re: [DNSOP] Another attempt at consensus on the bailiwick discussion
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 16 Dec 2021 18:55:37 -0000


Ben Schwartz wrote on 2021-12-16 10:45:
> On Wed, Dec 15, 2021 at 3:56 PM Wessels, Duane 
> <dwessels=40verisign.com@dmarc.ietf.org 
> <mailto:40verisign.com@dmarc.ietf.org>> wrote:
> 
>     For me “necessary” is an important distinction and “might be useful”
>     is too broad or ambiguous.  I have a hard time reconciling the idea
>     that glue is not optional with the idea that it might be useful.
> 
> 
> My view is less like "might be useful for reaching the nameserver", and 
> more like "intended for use in connecting to the nameserver".  A record 
> is "glue" if it is provided for the purpose of helping the 
> resolver connect to the nameserver indicated in the NS record.

the AAAA or A RRsets which are beneath delegation points will never be 
answered authoritatively by the zone's servers. they will either come as 
referral glue when asking for other names at/below that delegation 
point, or they will come as referral glue when asking for them by name.

so they do seem "necessary" since there is no other way to get them from 
the zone's servers except by asking a question which inspires the server 
to add them to the additional data section of a referral response.

of course, they may be held as glue higher up the hierarchy. for example 
we might get ns-ext.vix.com's AAAA/A RR from the root or COM servers 
when forwarding a question for www.vix.com to one of those servers. but 
if it doesn't come from there, it had better come from vix.com's 
servers, but since it's below a delegation point, it can only be sent by 
the vix.com zone servers as additional data in a referral response.

perhaps the nomenclature should be "referral glue" to drive home the 
point about where it will appear, and disambiguate from whatever DPRIVE 
is thinking about, and avoid the use of the words "necessary" or "useful".

> "Necessary" doesn't work, in my view.  Whenever there are multiple A or 
> AAAA glue RRs, each RR is not individually "necessary".   Any glue AAAA 
> RRSet is basically never "necessary".

i think that's a corner case, unworthy of the complexity of describing 
it. if there is only one name server for a zone, and it has only one 
kind of IP connectivity, then that one AAAA (or A) RRset will be 
"neccessary". this highlights the benefit of not using words like 
"necessary" or "glue" since they drag in unnecessary outer concepts.

vixie