IETF Logo Mail Archive

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

David Conrad <drc@virtualized.org> Wed, 16 April 2025 18:50 UTC

Return-Path: <drc@virtualized.org>
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 3E0401D3903B for <dnsop@mail2.ietf.org>; Wed, 16 Apr 2025 11:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized.org
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 VUNeAMjlb8Up for <dnsop@mail2.ietf.org>; Wed, 16 Apr 2025 11:50:27 -0700 (PDT)
Received: from mail-24422.protonmail.ch (mail-24422.protonmail.ch [109.224.244.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6040D1D39032 for <dnsop@ietf.org>; Wed, 16 Apr 2025 11:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized.org; s=protonmail3; t=1744829425; x=1745088625; bh=H+TkoKqaeTXvlw4NOjBd+9nrnWxttOhL+Q6ZlcB7fbg=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=BcOhKoCX/l/PKQRWpjSQCRlK69dL0dxC0RTYFC0m+DOO5KlfLlyxu2zgf6YoXyU9P nvPqSyvQYoS/ry1MmetFpPXq3R3jYQ8ZcjYONrw22n5zcuabdIKrMyh7zDPSKWeD6s kN3Jv49VlRuhvyPCU+Zypr4ZxLbpnSO6Lq8ei3ZfL0NPgVTvd1ElaCfUofAwRrHj6p /kZPwNzh4pAh6FRfEZTOquZBIJZ2GA1f+7JRf3lwJXglV5VAjOH/GjP6MJeX4R5SP+ 67NT3L6gc52WvYNeTsVHwhLp8xapnaCuZ2cxos2To3CFwiE0dUSoo4c9A5ZdDpjNGB NKD0eN7X0os5A==
Date: Wed, 16 Apr 2025 18:50:22 +0000
To: DNSOP Working Group <dnsop@ietf.org>
From: David Conrad <drc@virtualized.org>
Message-ID: <3818CCCC-4D15-4603-8CEA-F2CB34702C6D@virtualized.org>
In-Reply-To: <016201dbaee8$d1106580$73313080$@gmail.com>
References: <85BB19F8-03C2-4F36-A878-0AE46CD912C6@gmail.com> <FCB15449-C511-4959-8709-B6BB66B03E11@strandkip.nl> <e9193eec-06a4-491b-b35c-2cd53e44b8ba@NLnetLabs.nl> <6EDBA5B7-54C7-4600-BC20-5E6ECE56F8E3@strandkip.nl> <016201dbaee8$d1106580$73313080$@gmail.com>
Feedback-ID: 101327196:user:proton
X-Pm-Message-ID: e20737bb1b99eb24ec132fdedef52f044c6e1c5b
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------f5ffa7e7926b4b8abf52841791864123169d971d0708ff4bbe0d9d0ac64d512b"; charset="utf-8"
Message-ID-Hash: NLSQWYKF42ASAID76PFWZF4EQAIFRXML
X-Message-ID-Hash: NLSQWYKF42ASAID76PFWZF4EQAIFRXML
X-MailFrom: drc@virtualized.org
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [EXTERNAL] 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/26QVhcH8ufItLu0Ijy2JpBCA18U>
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>

Hi,

I support adoption and the eventual publication of a document in order to add .internal to the SUDN registry.

FWIW, my reasoning:

I doubt it’ll have much impact on either implementations or the query load for the root name servers, but I figure it might help (slightly) with consistency of specification. If you’re writing code for DNS, having one place to look for special cased names seems better to me than having to look in multiple places managed by multiple organizations. Figuring out how to implement the DNS properly is already hard enough, why make it more annoying?

Regards,
-drc

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