Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Mark Andrews <marka@isc.org> Tue, 21 March 2017 15:01 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 C83061299D8 for <dnsop@ietfa.amsl.com>; Tue, 21 Mar 2017 08:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 SwuefuDoPBnn for <dnsop@ietfa.amsl.com>; Tue, 21 Mar 2017 08:01:37 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 6AF041299E9 for <dnsop@ietf.org>; Tue, 21 Mar 2017 08:01:33 -0700 (PDT)
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.ams1.isc.org (Postfix) with ESMTPS id 78B2A24AE29; Tue, 21 Mar 2017 15:00:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2CF6816003A; Tue, 21 Mar 2017 15:00:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 191B31600BE; Tue, 21 Mar 2017 15:00:09 +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 7cLD3caOKRgL; Tue, 21 Mar 2017 15:00:09 +0000 (UTC)
Received: from rock.dv.isc.org (50-193-53-102-static.hfc.comcastbusiness.net [50.193.53.102]) by zmx1.isc.org (Postfix) with ESMTPSA id EB2DC16003A; Tue, 21 Mar 2017 15:00:08 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6D5C0671EB83; Wed, 22 Mar 2017 02:00:08 +1100 (EST)
To: Suzanne Woolf <suzworldwide@gmail.com>
Cc: Paul Wouters <paul@nohats.ca>, Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>, Russ Housley <housley@vigilsec.com>, Terry Manderson <terry.manderson@icann.org>
From: Mark Andrews <marka@isc.org>
References: <E07AFAEB-2B84-4610-87E7-94CF32CF3761@fugue.com> <7652B138-FEAB-4138-91FB-D71AFE6BEF2C@vigilsec.com> <6DCFBC9D-666A-4A3C-A418-82BB6AE3D25D@gmail.com> <alpine.LRH.2.20.999.1703210928390.28925@bofh.nohats.ca> <B1F8C6D6-7160-4BB0-B8A4-39D0027A52C1@gmail.com>
In-reply-to: Your message of "Tue, 21 Mar 2017 10:31:33 -0400." <B1F8C6D6-7160-4BB0-B8A4-39D0027A52C1@gmail.com>
Date: Wed, 22 Mar 2017 02:00:08 +1100
Message-Id: <20170321150008.6D5C0671EB83@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IZj31UUYCcfybGdXurH5zinB6Lw>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 21 Mar 2017 15:01:43 -0000

What is the point of having a MoU that names may need to be assigned
in the root namespace if there cannot be a entry added to the root
namespace if there is a technical need to it?

.onion names were never supposed to be looked up using the DNS protocol
so there is no need to the entries to exist.  Any DNS lookups should
return NXDOMAIN to the client.

.homenet on the other had uses DNS as the resolution protocol.  Existing
tools should just work.  Part of making them work is to provide a
break in the DNSSEC chain of trust.  There is only one way to do
that.

As for the name it needs to be in *stable* place in the namespace.
We have exactly two of these today.  The root and arpa.  The homenet
working group decided that the root was a more appropriae place than
arpa.

Mark

In message <B1F8C6D6-7160-4BB0-B8A4-39D0027A52C1@gmail.com>, Suzanne Woolf write
s:
> Paul,
>
> Id like to make sure I understand your comment, as Im not completely sure
> it addresses mine.
>
> As I read your response, youre willing to forgo a root zone entry, and
> the DNSSEC behavior the WG has reached consensus it wants, in order to
> have an entry in the special use name registry for homenet. Is that
> correct?
>
> If so.I see your point and I hope the IESG  is listening, as I dont think
> its the HOMENET WG consensus; as written, this draft asks for both a
> single-label name and certain behavior with respect to DNSSEC, which
> means asking for an entry in the root zone.
>
> A little more, below.
>
> > On Mar 21, 2017, at 9:54 AM, Paul Wouters <paul@nohats.ca> wrote:
> >
> > On Tue, 21 Mar 2017, Suzanne Woolf wrote:
> >
> > also speaking as individual only
> >
> >> I see no justification in draft-ietf-homenet-dot for a single-label
> name, except an implicit suggestion in
> >> Sec. 2 para. 2 that the specific string was chosen to be memorable in
> cases where homenet names are exposed to
> >> users.
> >
> > That seems good enough for me. The problem of DNS being the only
> > real name space for endusers is very well understood. And I still
> > regularly have to refind my printer based on checking my dhcp server
> > logs, something not available to regular endusers. The requirement
> > is very real.
>
> The requirement for a name that will resolve in the DNS? Sure.
>
> The requirement for a single label/TLD that will resolve in the DNS root
> zone? Dramatically less clear to me, and nothing you say above is
> specific to the root.
>
> From the perspective of the DNS protocol, which string is used to fill a
> domain name slot is mostly immaterial as long as strings are generated
> and parsed according to the recognized rules; theyre interchangeable what
> matters is that theyre unique within the relevant namespace. The root of
> a hierarchical namespace is mathematically special in a few ways, but I
> havent seen a case that the name used by HNCP requires any of them. At
> the same time, the root of the DNS namespace is quite clearly special in
> the administrative sense; Im trying to separate the two sets of
> considerations.
>
> >> I *strongly* suggest that if this document is to be used as
> justification to create an entirely new process
> >> for updating the root zone, coordinated between the IETF and the
> external body that controls the root zone,
> >> the justification should be *much* more explicit.
> >
> > This .home / .homenet issue has already been going on for a very long
> > time. The longer we wait with resolving this issue, the worse the
> > deployment situation will be of software mixing .home vs .homenet.
>
> For the purpose of the question Im asking, Im indifferent between the
> strings .home" and .homenet. The policy problems with .home" are
> significantly larger than with .homenet, but asking for a root zone entry
> at all is a significant problem for the current draft, no matter what
> string is involved.
>
> > Suggesting we postpone .homenet while figuring out a new IETF/ICANN
> > process, something that can take years, would basically doom this rename
> > and install .home as the defacto standard. Once this new process
> > would be completed, it would lead to new breakage, and the new
> > software would be forced to look into both domains, or if the
> > install base is big enough for .home, would be better of ignoring
> > a new .homenet altogether.
>
> Again, Id like to make sure the problem I was trying to address is clear.
>
> Asking for a delegation in the root zone, particularly an unsigned one,
> as this document currently does, *will* essentially require "figuring out
> a new IETF/ICANN process, something that can take years. This is true no
> matter what string is being requested.
>
> Its simple fact that a name elsewhere in the tree does not have the same
> obstacle.
>
>
> Suzanne
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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