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

Roy Arends <roy@dnss.ec> Thu, 18 June 2020 14:34 UTC

Return-Path: <roy@dnss.ec>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E05D3A1168 for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 07:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhARBqj9efkR for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 07:34:25 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A25F3A114E for <dnsop@ietf.org>; Thu, 18 Jun 2020 07:34:24 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id i25so7337409iog.0 for <dnsop@ietf.org>; Thu, 18 Jun 2020 07:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KjFMKX64qxuZuXW6+nb31AvgkrMWpr7E17BzxTP/sUU=; b=YTTRmtd38uBHMHuGfJYMl84N8it62ekD/iVnHGEH7vbhrvbhuyAcZaXB/AT6wTbrQk cAuIZUAhlAAJhtuNsGbXJkQuxsO3Q38hMFNtFlwif/nwSGSqqifKahGSospNCjWqnlHJ IVKJDOt7P/7hXP4j1d8Y1QE7sJnJw2o/B7+VA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KjFMKX64qxuZuXW6+nb31AvgkrMWpr7E17BzxTP/sUU=; b=uoShN/ambqbINuDD4BSj5+C21NAVkuPu/g76h/FOBM5vdZ7Xvzvv08ANszvndRaPLb HH7jWAh7IH6wuhvyXsfxy0JEl9lc5Og+RjsC0fSz6K499v1InmivoIKfyo5+Pv5aQBsU FkiEprSLOc2QabIQz/YJBvVii3sGC/F9rZ6iU4TYe9UqBiJcrmue2i7lC6dTHeWpMQ9s fWbgXgfgUPA83wTx4dEgd6num9bhcwPsGQn/7+qZ7QqN37qTKrz6dgbM11DqYuTeM2Es vSHGFmw9hO5o8n3QKUl+y1QDswjO1zXpf4rjH/yV72cYJemHMjZy9sMNYZaW39jJm/MG Tfow==
X-Gm-Message-State: AOAM533OMMQDnZYLqU4JhixQpx9JMHt8JbeboV1Ngstyk2DU4Sy6hS0Y U2TIkLoDhDnDfCcJBS1MGTlW9IJPhtglKA==
X-Google-Smtp-Source: ABdhPJx54AB16gnTVE6mSQnu3k0x9M+agkb6KERYNcdcdEHwXypBo10n6fJZw+JTaaoWzM6H8S3fMQ==
X-Received: by 2002:a5e:a70b:: with SMTP id b11mr5239442iod.63.1592490863602; Thu, 18 Jun 2020 07:34:23 -0700 (PDT)
Received: from [192.168.1.64] (host86-175-77-184.range86-175.btcentralplus.com. [86.175.77.184]) by smtp.gmail.com with ESMTPSA id c23sm1726014ioc.28.2020.06.18.07.34.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 07:34:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <af8c285c-6e08-7457-8ca8-b088e96dc251@nic.cz>
Date: Thu, 18 Jun 2020 15:34:17 +0100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C93E56C1-4CD9-4143-BA04-76CE059D2556@dnss.ec>
References: <CADyWQ+F=JA6fogcy_JGRJaZv=Hq52ozgmY5gmzfPm=1oHcJXKg@mail.gmail.com> <427141d8-c164-35a7-0e02-0961865d4468@nic.cz> <af8c285c-6e08-7457-8ca8-b088e96dc251@nic.cz>
To: Petr Špaček <petr.spacek@nic.cz>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MgMsSAPdLM6ceZLwTsUxX664cGs>
Subject: Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 14:34:27 -0000


> On 18 Jun 2020, at 08:03, Petr Špaček <petr.spacek@nic.cz> wrote:

>> 
>> I support adoption but share opinion that the document should not be published as is.

Ack. Please help the editors to mold it into the right structure when (if) the idea is adopted. And thank you for your support!

> 1. _If possible_ use a subdomain you own, it will save you headache later on (e.g. when you decide to set up VPN to your supplier, but I do not insist on this specific example).
> 2. If you think you need non-unique private subtree read list of problems listed in ... [link to some other document] and think again.
> 3. Never ever squat
> 4. If this document did not change you mind use one of /zz/

I agree with you!

> 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.

Squatting is not a good idea.

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. 

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. 

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.”. 

So for now, the query stops at the root, and with a carved out space, like the one I’m proposing, the query stops at the root, _indefinitely_.

If the intent is that the query should never reach the root, but handled internally, then I get that. Maybe RFC6303 or 6761 is an option here, but you’d still need a legitimate private space in order not to squat. 

I’d like to get this space recognised as “better than squatting”.

Warmly, and respectfully

Roy