Re: [DNSOP] [Ext] Possible alt-tld last call?

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 24 October 2022 17:37 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 37583C14CE2A for <dnsop@ietfa.amsl.com>; Mon, 24 Oct 2022 10:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqBC_TtYGO0Q for <dnsop@ietfa.amsl.com>; Mon, 24 Oct 2022 10:37:39 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823C6C14F735 for <dnsop@ietf.org>; Mon, 24 Oct 2022 10:37:39 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id m6so9613591pfb.0 for <dnsop@ietf.org>; Mon, 24 Oct 2022 10:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yzeYOP4lXiRN9PMavPggdYaaeMkSsaSBBl3QxEIIYos=; b=HsuiBd2FLhzbMVa7h1mJTrOAFUgz0pRsksGB6cAy2oXvqdNXTyEbBeUr5dIRpqn9im L+JFzORC9ccErMWBrbjXzyUlox0uv0KvAS0BeVwbMj1OpnzGmggpUDRikKflLSPPkJvo sh0WSV4FxfNWDz49IM1/Bmfs6NE+1IAJ7cuE30Ug5VDMOiRgnQIvlQ3VrSRoAz1nD/+/ NcJeYg0mT4Oh3k9tIyJHofecCISnVZIO2/Bu83df3NicmldRYi9Xd8gIaJtF5HMrBzRh RcGlZ2//g/2VLckV2FWD/ba+WvD9lrCisKV3YPaOPN1fzo+GysAD49CmUASOjaciQ2jy sfjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yzeYOP4lXiRN9PMavPggdYaaeMkSsaSBBl3QxEIIYos=; b=27zKuoEdrYvLRLo4GWsgBDQJl9FlOhZ6RWsAA62kenMzWJfTcrye606+Mk2b0Dugla 6jlIAB8zHnNQLFvRQALR2Sa5qljPAeFMn67C4VJ5XvuvJyZZlBK6kEzSVb/PDQh/L7aw +MqFzxTwUc+eDbbKzNjdhI3rvXTXzYHSRmkyGkAfHdnb/4EPJ1mWHntoS6NinQCH+VMP U44eDvrCiXkFhqSgs4pa20nYszNh/329+i3ERp5LM4SLZxRWNb2rWYNoN0S+E7gmYn8G G3+ZysPhPkL81qEvnv7hZIn8oiI9hLnqRc/zJAWqH9hUDs8fEhlwzfPI/Yi/w413Vt/E TOmQ==
X-Gm-Message-State: ACrzQf3E4H4VsSXIwRh3vDClF1Tzy95HfHF4XhIhzKLvRl71GI9fG+ZN +3+cO20faMwzqf0PHS6Tu26oWeBrQTqT2xlq+EQgquM8
X-Google-Smtp-Source: AMsMyM6h4+BCowPv+LVghW6Nnu8znel+vW4JKBODVef4DEC3pQmuYGXn2CwbuWBhcf6gFVCy2CWbRLUdv37v0qC318E=
X-Received: by 2002:a63:6b49:0:b0:46a:fcba:308f with SMTP id g70-20020a636b49000000b0046afcba308fmr29391836pgc.8.1666633058900; Mon, 24 Oct 2022 10:37:38 -0700 (PDT)
MIME-Version: 1.0
References: <D4D1C61C-6DAF-4D02-A861-D808270687B0@pir.org> <F514B317-18E8-4EEC-8049-A5BCAB4EB6B6@icann.org> <7A6FC59E-590C-411F-A83C-26E12172FB43@virtualized.org> <8B1A1AA1-A19E-4D26-8DB3-52B377EDA140@icann.org> <48CA0E74-2103-4691-9AC5-AB3E3360573A@virtualized.org> <9EB3910D-9ACE-476E-AEB6-798B9E5321FF@icann.org> <6471571B-0DC3-4978-8177-AEBE590C2085@virtualized.org> <BY5PR11MB4196CCA9F8FC2AE3679E6C57B52C9@BY5PR11MB4196.namprd11.prod.outlook.com> <7F3255E1-054D-4CA2-98CE-7518A0FBBE77@virtualized.org> <MN2PR11MB42079F9F77ECA7644458853EB52C9@MN2PR11MB4207.namprd11.prod.outlook.com> <CF130BA4-2FF8-4257-9B5F-3886851AC019@virtualized.org> <0809cd98-9d13-de7f-6522-bd9547c5e4b2@redbarn.org>
In-Reply-To: <0809cd98-9d13-de7f-6522-bd9547c5e4b2@redbarn.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 24 Oct 2022 10:37:27 -0700
Message-ID: <CAH1iCipNcsFnCSu338o3gfgfXyT5=r+=uvgbHKkSWL8F=ak7eg@mail.gmail.com>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
Cc: David Conrad <drc@virtualized.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000725d8c05ebcb3f08"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j3h_97LJ9O-z2PIs_FjN4Dwyg-0>
Subject: Re: [DNSOP] [Ext] Possible alt-tld last call?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 24 Oct 2022 17:37:44 -0000

On Sun, Oct 23, 2022 at 12:33 PM Paul Vixie <paul=
40redbarn.org@dmarc.ietf.org> wrote:

>
>
> David Conrad wrote on 2022-10-23 12:00:
> > Rob,
>
> not rod, but i have three comments.
>
> > On this mailing list, I think there is a pretty good understanding of
> > the intent of .alt and I don’t think there is much in the way of
> > disagreement on that intent. As far as I can tell, the points of
> > contention are:
> >
> > 1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> > 2) whether there will be a registry of .alt uses (i.e., non-DNS name
> > resolution systems) and if so, who will operate that registry.
> > 3) whether the inevitable leakage of .alt queries to the DNS represent
> > potential issues, and if so, should there be an effort to address those
> > issues.
>
> first, +1 to the above and to the elided text formerly below.
>
> second, it's worth a bit of puttering to figure out how to prevent more
> pollution (queries of non-DNS namespaces or non-global-DNS namespaces)
> from hitting the root. delegating .ALT the same way 10.in-addr.arpa is
> delegated (prisoner.iana.org and so on) may be a fine idea.
>
>
Just to expand on this idea (which I quite like), the original AS112 was
enhanced to handle new/arbitrary names, so that AS112 operators don't need
to do anything to support being a sink for new domains.

This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
target for use via DNAME.
(The DNAME bit is so there isn't a delegation for which the AS112 operator
would need to have a zone configured.)

Using this via the root zone would be a new kind of entry for the root
zone, but is otherwise non-controversial (IMHO).
It would basically look like:

alt. DNAME empty.as112.arpa

Any query for foo.alt would be rewritten by the resolver doing resolution
to foo.empty.as112.arpa, which would result in an NXDOMAIN from the
topologically closest AS112 instance.

(Separate conversation that might be time to raise: is it time to sign
empty.as112.arpa, so these NXDOMAIN results have full DNSSEC proofs, and to
enable aggressive NSEC support on resolvers?)

Brian