Re: [DNSOP] ALT-TLD and (insecure) delgations.

Mark Andrews <marka@isc.org> Thu, 02 February 2017 00:02 UTC

Return-Path: <marka@isc.org>
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 6C04F1295F8 for <dnsop@ietfa.amsl.com>; Wed, 1 Feb 2017 16:02:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level:
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0HEX7tL5QHUo for <dnsop@ietfa.amsl.com>; Wed, 1 Feb 2017 16:02:42 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36D8129577 for <dnsop@ietf.org>; Wed, 1 Feb 2017 16:02:42 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9F21E349314; Thu, 2 Feb 2017 00:02:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 772E9160071; Thu, 2 Feb 2017 00:02:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B3D1160070; Thu, 2 Feb 2017 00:02:40 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VYgkkXIzxl_e; Thu, 2 Feb 2017 00:02:40 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id BCAB2160042; Thu, 2 Feb 2017 00:02:39 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A29556117F7F; Thu, 2 Feb 2017 11:02:35 +1100 (EST)
To: Ted Lemon <mellon@fugue.com>
From: Mark Andrews <marka@isc.org>
References: <CAHw9_i+8PA3FQx8FqW-xQ_96it7k-g5UrMB7fxARUi1gwQ++hw@mail.gmail.com> <CA+nkc8AhLe7nbPRkGixi93SGNZQhw+TACUDa8=pGsWM5YHJE0w@mail.gmail.com> <C75FC005-ED38-436B-A93E-C2D2B7CDDE9C@gmail.com> <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>
In-reply-to: Your message of "Wed, 01 Feb 2017 15:58:41 -0500." <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>
Date: Thu, 02 Feb 2017 11:02:35 +1100
Message-Id: <20170202000235.A29556117F7F@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1Ow69Br-HTbhmYeRtQc-O-mivug>
Cc: dnsop <dnsop@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 02 Feb 2017 00:02:43 -0000

In message <1B8E640B-C38E-4B76-A73D-7178491A9D7B@fugue.com>, Ted Lemon writes:
>
> On Feb 1, 2017, at 3:50 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
> >> It appears to me that requesting an insecure delegation is the right
> >> thing to do, as a "technical use".  We have, so far, been very careful in
> >> what we ask for.  If ICANN does not agree, then we can discuss other
> >> options.
> >
> > I agree.
>
> I'm confused.   The .ALT TLD is expected to be used for non-DNS name
> lookups.

The .ALT TLD is a sandbox to play in.  It is a place where people
can graft on alternative namespaces to play with.  The names in it
are not expected to be reachable in the DNS following normal DNS
delegations from the root zone.  This does NOT mean they are non-DNS
names.

I would expect all the names used in it to be syntactially valid
DNS names (able to be converted to DNS wire format) but there is
nothing we can do to enforce that.  If they aren't convertable
tools will fail to parse the names if they leak.

They may be looked up using the DNS (e.g. like homenet).
They may be looked up using other protocols (e.g. something like TOR).

Its a place where people know that there is a risk of namespace
collisions as there is no registry to prevent that.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org