Re: [DNSOP] draft-lewis-domain-names-00.txt

George Michaelson <ggm@algebras.org> Mon, 21 September 2015 15:08 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C331B326A for <dnsop@ietfa.amsl.com>; Mon, 21 Sep 2015 08:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level:
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 P2LeWyWLEr1P for <dnsop@ietfa.amsl.com>; Mon, 21 Sep 2015 08:08:48 -0700 (PDT)
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) (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 0F97E1B3262 for <dnsop@ietf.org>; Mon, 21 Sep 2015 08:08:48 -0700 (PDT)
Received: by qkcf65 with SMTP id f65so45891762qkc.3 for <dnsop@ietf.org>; Mon, 21 Sep 2015 08:08:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9sqAt86HYW/mfM3StsWRqFu8qTZHz+MMB4ggPHzLCFs=; b=I2gvQA/ijukWrmWQE7Qksn0L7h+AAzae2tvuWgeWOYbf7hJLgF4v35ih1JfnjvgmiQ 9dVv++/osuX4Sg4ZOyHaMEkPynhcOaxvGSk4nLQpVRBjqQkuC7KaTkmz0hvC4Oyzx7dv 5y6IKfP2PfAW6spCdiHyfMfqbOjOpaDZPvYR9IzDue+IovZBT3te1+7Gn6vooz9FKXBY XIZrtCW277pgd2zHhfkREE6X2lUnnBEpDVS0lpwVgSsgIn9OlGyXwuDdMVUieI4GfP5p X+aBjSVy7ec7fr8woXrVbmcdFZpiXlaZlEv6qayomqdqlO20e621LRnS5JXecTK7OnvS sygg==
X-Gm-Message-State: ALoCoQmKGQVpyj0BBBa8+0+P8sNvKaAEIJP/jtvUMADokhgaAMOikxH+qEI/s8vWmyAzZLpV1qCp
MIME-Version: 1.0
X-Received: by 10.55.26.40 with SMTP id a40mr22596665qka.33.1442848127113; Mon, 21 Sep 2015 08:08:47 -0700 (PDT)
Received: by 10.55.221.79 with HTTP; Mon, 21 Sep 2015 08:08:47 -0700 (PDT)
X-Originating-IP: [2001:13c7:7001:2128:5896:ed5:8212:e96a]
In-Reply-To: <D2258D17.F334%edward.lewis@icann.org>
References: <D2209363.F235%edward.lewis@icann.org> <CAKr6gn1aM0=Mi3343aaXKc=WtqGnJqoQm64+r4LDKzT0MyAF7A@mail.gmail.com> <14957733-EB45-45ED-9B5C-55B0943CDACD@fb.com> <45A1C205-3DF1-40A3-9282-CA8344805CBE@hopcount.ca> <FAF424AD-E95C-4D0B-9C9E-CCCD95B44181@rfc1035.com> <D2258D17.F334%edward.lewis@icann.org>
Date: Mon, 21 Sep 2015 12:08:47 -0300
Message-ID: <CAKr6gn0KkBemf3N03AFuoX6tMs=+tRZvVTE9iy7Vc6vha81ztg@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: Edward Lewis <edward.lewis@icann.org>
Content-Type: multipart/alternative; boundary="001a114708e615286305204342e1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/-DXon_licSbXJqRU1sKfldO1lao>
Cc: dnsop <dnsop@ietf.org>, Joe Abley <jabley@hopcount.ca>
Subject: Re: [DNSOP] draft-lewis-domain-names-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Sep 2015 15:08:50 -0000

Your example has some problems for me.  Problems which I guess your
question was designed to draw out.

Firstly, *some* tor active clients operate by using bump-in-the-stack
methods based or analogous to SOCKS. So, there is an API which intervenes
on the normal operations and tunnels, and then its basically transparent.
Where this happens, and how this happens begs questions about the DNS
gethostby*() and getDNS*() api. -SOCKS does one set of things. the
TOR-SOCKS model (I hypothesize, but I do believe this exists) may do
something else.

Secondly, applications which don't use generic bumps in (application)
stacks, need to be re-coded to DTRT. So the .local example you gave, the
different OS's do a different job of implementing a set-aside into mDNS:
Its not uniformly available. "it depends" -And by analogy, one can expect
that .onion set-aside logic will not be uniform: if I took an apparent FQDN
xxxxx.onion on an SSH command line, and punched it into Opera, or Firefox,
or Chrome, or Safari, or curl, or ftp, I *might* get different behaviours.

I think the meta-question is a good question, but I don't think it only
faces one way (into DNS, and how we think about DNS) -It faces into the
problem space:

 "what is the set of mechanisms we have to hand, to try and do
name-to-locator mapping"

and some of them are domain names, and some aren't, and some have been
coerced into the domain name space so that other processes (X.509
certificate behaviour) can work, because of the SubjectName and
SubjectAlternateName being coerced into the dot-separated domain name form)

On Mon, Sep 21, 2015 at 11:50 AM, Edward Lewis <edward.lewis@icann.org>
wrote:

> On 9/18/15, 12:51, "DNSOP on behalf of Jim Reid" <dnsop-bounces@ietf.org
> on behalf of jim@rfc1035.com> wrote:
>
> >
> >On 18 Sep 2015, at 17:19, Joe Abley <jabley@hopcount.ca> wrote:
> >
> >> Whether or not we should call an onion or mdns name a "domain name" or
> >>something else is just a detail. I don't think agreeing on the answer is
> >>going to solve any of the problems that we actually have
> >
> >+1
>
> I'm a little surprised at this response and the plus one.
>
> Here's the problem I see.
>
> Lets say I want to write a very basic SSH client (just to make the story
> simple).  Someone can then type "eds-ssh computer-name" and open up a
> secured connection.
>
> If computer-name ends in .local, I open TCP to an IP address from the
> lookup in mDNS.
>
> If computer-name ends in .onion, I open TCP to an IP address I get via Tor
> (assuming that .onion supports remote shell).
>
> If computer-name ends in a digit, I suppose it's an address literal and
> open TCP accordingly.
>
> If computer-name ends in whatever is in the DNS root zone, I find the
> address in DNS.
>
> If computer-name ends in something not in the DNS root zone, I return an
> error.
>
> The gotchas include, what if the latter two are indistinguishable because
> the DNS resolver sent back a landing page - or the latter three if the
> redirection service didn't recognize .onion as special.
>
> What if, in a year from now, .carrot becomes yet another way to resolve
> names?
>
> What if, in the future, .alt is defined as having special meaning?  (Note
> - the fact that .alt is in an actual ID and .carrot is purely fictional
> means .carrot is closer to being an RFC. ;))
>
> It seems to me that a new layer of software is emerging between the UI and
> the stub resolver, one that will need to know where to send a name
> resolution query.  (Perhaps even amongst DNS stub resolvers on different
> interfaces.)  This emerging layer needs to know how to direct it's work
> flow.  The Special Use Domain Names Registry would be the place to start
> (but as it's written now, the emerging layer can't be future proofed).
>
> These are just TLD examples, perhaps a simplification.
>
> I see a fork in the codepath ahead regarding "whether the DNS is above
> Domain Names" (like .alt) or whether "Domain Names are broader than what
> was conveniently defined for a DNS".  It's important to know which of
> those two statements are true so we can get on with Special Use Domain
> Names, and perhaps to find ways to objectively assign new names for new
> uses.
>
> I think defining -whether- name.onion is a Domain Name will make us
> re-think how Domain Names interoperate amongst protocols beyond the DNS.
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>