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

Andrew McConachie <> Fri, 09 October 2020 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D76B63A0E17 for <>; Fri, 9 Oct 2020 02:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HjeqCQUYsxjo for <>; Fri, 9 Oct 2020 02:38:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E6073A0E18 for <>; Fri, 9 Oct 2020 02:38:08 -0700 (PDT)
Received: by with SMTP id o18so8699387edq.4 for <>; Fri, 09 Oct 2020 02:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=yz3Czp5w91Iyat5VGpX/4nHwlAPqSx5MLLi34ZrnZHQ=; b=TqGz3L7/iIv+5JkX8mmW/2frJUtmP4uSjb/C25i54l6uq/NYXSvYxHFRbjYs1+3OhU O3eaHzNj0tJbF4JBT2OL65vNm4L9ku38XsnF8m71al1nTAtMNeabW5vF0UnZFCkbVBum zjkUSwxu/93hryt11bnfLhYD4MKEJ/yEgUymd+tCRgUQmktECVYeLK9XyoqtOKkcx5a2 Vl/H+jtnTrk+gik36nrulYNteKbuxzKHLjxsq1BwLL24Ky00bdRWfsBCb2hCj7vLMAKs F3WfBUmg1UFa+NcTwWv9YJLLj/3jpwd4NJN/2WbWgwNtGZgGfN2q9v5LnI27GLfX3THM hOdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=yz3Czp5w91Iyat5VGpX/4nHwlAPqSx5MLLi34ZrnZHQ=; b=FVbE26QS6CbBeIurU2tO0vht5ZTk6emDfypPoH2cw/xlOGlitLTTtKlgmrjBy6dEhR 9fuAWVWFbalLa9tC6OVgAZGCPOHZknq/ubURK9C2mtHDmzxpGPwHQF73JP9eCevMJs9k QjBh22D3r27OgG8RoYB9dcjnw2rQaQrkdRIGfA23Lup3tzpJtD0fXPudeTno8jP2VpIr j/5ZwYPpZSSpyCs1TMxpWyJnB9Jhpu12DlHeWz8QClsAvIidrAeQDynFKQd8x9qkKdNw AvRsNBvjFOYfXzrP5vMpcLb5MfCioSVHmQFPZj5SQf6aAFoUlU5Pr9pVsWjiung7xm3b PAag==
X-Gm-Message-State: AOAM530mN5Szavn6Ak82ez6LVuwls5IExsqJsDvJckTkMjzmvMQy+t8O 5qFjXMVrO0U7S4MqUhoIcKv8H0W1aH02yw==
X-Google-Smtp-Source: ABdhPJx+VQH2NC0T6a5SGtZQ8ZkBLkxCQp91r3VjNQerrAvSCW0u2q+ZJAWyGMsei/unc8ZKnvmu/A==
X-Received: by 2002:a05:6402:1012:: with SMTP id c18mr13327215edu.77.1602236286205; Fri, 09 Oct 2020 02:38:06 -0700 (PDT)
Received: from [] ([2a02:a212:9285:29f0:d487:2d84:6e4b:9ed5]) by with ESMTPSA id r24sm5785347edm.95.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 02:38:05 -0700 (PDT)
From: Andrew McConachie <>
Date: Fri, 09 Oct 2020 11:38:04 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Oct 2020 09:38:10 -0000

On 8 Oct 2020, at 11:54, wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of 
> the IETF.
>         Title           : Top-level Domains for Private Internets
>         Authors         : Roy Arends
>                           Joe Abley
> 	Filename        : draft-ietf-dnsop-private-use-tld-00.txt
> 	Pages           : 10
> 	Date            : 2020-10-08
> Abstract:
>    There are no defined private-use namespaces in the Domain Name 
> System
>    (DNS).  For a domain name to be considered private-use, it needs to
>    be future-proof in that its top-level domain will never be 
> delegated
>    from the root zone.  The lack of a private-use namespace has led to
>    locally configured namespaces with a top-level domain that is not
>    future proof.
>    The DNS needs an equivalent of the facilities provided by BCP 5 
> (RFC
>    1918) for private internets, i.e. a range of short, semantic-free
>    top-level domains that can be used in private internets without the
>    risk of being globally delegated from the root zone.
>    The ISO 3166 standard is used for the definition of eligible
>    designations for country-code top-level Domains.  This standard is
>    maintained by the ISO 3166 Maintenance Agency.  The ISO 3166 
> standard
>    includes a set of user-assigned code elements that can be used by
>    those who need to add further names to their local applications.
>    Because of the rules set out by ISO in their standard, it is
>    extremely unlikely that these user-assigned code elements would 
> ever
>    conflict with delegations in the root zone under current practices.
>    This document explicitly reserves these code elements to be safely
>    used as top-level domains for private DNS resolution.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
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.