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

tojens.ietf@gmail.com Wed, 16 April 2025 16:01 UTC

Return-Path: <tojens.ietf@gmail.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 28C3F1D17471; Wed, 16 Apr 2025 09:01:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com
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 NaJut7E9oXEN; Wed, 16 Apr 2025 09:01:29 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E29051D17463; Wed, 16 Apr 2025 09:01:29 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-7370a2d1981so5648632b3a.2; Wed, 16 Apr 2025 09:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744819289; x=1745424089; darn=ietf.org; h=msip_labels:content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=cUzgtEasVniw93U1Lu1VfBSI6lXZ6uqTM/S/vraWgrk=; b=jwiK3ojKHkPLM3+fFqP1nXgV0nzcAxc0KAWEDO6JMC406DWCdZ0Q3ofIHEFfJ8loV1 jgu1vXRmZyzzFaHI8Zi0upwJZPoGDaw+UkyG5zxqjZTAg+sroxn4RKrbaXfzOMOwLqwM 4l/a8Eu1b7D0XIvkZOIYJwOyJQL8zxHuqpyN7ZfQw39oDXSEuTlMD0ZIexJFGDITLA8y DpcN4BMKAW73ChzBzTc3gjJnXQKJ1o+yR3a6eJKGBlnjn8bAg6aK5gvxWmD+A1tGKYAH hYVrnW840xdWAzO4c49Vw6A8S9riILpqUhY7y/SLmyi1mSwcv6qnuGdc0wvz9VqrB0JX KlPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744819289; x=1745424089; h=msip_labels:content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cUzgtEasVniw93U1Lu1VfBSI6lXZ6uqTM/S/vraWgrk=; b=sq/MD0HhtNVZWIhoYcx4BZb+2wqqc/rw9d3wR1/tUDV6nYqQMFw2y6oIQUFNGx0bbq M37rh1xTB/BMgxd64ZM4JD4bc2DOd2/90aVAwP7ti8idmOrvvz+giWEgRcL1dFzfOQwn yhU4CNVclTJfWJunT0Dt+uZmch02TK0AF7EUWBl0hSukGujlu1UIHS+E1xidS0mBP0Cq xkPkGyySUeNAgqzmLucbKnxCtesMiO03umPQwZlclDTfKzaH1Q05z0Tq9HKwG1Ju6vwm PNeOGgArXqQ2yNNQYhoRKPAp+Tfmb2qWnpAToOAqVV5PA7qcCNFxoEM2312TnkZISrI9 3Nag==
X-Forwarded-Encrypted: i=1; AJvYcCUr8XqSeTGIk2A2Drr/7pDI5hz1tWeZZi3tHcoQgNsDuBZ4y1BgG1RqGth7WUFsOIrCQWZjXBk=@ietf.org, AJvYcCWqJtu65Q8kWK5Id6iesLvEhwlVpyqeJ+761DAauOvg+aNe0ljKvW/tJlNaiDtrfeQpmyb6tsf74xpyVXE=@ietf.org
X-Gm-Message-State: AOJu0Yw3G9gSQdF6KsmJT6pIu3wTyRIT/SIJmc2XNYe7Lr7as3togPKh 0jCzT4cZ4FDv0iaUXUN5u4UEyWOYg3RqD8ntCyqPRs1TeRPU5GTXEknFlA==
X-Gm-Gg: ASbGncvmpS4DJCT1dlqr8Htq4BZK4I/YB9mzKcnq3ZATEyMqwI71WEJiF9nPEqG8s0W n7pK6A0IZPi2NqxPeSqmKAQ9VgD6QTjgyGDx42sie0HqtwOWlGwjMaEPVx9Ym0vOYSLnWvcloib +Za+JWjY8YR2OfIAElNTzT3Ge/w9JfZQu1ifuFt0k6KhBqDIso8EmxoCGM9GrU4YpHUeyctlQ83 v8Z9FwRhVH6lHdCu7WftYARGDGKab/3SD9kLCkV5Nrw3XVpLs6a/qCOOCDp4W00dMT9W0ZOIiHh kaM2ZypOnGu90gb81kz6J+szcjdIYNaKjqSTh8xXQr+JeN9eU6nCDBZ3
X-Google-Smtp-Source: AGHT+IHQwh+5N7tVVvyRB092y+C7RuzJN19GB/ItkebPaRU9EKS/iJ0s/9uWFWVqxeI9qKJ98qcLGQ==
X-Received: by 2002:a05:6a00:279f:b0:736:3ea8:4805 with SMTP id d2e1a72fcca58-73c266e8933mr3421266b3a.7.1744819288697; Wed, 16 Apr 2025 09:01:28 -0700 (PDT)
Received: from tojensdell ([76.104.236.176]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73bd22f0f8esm10975127b3a.103.2025.04.16.09.01.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Apr 2025 09:01:28 -0700 (PDT)
From: tojens.ietf@gmail.com
To: 'Joe Abley' <jabley@strandkip.nl>, 'Benno Overeinder' <benno@NLnetLabs.nl>
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>
In-Reply-To: <6EDBA5B7-54C7-4600-BC20-5E6ECE56F8E3@strandkip.nl>
Date: Wed, 16 Apr 2025 09:01:29 -0700
Message-ID: <016201dbaee8$d1106580$73313080$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHbrkRA99KeyanbaUmQai4Jl7V1KrOmJdUAgAAUMoCAAAZDgIAAMOfg
Content-Language: en-us
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a7dce31d-ab47-4b0b-bef4-563d19b43b97;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2025-04-16T15:47:31Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Tag=10, 3, 0, 1;
Message-ID-Hash: AN5SOW4ESPGEYJJPMHWEAJXGCPXE2ZWC
X-Message-ID-Hash: AN5SOW4ESPGEYJJPMHWEAJXGCPXE2ZWC
X-MailFrom: tojens.ietf@gmail.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: 'Geoff Huston' <gih902@gmail.com>, 'DNSOP Working Group' <dnsop@ietf.org>, 'DNSOP Chairs' <dnsop-chairs@ietf.org>
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/xv48IqKlenHUKl4AymHJm5tLsl4>
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>

I support adoption of this document.

> any masochists in the audience are welcome to endure the archives to find out
> more.

Oh, pick me! I was already in favor, so I wanted to see your counterargument. As it turns out, this exercise further convinced me this should be adopted, so I want to explain why in case it helps anyone else to make up their mind in either direction. 

Joe, you said:

> Personally I don't think that special actions in resolvers for INVALID and TEST are a good
> idea either; I would prefer consistent behaviour and no special cases, especially as I
> suspect that resolver operators that pay attention to this kind of thing and keep their
> software up-to-date probably already do aggressive NSEC caching and hence the risk to
> the root server system is lower than the risks related to increased complexity and
> camel exhaustion. But both risks seem small.

Camel exhaustion, sure, but I'm not convinced that the complexity added by saying queries for every name under a given TLD should always be given negative responses. That's about as simple as a TLD-specific handling can be. If we expect network operators to move to use of .internal, they ought to have some confidence that the ecosystem isn't going to be forwarding these to the global DNS. Maybe that's just my eternal hatred for split DNS speaking, hoping to confine all such uses to the one box we can then hide away forever.

I am more sensitive to risks to the root server system than any other component, so I'm not comfortable saying aggressive negative caching is good enough. Even in the happy case where every implementation that would honor .internal would also use aggressive negative caching, there is still some emission of traffic that we know, by design, in every case, is a complete waste of time. In that we would want the DNS ecosystem to become more diverse, then we scale that traffic.

So: weighing the benefit of reducing traffic to the root by even a very small percentage (and if there is adoption of .internal, how small will it be after enterprises create as many names as they want?) against managing another TLD special case, in a world where several such already exist and there are no resolvers that can exist without conditional logic... I say we go for it.

Thanks,
Tommy

> -----Original Message-----
> From: Joe Abley <jabley@strandkip.nl>
> Sent: Wednesday, April 16, 2025 5:52 AM
> To: Benno Overeinder <benno@NLnetLabs.nl>
> Cc: Geoff Huston <gih902@gmail.com>; DNSOP Working Group
> <dnsop@ietf.org>; DNSOP Chairs <dnsop-chairs@ietf.org>
> Subject: [EXTERNAL] [DNSOP] Re: Call for Adoption: draft-davies-internal-tld
> 
> Hi Benno,
> 
> So it seems to me that the question of adoption is the same as the question for
> whether this domain should be added to the Special-Use Domain Name registry.
> 
> I do not believe this domain fits the criteria for that registry, and therefore think it
> should not be added. I will spare the list my handwaving on why I think that, but
> any masochists in the audience are welcome to endure the archives to find out
> more.
> 
> For this reason I do not support adoption of this document by this working group.
> 
> 
> Joe
> 
> > On 16 Apr 2025, at 14:30, Benno Overeinder <benno@NLnetLabs.nl> wrote:
> >
> > Hi Geoff, Joe, all,
> >
> > I understand the confusion caused by the Editor note at the beginning of Section
> 5.1.  We have discussed the status of the document with the authors, and the
> intention is for it to be published as a Proposed Standard in order to add the label
> to the Special-Use Domain Name registry.
> >
> > If the draft is adopted by the DNSOP working group, Section 5, IANA
> Considerations, will be updated accordingly.  With Proposed Standard status, the
> .internal label is intended to be added to the Special-Use Domain Name registry.
> >
> > We hope this answers your questions.
> >
> >
> > On behalf of the DNSOP co-chairs,
> > -- Benno
> >
> >
> >
> > On 16/04/2025 13:17, Joe Abley wrote:
> >> Hi Geoff,
> >> I have previously disagreed with you about whether adding this name to the
> special use domain names registry is a good idea. But I very much agree with you
> about this adoption call, or at least I am confused about the same things that you
> say you are confused about.
> >> If we are not adding this domain to the registry in question, we don't need a
> document. Surely clarity on that fundamental question should come first.
> >> Joe
> >> On 15 Apr 2025, at 22:24, Geoff Huston <gih902@gmail.com> wrote:
> >>> I am left asking myself: what is the purpose of this document?
> >>>
> >>> I had assumed that the purpose was to provide RFC documentation to justify
> the inclusion of this label in the Special Use Domain Name registry, but the draft
> reads: "(Editor note: It not yet decided if the "internal" top-level domain should
> be added to the list of special-use domain names..."
> >>>
> >>> If there is no intent to add this label to the Special Use registry then what is
> the intent of this document and why is it being proposed to be an RFC?
> >>>
> >>> Why is DNSOP being asked to adopt this document if there is no clarity as to
> what is being proposed here?
> >>>
> >>> thanks,
> >>>
> >>>    Geoff
> >>>
> >>>
> >>>
> >>>> On 15 Apr 2025, at 6:38 pm, Benno Overeinder <benno@nlnetlabs.nl>
> wrote:
> >>>>
> >>>> All,
> >>>>
> >>>> At IETF 122, there appeared to be some agreement to adopt this work
> within DNSOP.
> >>>>
> >>>> Below are the relevant meeting minutes and a link to the presentation from
> the session:
> >>>>
> >>>> A Top-level Domain for Private Use, Warren Kumari
> >>>>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fdraft-davies-internal-
> tld%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7C7919834ee549
> 41b3300908dd7ce5aabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> C638804048064150080%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> %3D%7C0%7C%7C%7C&sdata=AUgwAUQkqPwHG2mnsySWv1AphcnhXn9uRDTo
> ph2RIa0%3D&reserved=0
> >>>>        Ted: Should work on this
> >>>>        Tommy Jensen: Work on here
> >>>>                Consider that libraries MAY treat it as special to catch things
> >>>>                from going upstream
> >>>>        Stuart Cheshire: Agree with logic, should be listed in registry
> >>>>        Jim: Not for IETF because ICANN told us what to do
> >>>>                Maybe figure out the process
> >>>>                Thanks for bearing with all the machinations
> >>>>        Mark: Locally served registry requires that the names have insecure
> >>>>        delegations in the DNS
> >>>>                Bring-your-own-devices work because of this insecure validation
> >>>>        Suzanne: How much work is needed?
> >>>>                Warren: Almost no work
> >>>>
> >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> >>>> atatracker.ietf.org%2Fmeeting%2F122%2Fmaterials%2Fslides-122-dnsop-
> >>>>
> &data=05%7C02%7CJensen.Thomas%40microsoft.com%7C7919834ee54941b33
> 00
> >>>>
> 908dd7ce5aabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638804
> 04
> >>>>
> 8064161046%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> OiIw
> >>>>
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> >>>>
> %7C%7C&sdata=89XMiJZdXoZ5J%2BX0vhkLASFQ%2FJL0DHLjd399eCXVoDc%3D&
> res
> >>>> erved=0
> >>>> sessa-draft-davies-internal-tld-a-top-level-domain-for-private-use-
> >>>> 00
> >>>>
> >>>>
> >>>> Warren Kumari has responded to some of the questions raised at the mic
> during the session in an email to the mailing list.
> >>>>
> >>>> This email begins a Call for Adoption for draft-davies-internal-tld, "A Top-
> level Domain for Private Use."
> >>>>
> >>>> You can find the draft here:
> >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> >>>> atatracker.ietf.org%2Fdoc%2Fdraft-
> &data=05%7C02%7CJensen.Thomas%40m
> >>>>
> icrosoft.com%7C7919834ee54941b3300908dd7ce5aabc%7C72f988bf86f141af9
> >>>>
> 1ab2d7cd011db47%7C1%7C0%7C638804048064167771%7CUnknown%7CTWFp
> bGZsb3
> >>>>
> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> >>>>
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0jakmFWXRe7MAXA4
> QxXK
> >>>> 1kHIpp1pShBc%2BbwNBs51shw%3D&reserved=0 davies-internal-tld/
> >>>>
> >>>> Please review the draft and share your thoughts on the mailing list, clearly
> stating whether you support its adoption by DNSOP.  Also let us know if you are
> willing to contribute text, provide reviews, or help in other ways.
> >>>>
> >>>> Due to the Easter holiday, we are extending the usual timeline for this call.
> >>>>
> >>>> The Call for Adoption will end on May 2, 2025.
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> For DNSOP co-chairs
> >>>> -- Benno
> >>>>
> >>>> _______________________________________________
> >>>> DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email
> >>>> to dnsop-leave@ietf.org
> >>>
> >>> _______________________________________________
> >>> DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to
> >>> dnsop-leave@ietf.org
> >> _______________________________________________
> >> DNSOP mailing list -- dnsop@ietf.org
> >> To unsubscribe send an email to dnsop-leave@ietf.org
> >
> > --
> > Benno J. Overeinder
> > NLnet Labs
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> nlnetlabs.nl%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7C79198
> 34
> >
> ee54941b3300908dd7ce5aabc%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> 7C0%7
> >
> C638804048064176692%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIl
> >
> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C
> 0
> >
> %7C%7C%7C&sdata=qD0l1rKNn5aIkhM9VjS09AFEnL31CedUi6zjmgHS4uU%3D&r
> eserve
> > d=0
> >
> 
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org