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

Joe Abley <jabley@hopcount.ca> Wed, 28 July 2021 18:27 UTC

Return-Path: <jabley@hopcount.ca>
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 75BAF3A1B2A for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 11:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=hopcount.ca
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 XvissiD6cNTO for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 11:27:43 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 1378D3A1B19 for <dnsop@ietf.org>; Wed, 28 Jul 2021 11:27:42 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id d9so2022927qty.12 for <dnsop@ietf.org>; Wed, 28 Jul 2021 11:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=3mLGzsxe1uQQd3DH8DpiVcAvXlgZ4jUzc847ZGhJXpk=; b=otnPo1zc4rJJq0P0yC9vQ2HRFddrN4754nsKGtd9YlDt/uhVdFjEiXGfM3aRCeRggA aPNI+8pxXsO1U7btZRxr8RwcFJf8+KRaeATrq52FigROk9uP5Kr4aqqqRFH5uIXtV3wH +gUN+nar/dZCHKlYW7ZKfktTakFzMqUmdYjMw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=3mLGzsxe1uQQd3DH8DpiVcAvXlgZ4jUzc847ZGhJXpk=; b=qwgY9A8708qItTdLQDSk2OcAqKFRNmHe1GJqtRBa/IBGvYhOljDnzst+X1VgndxW/p unPMsRncjVYa5VpyYqipL1QaeJIFG5Dv0jPE7zd/S0Zu3zcORPg4yJZBqLxqdElMTNau jPBZ64STouJFxxb1X+im+X2QlpG9E31AOgSbz38DqhyMmxZhVCiXQ3RyKe7BlaUi52qk yPbCsqTMo6xFygJRdVOl688OlS3N+zdKHnJ59qxsrgKerqV8YkURRdrDDSVcSzTWFz8P yctv6tgoVKmg5lzManhIsVR+AJIjdkYkIaiVtUE0kSRjA3RIL73o/hhA61CCdbIYAke8 YCbA==
X-Gm-Message-State: AOAM532r5BZ0+kiU6mxLR2xZzihTiJIVGjhyGK+LYMTIkkl7Lw3NQstm Xt0L0ZA2npHLHjpJzuG8eTZsXnYbosrSJqr2dhQ=
X-Google-Smtp-Source: ABdhPJyOrnbwPwxXtnulaKunda8jWTt4yVmVKe4iZqIlGmEMVwnewaDaNDdH2RtZga9vc4tFP3uz5A==
X-Received: by 2002:a05:622a:1a9f:: with SMTP id s31mr804987qtc.151.1627496860102; Wed, 28 Jul 2021 11:27:40 -0700 (PDT)
Received: from smtpclient.apple ([2607:f2c0:e784:c7:81d7:791a:2c95:26a2]) by smtp.gmail.com with ESMTPSA id t64sm397183qkd.71.2021.07.28.11.27.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 11:27:39 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Wed, 28 Jul 2021 14:27:38 -0400
Message-Id: <A33D8A12-BE91-4FD1-83E1-AFE9469B66AE@hopcount.ca>
References: <496c910-f5d6-6329-e040-886fb55a2f7b@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
In-Reply-To: <496c910-f5d6-6329-e040-886fb55a2f7b@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: iPad Mail (18G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Rzr2jMHvSM1nE0z-76wA-ihtrRM>
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: Wed, 28 Jul 2021 18:27:50 -0000

On Jul 28, 2021, at 14:00, Paul Wouters <paul@nohats.ca> wrote:

> If the zone example contains amongst other content:
> 
> foo.example. IN NS ns0.foo.example.
> foo.example. IN NS ns0.bar.example.
> ns0.foo.example. IN A 1.2.3.4
> ns0.bar.example. IN A 1.2.3.5
> 
> Then for the DNS server returning an NS query for foo.example, it is
> easy to either:
> 
> 1) return ns0.foo.example's A record
> 
> or
> 
> 2) return ns0.foo.example and ns0.bar.example. A records`
> 
> What is harder to do is determining whether it should or should not
> include ns0.bar.example's A record based on whether it is "needed" or
> not, as there are various kinds of loops possible.

So your assumption is that it's easier to return all possible glue for every nameserver in the delegation set than it is to return glue for just that subset that are subordinate to the zone cut.

Perhaps this is a good opportunity to let actual implementers let us know what is what.

>> I don't see where the "extra CPU power" you are talking about comes from.
> 
> To determine if the glue you know you have is "needed or not".

As I said, it seems to me that this is absolutely knowledge that you can gain at load time and it's not necessary to wait until response time to do the work. So I think the CPU consumption argument is not especially persuasive. However, I am not an implementer.

Regardless, it does seem to me that glue for nameservers that are subordinate to the zone cut is the MUST and other glue is at best a MAY.


Joe