Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Roy Arends <[e-mail]>]

.gnu and .onion were never intended as private use. Gnu was meant as just another top level domain, and .onion is supposed to work over a (private but remote) network. 

Maybe “.local” would have been a candidate to use one of the iso3166-1 Alpha-2 user assigned string.



On 18 Jun 2020, at 17:00, Paul Wouters <[e-mail]> wrote:

> 
> On Thu, 18 Jun 2020, Roy Arends wrote:
> 
>>> To me it seems that most dnsop people (me included) do not want to legitimize use unnecessary use of private names as it often causes unnecessary pain down the road - but at the same time I personally recognize the motivation for home.arpa. etc.
>> 
>> I want to recognise two points here:
>> 
>> 1) The lack of a private DNS domain is the main motivation to squat.
> 
> I would say the main motivation is a short and memorable TLD for their
> purpose. The importance here is "their purpose". Do you think tor would
> have settled for .zz instead of .onion ? Or that GNUnet people who
> wanted .gnu will settle for .zz ? And if they did, how would you expect
> browser plugins for these two _different_ uses of .zz to work?

.gnu and .onion were never intended as private use. Gnu was meant as just another top level domain, and .onion is supposed to work over a (private but remote) network. 

> i think people who want a memorable name, will still squat one, and not
> use .zz.

Yes, and folks will cross a red light and there will be collisions, instead of using a zebra path.

>> 2) Using a private namespace is sometimes necessary, and its use needs to be legitimised 
>> Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, “gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; software is shipped with default configurations like  “openstacklocal”; renowned companies advise to configure “corp” and “internal” for private use, and ISPs are shipping home routers with “.telus” and “.home”. We have all seen those examples, have frowned upon it, and rant on various lists and fora.
> 
>> These companies all had motivations to choose these labels.
> 
> basically all the domains you list here could have used one of their own
> domains (eg local.telus.com instead of .telus, etc)

You are wilfully ignoring what I wrote. I know that seems convenient, but it is unhelpful in this discussion. Read the “bad idea” part below for your answer.

>> I know of two (imho legitimate) reasons, having learned this from a few organisations about why they prefer a squatted domain over a registered domain:
>> 
>> They could have shipped with a label under their own brand, but that would be an astonishingly bad idea, considering the volume (reason one) and type of traffic that was meant to be private (reason two), they would receive, as all these configurations will cause something to “phone home” to them.
> 
> So why not have no local domain instead? Or just pickup the DHCP domain
> name. This is just bad software design. But this group isn't going to
> fix that.
> 
> However, if these bad engineers start using .zz for this. What will
> happen is that ISPs are going to specially handle this queries, leading
> to a new set of issues for users. For example, dropping the queries
> instead of answering NXDOMAIN.

Really? No you think you know what ISPs will do?

> Lumping all these users together in .zz is just going to make each
> individual group inside .zz want to not be there. So I don't think
> your premise of letting them squat in one place will actually end up
> happening.

It is clear to me that you haven’t read the latest version of the draft. ZZ was an example that I have removed.

>> Additionally, why these organisations could to tell their users to not “squat”, find a registrar, buy a domain, renew it annually, etc, these users would move on to an organisation that says “just use .internal and you’ll be fine.”.
> 
> And those same people would not pick .zz but still pick their own more
> appropriate names.

We can’t help folks wilfully ignoring traffic signs.

Roy