IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Wed, 28 July 2021 14:13 UTC

Return-Path: <paul@nohats.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 BCEAA3A11FD for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 07:13:59 -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, 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=nohats.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 s94LpdfGwKwi for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 07:13:54 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF333A11FF for <dnsop@ietf.org>; Wed, 28 Jul 2021 07:13:54 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GZbHf6lFmzrl; Wed, 28 Jul 2021 16:13:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1627481630; bh=DO/rLwzS6yON5Z50Nu/T5osX/fIj8ig0OKEwIFe+DLY=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=nY+sl2Gk83xM/N0B17jMdKb571CPPcRvRjdQzkOeJkpsJYzSrGv7goz4TYOFZNcK7 CULn+ND3xwO1spAOr2jSZdtLCZ2XuobSDV4IB7eJzQr3+biI7bDdBe3Tshstexrab3 drpKY9V1KmYzYxPjMDPnhELBZMn4S9VG7nCCeUUg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BVJ87ApS419k; Wed, 28 Jul 2021 16:13:49 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 28 Jul 2021 16:13:49 +0200 (CEST)
Received: from smtpclient.apple (unknown [193.110.157.209]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0DDF0D23FE; Wed, 28 Jul 2021 10:13:48 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Wed, 28 Jul 2021 10:13:46 -0400
Message-Id: <AE200EA2-F856-4921-9C9B-72FF0043BE42@nohats.ca>
References: <0B065E12-6257-4001-B98A-D5B6AE4D3358@hopcount.ca>
Cc: Ralf Weber <dns@fl1ger.de>, dnsop <dnsop@ietf.org>
In-Reply-To: <0B065E12-6257-4001-B98A-D5B6AE4D3358@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPhone Mail (18F72)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V2bCxLfF1vgvjMPQaN51tB-payw>
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 14:14:00 -0000

On Jul 28, 2021, at 08:22, Joe Abley <jabley@hopcount.ca> wrote:
> 
> I tend to agree with this. 
> 
> There are a lot of ways a delegation can be non-functional (for example the circle of dependencies can be as big as you like, can incorporate third cousin twice removed glue, etc) and it makes more sense to me to let all of these cases fail rather than incurring the cost of papering over just some of them in the authority server.

Do you want dns servers to spend extra CPU power to lookup whether this is a “non-functional” glue case instead of spending less CPU just looking if it has a glue record and adding it?

If the latter, should it do this extra work of things don’t fit to determine the usefulness of TC=1 for this to set it depending those circumstances or just set TC=1 based on size ?

> From this perspective it's a greater kindness to all concerned to fail consistently when such configurations are first deployed.

Is that kindness worth spending more CPU cycles on the auth server?

Paul

v2.23.0 | Report a Bug | By Email