Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

Mark Andrews <marka@isc.org> Tue, 26 May 2015 23:55 UTC

Return-Path: <marka@isc.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 CE95F1B332B for <dnsop@ietfa.amsl.com>; Tue, 26 May 2015 16:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.711
X-Spam-Level:
X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 aEzvt4Bsylid for <dnsop@ietfa.amsl.com>; Tue, 26 May 2015 16:55:45 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9C11A9235 for <dnsop@ietf.org>; Tue, 26 May 2015 16:55:43 -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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 110A5349514; Tue, 26 May 2015 23:55:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9A08D160050; Tue, 26 May 2015 23:56:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6777F16008A; Tue, 26 May 2015 23:56:05 +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 0mv9xAN6nKrb; Tue, 26 May 2015 23:56:05 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id BE258160050; Tue, 26 May 2015 23:56:04 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6EB212F57FC3; Wed, 27 May 2015 09:55:36 +1000 (EST)
To: Francisco Obispo <fobispo@uniregistry.com>
From: Mark Andrews <marka@isc.org>
References: <20150526200703.15413.qmail@ary.lan> <3B05F60A-8865-45B8-A36C-042E0F5CC92C@uniregistry.com>
In-reply-to: Your message of "Tue, 26 May 2015 14:19:33 -0700." <3B05F60A-8865-45B8-A36C-042E0F5CC92C@uniregistry.com>
Date: Wed, 27 May 2015 09:55:35 +1000
Message-Id: <20150526235536.6EB212F57FC3@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/s7SU1FdAoDks35BvQ3ovG0wMCX8>
Cc: dnsop@ietf.org, John Levine <johnl@taugh.com>
Subject: Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps
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: <http://www.ietf.org/mail-archive/web/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, 26 May 2015 23:55:48 -0000

In message <3B05F60A-8865-45B8-A36C-042E0F5CC92C@uniregistry.com>, Francisco O
bispo writes:
> > On May 26, 2015, at 1:07 PM, John Levine <johnl@taugh.com> wrote:
> >
> >> I believe the delegation of HOME/CORP/MAIL provides with more benefit
> >> than risks, there
> >> will be more companies/homes and mail users happy because their names
> >> resolve from
> >> everywhere, they can validate with DNSSEC, they can opt who can
> >> connect to their
> >> networks and no longer require domain hacks to get their users to go
> >> to the right
> >> places.
> >
> > There are probably tens of thousands of people who have a device with
> > the local name PRINTER.HOME.  I must be dim, because I cannnot imagine
> > any way that any possible set of DNS records in the root or a TLD
> > would allow that name to "resolve from everywhere" in a way other than
> > perhaps one that sent an enormous amount of people's printouts to one
> > printer somewhere.
> >
> > Could you clarify how it's supposed to work?
> >
>
> I would certainly like to have: obispo.home, be a real FQDN, so I can
> name my home devices, printer.obispo.home, etc.

In reality it would be printer.obispo72.home or something like that
99.999% of registrants after a year or so.  Only those that jump
at the very begining would get their family name.  .home wouldn't
be like .com where you are choosing a name for a business and part
of that process is finding something that is unique and that you
like in the DNS.  You already have a name.

And Australia actually has a model for how to link individuals /
families / homes into the dns.

name.<othername>.id.au

id is for individual.
<othername> is a meaningless label designed to deal with human name
collisions.

andrews.wattle.id.au (the master is currently broken) is just as
easy for me to remember as andrews.home and has the advantage that
lots of other andrewses can get a andrews.something.id.au name and
be on a equal footing.

wattle.id.au is also a free registry run on a volunteer basis.

Basically .home is too high in the heirarchy for this sort of
individual / family use.  There are too many collisions of names.

.home.ctld is also too high which is why a third level was added.

Mark

> If I go to a hotel around the world and I need to print in my printer at
> home, I should be able to do it, I shouldn’t be “hacking” my way around
> that. In a v6 world, this is going to be common practice, the fact that
> we have limitations on how we use our home networks today does not mean
> that those same restrictions will exist in the future.
>
> Perhaps the approach is (if identified as a problem), to have
> printer.home be on a controlled interruption list for a while, so people
> can identify and fix their setups.  I don’t know, but the approach where
> we ban the whole TLD from ever existing because of few that misconfigured
> their naming, doesn’t seem reasonable to me. (few compared to the rest of
> the world who will be connected in the future).
>
> Should we also add a .BELKIN TLD?, there are tons of devices that use it
> (to name a few), what if in 10 years someone decides to create .FOOBARBAZ
> are we going to add it to the list later?,
>
> We need a better view/picture of the whole DNS ecosystem, we should not
> be making assertions based on a 24 hour sample of 1 day of root server
> traffic, let put more effort into strategy for the long term and not be
> so tactical about these specific use cases.
>
> Regards,
>
>
> Francisco Obispo
> CTO - Registry Operations
> ____________________________
>
>  <http://www.uniregistry.com/>
> 2161 San Joaquin Hills Road
> Newport Beach, CA 92660
>
> Office +1 949 706 2300 x4202
> fobispo@uniregistry.link

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