Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt

Roy Arends <roy@dnss.ec> Fri, 09 October 2020 09:58 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 65DA93A0E80 for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 02:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, 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 MIeSqu_TpqHs for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 02:58:53 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 381463A0FA4 for <dnsop@ietf.org>; Fri, 9 Oct 2020 02:58:40 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id 188so9892323qkk.12 for <dnsop@ietf.org>; Fri, 09 Oct 2020 02:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cIeJ8TE3flYjciQaF+ahlZSjtlpOucMTizjC3u03OuE=; b=argsNPzWM3prsj0p96WKtFND4P8Tt+MQugZ13QyVVO9k4BUPqkre1MAx1T6bmm7i/Q XUTnQ4r73N5Ieog68+pJe552OUcgqWDmcWpKSfY5rotmUZSu4269bGAbHu4g1JYtIBfx PRLSS1tSqzDptB2u4xFeb7ksx+hdrtXEqXWBg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cIeJ8TE3flYjciQaF+ahlZSjtlpOucMTizjC3u03OuE=; b=BtHjd26fXeyHMR/LkziOD4Zd4Kauk+QwoOFFZ//fq8dzhhy0FsFqct4A/sW4XOsFS3 qTdGl52AIAW+NKC74R7odkFmHUEhAK5+7v7GlNH+6Kz3bOJDBGXp0+UP2G8IshY5rL1S JvclfYB9+cnnUveIpm7uHokspIAebylIRM50ph8OJh7F+c65UlEnPToiW6lAeF0MnQim mZuUJzIJhdvj0UIkO8x4BVXzBda8FODL8T0pboe3kpS2bcGZtK8KMpSjxNUFHVqZTOGv OEqdN3rqjHDJSSd0ZXVC7otLoJsZeq+BjqdnhkpVmUirl7QkJObuMK/Rl6mb5LRRFSlv VIXA==
X-Gm-Message-State: AOAM532G0SC7ArlA7Y5029x/m2qXP4+qLf5J9/qFzWAecN51oAF6trrW YsXnOXL0pMKffqcmQM63WNYwHhaW4ymEj363
X-Google-Smtp-Source: ABdhPJwbK2ZoiUOGh3o5Rza7vp/BvUlwQjW2ZcAqkpdGBBMkOOl4KH4DGW3wRfgf2Dv54Wy673tXmg==
X-Received: by 2002:ae9:c30d:: with SMTP id n13mr12648981qkg.138.1602237518427; Fri, 09 Oct 2020 02:58:38 -0700 (PDT)
Received: from [192.168.0.51] (cpc69046-oxfd25-2-0-cust674.4-3.cable.virginm.net. [81.109.86.163]) by smtp.gmail.com with ESMTPSA id k21sm6031951qtq.4.2020.10.09.02.58.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 02:58:38 -0700 (PDT)
From: Roy Arends <roy@dnss.ec>
Message-Id: <1D3FDBF5-75D5-4F39-803C-346FD1E5D906@dnss.ec>
Content-Type: multipart/alternative; boundary="Apple-Mail=_20D810CE-00F2-4C4F-A74E-D6095AB05D82"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Fri, 09 Oct 2020 10:58:35 +0100
In-Reply-To: <7E3AFDBD-4748-4C50-9950-5C8445C96B24@depht.com>
Cc: dnsop <dnsop@ietf.org>
To: Andrew McConachie <andrew@depht.com>
References: <160215087457.31977.4784904737314236890@ietfa.amsl.com> <7E3AFDBD-4748-4C50-9950-5C8445C96B24@depht.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/waUdFZvwmt4qwqrYA4aAUEbqWDA>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt
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: Fri, 09 Oct 2020 09:58:55 -0000

> On 9 Oct 2020, at 10:38, Andrew McConachie <andrew@depht.com> wrote:
> Hi Roy and Joe,
> 
> It’s not clear to me whether the document is advising to only use this facility when a sub-domain of a public domain name is unavailable, or to optionally use this facility based on the user’s preference. What I would like the document to say is that only when a sub-domain of a public domain is unavailable should this facility be considered. The reader should get the impression that they should try really really hard to not use the ISO-3166 reserved string if they can.
> 
> This is marked as a BCP and so I would expect to see this advice prominent in the document. Since, IMO at least, that is the best current practice. Only when a user cannot use a sub-domain of a domain they control should they even consider using the ISO-3166 reserved string. Ideally there could be a new section discussing this advice between the current sections 1 and 2. That way the reader will encounter the best practice before encountering the work around.

Thanks for your comment Andrew,

The next version will contain more text directed to this.

IMHO, the mere availability of a subdomain (of an existing domain) should not automatically preclude the use of a private top-level domain. That is, I disagree with the notion that “they should try really really hard to not use the ISO-3166 reserved string”.

Note that a domain may not always be tied to the same legal entity. When software or devices are shipped with a default configuration that is meant to work only locally (there are a few scenarios that include home use or corporate use), using a public domain is problematic. Queries will leak to the authoritative servers of that public domain, long after the public domain has changed hands.

It is also not desirable from a legal and even operational standpoint if software that is shipped with a default public domain will be “phoning home” all the time.

There are likely to be many different use cases, some where a public domain is useful, some where a private-use domain is useful. 

Warm regards,

Roy