Re: [DNSOP] [Ext] Do we need new draft that recommends number limits ?

Edward Lewis <edward.lewis@icann.org> Thu, 14 March 2024 17:02 UTC

Return-Path: <edward.lewis@icann.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 4A8C6C14F5FD for <dnsop@ietfa.amsl.com>; Thu, 14 Mar 2024 10:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 TYJNtQQnRYVI for <dnsop@ietfa.amsl.com>; Thu, 14 Mar 2024 10:02:14 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 45BE0C14F5E3 for <dnsop@ietf.org>; Thu, 14 Mar 2024 10:02:14 -0700 (PDT)
Received: from MBX112-E2-VA-1.pexch112.icann.org (out.mail.icann.org [64.78.48.205]) by ppa4.dc.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 42EH22ZM015144 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Mar 2024 10:02:02 -0700
Received: from MBX112-E2-VA-1.pexch112.icann.org (10.217.41.128) by MBX112-E2-VA-2.pexch112.icann.org (10.217.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Thu, 14 Mar 2024 13:02:12 -0400
Received: from MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) by MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) with mapi id 15.02.1258.028; Thu, 14 Mar 2024 13:02:12 -0400
From: Edward Lewis <edward.lewis@icann.org>
To: Kazunori Fujiwara <fujiwara@jprs.co.jp>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] Do we need new draft that recommends number limits ?
Thread-Index: AQHadFX/YZprpwQJR0uix4llaRwr5LE3egmA
Date: Thu, 14 Mar 2024 17:02:12 +0000
Message-ID: <F5A32FB8-0451-4F85-92DA-939A802C03DE@icann.org>
References: <20240312.171904.558689864486146903.fujiwara@jprs.co.jp>
In-Reply-To: <20240312.171904.558689864486146903.fujiwara@jprs.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.65.22091101
x-originating-ip: [192.0.47.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C1782C9977C88145B3461843E8090410@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-14_13,2024-03-13_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rM-U6iEIWl-zBnLQZs775q8Q_UQ>
Subject: Re: [DNSOP] [Ext] Do we need new draft that recommends number limits ?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 14 Mar 2024 17:02:18 -0000

The DNS needs operational profile documents.  Documents that set societal norms for the global public Internet while still allowing the protocol to be overly flexible ("my network, my rules" world).

On 3/12/24, 04:19, "DNSOP on behalf of Kazunori Fujiwara" <dnsop-bounces@ietf.org on behalf of fujiwara@jprs.co.jp> wrote:

    With DNS, there are several things to consider, such as the number and
    number of times that can complicate name resolution or cause DoS.

    For example, number of CNAME chains or number of chains of "unrelated"
    name server names are not limited. (Each implementations limit.)

    "KeyTrap" also seems to be caused by the configuration of a large
    number of DNSKEY RRs and RRSIG RRs in one domain name.

    For example,

    - Number of CNAME chains
    - Number of "unrelated" name server name resolutions (hard to write)
    - Number of NS RRs in each delegation
    - Number of RRs in one RRSet.
    - Number of RRSIG RRs in one RRSet
    - Number of DNSKEY RRs in one domain name

    DNSOP WG limitted NSEC3 Parameters in RFC 9276,
    beyond which DNSSEC validation was not required.

    Then, we can generate new recommendations that limit numbers and
    if it exceeds that limits,
    it might be a name resolution error or no validation.

    Rather than writing a draft for each limitation,
    I think it would be better to compile them all into one draft.

    --
    Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>

    _______________________________________________
    DNSOP mailing list
    DNSOP@ietf.org
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!668p516xLDGGnGTMw7gMQ6_DZg8_EMynquifrz9egdugWq24bSnRbqPLCUr4sRoXfhXzeCSYRZy1AC3MEjdEDenkcH0$ [ietf[.]org]