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 <[email protected]> > Sent: Wednesday, April 16, 2025 5:52 AM > To: Benno Overeinder <[email protected]> > Cc: Geoff Huston <[email protected]>; DNSOP Working Group > <[email protected]>; DNSOP Chairs <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 -- [email protected] To unsubscribe send an email > >>>> to [email protected] > >>> > >>> _______________________________________________ > >>> DNSOP mailing list -- [email protected] To unsubscribe send an email to > >>> [email protected] > >> _______________________________________________ > >> DNSOP mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > -- > > 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
