Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

Jared Mauch <jared@puck.nether.net> Thu, 29 July 2021 10:33 UTC

Return-Path: <jared@puck.nether.net>
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 E0FE33A1D12 for <dnsop@ietfa.amsl.com>; Thu, 29 Jul 2021 03:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 00j9J88cGPL8 for <dnsop@ietfa.amsl.com>; Thu, 29 Jul 2021 03:33:49 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD223A1D0A for <dnsop@ietf.org>; Thu, 29 Jul 2021 03:33:49 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2602:fe55:64:0:dc0c:2e62:7c0b:1ae5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 0CE8C540378; Thu, 29 Jul 2021 06:33:36 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <20210728041631.CCAA8253A750@ary.qy>
Date: Thu, 29 Jul 2021 06:33:34 -0400
Cc: dnsop@ietf.org, paul@nohats.ca
Content-Transfer-Encoding: quoted-printable
Message-Id: <F802A049-F073-4FC2-A19F-2342CE44AF69@puck.nether.net>
References: <20210728041631.CCAA8253A750@ary.qy>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9qeqC7d8O5RobfZMICF1HBlTNw8>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt
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, 29 Jul 2021 10:33:55 -0000


> On Jul 28, 2021, at 12:16 AM, John Levine <johnl@taugh.com> wrote:
> 
> OK, so I ask for foo.example and I get 
> 
> ; answer
> foo.example NS ns.bar.example
> ; additional
> ns.bar.example AAAA 2001:0DB8:0000:000b::2
> 
> Does it check that's the right value for ns.bar.example?  How about with DNSSEC?  I suppose
> 
> I still don't see the benefit of trying to make some loops work when we know that we
> can't make cross-zone loops work.

I think this is honestly a bit about, should we make the computers more strict (and possibly more secure) vs more likely to workaround something that is mostly-broken.

Much of the flag day activities were about reducing cruft around workarounds for older code out there.  I don’t like breaking existing stuff but am leaning towards John in that if people are putting semi-broken glue out there, the operator should fix their NS config. 

We have been explicitly driving up DNS queries (eg: QNAME minimization for longer zones, like ip6.arpa) for the sake of privacy and reduced performance as a result.  I think breaking a few people who have poorly configured systems isn’t the end of the world, they will eventually fix their NS records.

Also, trying to define relationships without knowing where the zone cuts may exist in a domain is interesting for terminology but not something I believe goes in this work.

I think calling out that it’s possible people will create situations where a name won’t resolve, is similar to what happens with routing that isn’t deterministic as well.  We should be defining how to determinsticly resolve a name and highlight that it’s flexible enough you can configure it so it won’t work.

- Jared