IETF Logo Mail Archive

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

Jim Reid <jim@rfc1035.com> Wed, 10 July 2024 13:42 UTC

Return-Path: <jim@rfc1035.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 EB84DC14F695 for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2024 06:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2Uf7c--HIbp for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2024 06:42:31 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DFFC14F5FA for <dnsop@ietf.org>; Wed, 10 Jul 2024 06:42:31 -0700 (PDT)
Received: from smtpclient.apple (xvc355001.itu.ch [156.106.214.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 0DC772420E4A; Wed, 10 Jul 2024 13:42:29 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <m1sRXLs-0000LpC@stereo.hq.phicoh.net>
Date: Wed, 10 Jul 2024 14:42:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <53EBF719-FCB0-46D9-9FA6-292BB085A48C@rfc1035.com>
References: <20240709.190627.2171739541556622717.fujiwara@jprs.co.jp> <b46fb097-d8d9-4765-b797-18c8e8e74389@bellis.me.uk> <m1sRXLs-0000LpC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-dnsop-5@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: LKRYIAK3N2M4F2Q35LWJFE2XQHYXT5XB
X-Message-ID-Hash: LKRYIAK3N2M4F2Q35LWJFE2XQHYXT5XB
X-MailFrom: jim@rfc1035.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j3yyrTbQfmUH20rzTknCnj-XFes>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>


> On 10 Jul 2024, at 14:27, Philip Homburg <pch-dnsop-5@u-1.phicoh.com> wrote:
> 
> So the question becomes, do we want some limits in an RFC that everybody
> agrees on or do we want to keep the current informal system where limits
> are not fixed and people can get unlucky if they exceed limits they didn't
> know exist.

I’d prefer somewhere in between. Nailing down fixed limits could be tricky because there are too many moving parts: transport, DNSSEC flavours, Do[TQH], what (not) to drop from the Additional Section, etc). And those limits may change as the DNS and/or the Internet evolves. The current informal arrangements may well be too loose. The info isn’t in one place, making it hard for DNS operators.

IMO documenting the trade-offs in response sizes could be a better option. ie if the response > X, it breaks foo; if it’s > Y it breaks bar.

v2.26.15 | Report a Bug | By Email | System Status