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

Warren Kumari <warren@kumari.net> Sun, 05 February 2017 15:16 UTC

Return-Path: <warren@kumari.net>
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 05BDD129485 for <dnsop@ietfa.amsl.com>; Sun, 5 Feb 2017 07:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 3dr-j9z75Q4E for <dnsop@ietfa.amsl.com>; Sun, 5 Feb 2017 07:16:52 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 17576128BA2 for <dnsop@ietf.org>; Sun, 5 Feb 2017 07:16:52 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id w20so81278006qtb.1 for <dnsop@ietf.org>; Sun, 05 Feb 2017 07:16:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SnwFTqgN5y4ab2hAivZhRTJroB4ps9Wh3JIlQwkx6b8=; b=jUZKDBM7gAsI3lJz36SxGtYwjDM4my83AQJX2+yenQfFwNLK5y92PUVz4DLkt+WnRr 3ew8ZMHWagpLISvBGyC8N8Hn8FxsAEtghr7Cndc66qYvEazuYVpkrH+ORIH4lA1mGPcw rwvV1UWpizqohqrXq4LYwla47hkb8mbMXG8/HfpdJlZAUoK7hJ5Jishi3D2zJ11a7oeD nLBzqowF17/LEWh58xI8ttM33tp11E//D20MJ5dhUtADha0o8RTLQY20kXd8JB5NoVAN I/VWkFw23lZW8VgKjbKEV+F9aWUKeeP3V7I2VrcylR3ZvkCPjEHr41oRG2MxtwM3hj3w GfHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SnwFTqgN5y4ab2hAivZhRTJroB4ps9Wh3JIlQwkx6b8=; b=QG1F3yZv4b8UGJCj4QJ0Hu4pkfM2+vMtPhInXkL9saI8B2OPknaLnLifkX4beSc+hi XiEr7K8P3u+6c6MlySN6pvrm6pemkWDoOO60hI/aweBhredapy1sOn7K10PDObTsrH/j MYDba+O1CZJZWkjE2TfBczhO07QAa5L5Y1fNxs+9SjGB3xzbnDOSAag15FXny8RORqv4 fh11/utqbcbbgvKEUj83Cc3Eb9Mouy70eb4RIblJCg9fTEZHY9yWbRxHxc7fxAXHGxEW D6wSLUN8aoSvTbocs0AsCjMbLBBQbjZYIZvUGLbM1jWRCdEDBo1wDjwd5y+WZzngj5W4 PEAw==
X-Gm-Message-State: AMke39lkIrMzKUgDpQkk5/eFDDYp9QKhZu5nG2FmIgM7z6+8369ZdRkT3LkxE5EZLrdso+3Vdry+5b1clgE7vXzi
X-Received: by 10.200.54.247 with SMTP id b52mr6426605qtc.124.1486307811055; Sun, 05 Feb 2017 07:16:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.179.19 with HTTP; Sun, 5 Feb 2017 07:16:20 -0800 (PST)
In-Reply-To: <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com>
From: Warren Kumari <warren@kumari.net>
Date: Sun, 05 Feb 2017 10:16:20 -0500
Message-ID: <CAHw9_i+ua-PWCDLGo=_=+eAT52i-Air2o0Py1h74Ph71QnLfTQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nazib7YDwXKaiwuS-hahrfe43vI>
Cc: dnsop <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.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: Sun, 05 Feb 2017 15:16:54 -0000

On Fri, Feb 3, 2017 at 9:40 PM, Ted Lemon <mellon@fugue.com> wrote:
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>
> My memory is that only after that
> did we start thinking of a sort of 1918-style part of the DNS as
> well.  That may have been a mistake, since as this discussion is
> showing the properties of an in-protocol, in-DNS namespace without
> delegations are somewhat different to alternative-protocol uses that
> do not rely on the DNS at all.
>
>
> I think that we've seen a number of questions go by that lead to the
> conclusion that it makes sense to have two hierarchies: one for experimental
> non-DNS queries, and one for locally served zones.

Yes.

>  I don't know if we
> _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a
> special-use top-level domain name that has an un-signed delegation, it
> probably ought to be different than the SUTLDN that is used for non-DNS
> stuff, so that both names can have the appropriate configuration in the root
> zone.


.alt was intended only for names *outside* the DNS - an alternate name
resolution system (like .onion). It was never intended for use in an
alternate/internal DNS namespace. If needed, we can clarify this in
the draft.

I fully understand the desire for names which are resolved using the
DNS, but are not rooted in / connected to the DNS root -- I think that
something like this would be really useful (I've got a bunch of
use-cases), but it seems like a completely different kettle of fish.

I'd encourage someone to write a document like this -- I started
writing a such document[0] in July 2015 to reserve a name (.internal)
specifically for this, but only got as far as the title and abstract
before getting sidetracked. :-P

So, in my opinion there should not be any sort of delegation for .alt.
A new (short) draft reserving .internal (or whatever) specifically for
DNS names not rooted in / connected to the IANA tree could be written,
and that can ask for a delegation.

W


[0]
    <title abbrev="template">Reservation of .internal as a Special Use
    Name.</title
...
<abstract>
      <t>This document reserves the string "internal" for use as an internal
      DNS </t>

      <t>[ Ed note: Text inside square brackets ([]) is additional background
      information, answers to freqently asked questions, general musings, etc.
      They will be removed before publication.]</t>

      <t>[ This document is being collaborated on in Github at:
      https://github.com/__URL__. The most recent version of the document,
      open issues, etc should all be available here. The authors (gratefully)
      acept pull requests ]</t>
    </abstract>
  </front>

>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf