[DNSOP] Re: Call for Adoption: draft-davies-internal-tld

Philip Homburg <pch-dnsop-6@u-1.phicoh.com> Fri, 18 April 2025 10:41 UTC

Return-Path: <pch-b6CAFA0C7@u-1.phicoh.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D9F281E09AE6 for <dnsop@mail2.ietf.org>; Fri, 18 Apr 2025 03:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV31R4oMYG8M for <dnsop@mail2.ietf.org>; Fri, 18 Apr 2025 03:41:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7037B1E09ADE for <dnsop@ietf.org>; Fri, 18 Apr 2025 03:41:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305) (Smail #158) id m1u5ixW-0000MQC; Fri, 18 Apr 2025 12:28:34 +0200
Message-Id: <m1u5ixW-0000MQC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-6@u-1.phicoh.com>
Sender: pch-b6CAFA0C7@u-1.phicoh.com
References: <m1u5h1G-0000LcC@stereo.hq.phicoh.net> <B1447F30-154A-46FB-A7A8-04E26A020E03@depht.com>
In-reply-to: Your message of "Fri, 18 Apr 2025 12:17:17 +0200 ." <B1447F30-154A-46FB-A7A8-04E26A020E03@depht.com>
Date: Fri, 18 Apr 2025 12:28:33 +0200
Message-ID-Hash: VHG7V3GUUH2OJN4H4HJPXJORFWZLBHGF
X-Message-ID-Hash: VHG7V3GUUH2OJN4H4HJPXJORFWZLBHGF
X-MailFrom: pch-b6CAFA0C7@u-1.phicoh.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: Andrew McConachie <andrew@depht.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AKGzxq30kCdSpxjR87-FQxBLubA>
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>

> The draft does not recommend using or not using .internal. It says:
> 
>     If an organization determines that it requires a private-use
>     DNS namespace, it should either use sub-domains of a global
>     DNS name that
>     is under its organizational and operational control, or use
>     the "internal" top-level domain.  This document does not offer
>     guidance on when a network operators should choose the "internal"
>     top-level domain instead of a sub-domain of a global DNS name.
>     This decision will depend on multiple factors such as network
>     design or organizational needs, and is outside the scope of
>     this publication.
> 
> SAC113 said:  Using sub-domains of registered public domain names
> is still the best practice to name internal resources.
> 
> Im not against changing the draft to align more with the advice in
> SAC113, but my inclination is to keep the draft agnostic on this
> point.  When the authors originally discussed it we decided against
> offering advice in either direction.

I assume this IETF working group can form an independent opinion. 

In my opinion the issue is not whether public domains are better or not.
My issue is that the IETF should recommend against uses that lead to DNSSEC
failures.

For example, home.arpa. is safe to use from a DNSSEC validation point of
view.

So unless DNSSEC validation is improved the draft should actively recommend
against using internal.