Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

Mark Andrews <marka@isc.org> Wed, 05 July 2017 03:21 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 4493412EC38; Tue, 4 Jul 2017 20:21:27 -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 JYQk5SfooSzc; Tue, 4 Jul 2017 20:21:22 -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 C9E9312EC20; Tue, 4 Jul 2017 20:21:22 -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 2E20A24AE12; Wed, 5 Jul 2017 03:19:57 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id ED1F7160045; Wed, 5 Jul 2017 03:20:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D81C5160050; Wed, 5 Jul 2017 03:20:00 +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 k9Slb0ZcaJ2G; Wed, 5 Jul 2017 03:20:00 +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 4E893160045; Wed, 5 Jul 2017 03:20:00 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 834B97D8FBDD; Wed, 5 Jul 2017 13:19:57 +1000 (AEST)
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com>
In-reply-to: Your message of "Wed, 05 Jul 2017 12:23:53 +1000." <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com>
Date: Wed, 05 Jul 2017 13:19:57 +1000
Message-Id: <20170705031957.834B97D8FBDD@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yK3R0hIibS5I4iEpCPbIHT-xB-E>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
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: Wed, 05 Jul 2017 03:21:28 -0000

In message <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com>;, Matthew Kerwin writes:
> On 5 July 2017 at 10:02, Mark Andrews <marka@isc.org>; wrote:
> >
> > Who owns a name is a different question to what machines serve the
> > <name,type,class> tuple and how do you reach those machines.  There
> > is absolutely no reason why the zones <name,IN> and <name,CLASS56>
> > need to be served by the same machines.  There is a argument for
> > them both being under control of the same people.
> >
> > Mark
> >
> 
> Hi, I'm jumping in at a random time with a possibly dumb question, but
> the talk of <name,type> and <name,type,class> tuples got me wondering
> about representation in general, and URLs in particular.
> 
> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks
> like a DNS name is a DNS name, and that they have to be resolved to IP
> addresses if you want to fetch them, but they don't talk meaningfully
> about how to do that resolution. Given that we always assume class=IN
> (not to mention type=A|AAAA via happy eyeballs), how would we go about
> practically presenting an alternative class in things like URLs?
> (Registering a new "alt-http" URL scheme doesn't strike me as a great
> idea.)

mailto: is tied to <MX,IN> then <A,IN> and <AAAA,IN> directly or indirectly.
http: is tied to <A,IN> or <AAAA,IN> and perhaps in the future <SRV,IN>

Note the linkage is not in the name but in the definition of the
scheme.

If some scheme needs <type56000,CLASS100> it will be defined in
that scheme and you will call the resolver with <name,type56000,CLASS100>
to lookup data.  That may then result in a call to lookup
<name2,AAAAA,IN> to get the addresses of the servers based on the
data returned.

Remember we call resolvers most of the time with <name,type,IN>
today.  Changing IN to something else is not hard.  You just need
to know to do that and when people write the code to support the
scheme they will do that.

When a new globally resolvable class becomes active whois will show
a set of nameservers for class IN and a set of nameservers for class
FOO.  They may be the same or they may be different.  One set may
be empty.

Remember this in not new stuff.  HS was used this way but without
central delegations.  You were still expected to use the namespace
delegated to you.  The recursive servers knew how to locate the HS
data.  getpwnam() knew how to map from user name to <domain name,
TXT, HS> and lookup the data by calling the resolver with those
values.

> Because it's all well and good setting up your own .org hierarchy
> under class=FOO or whatever, but there's not much point if you can't
> send people to www.not-icann.org using it. Unless you don't want to
> expose your new hierarchy to the web ...?
>
> Cheers
> 
> 
> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :
> 
>    """A registered name intended for lookup in the DNS uses the syntax
>    defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]."""
> 
> I read that as: "if it matches RFC1034 (and isn't overridden by the
> specific URI scheme's rules) it's a DNS name."  It could be read the
> other way, but that just adds more assumptions.
> 
> -- 
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org