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

Matthew Kerwin <matthew@kerwin.net.au> Wed, 05 July 2017 04:24 UTC

Return-Path: <phluid61@gmail.com>
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 073E9129AEA; Tue, 4 Jul 2017 21:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XpYvvfGDj1I5; Tue, 4 Jul 2017 21:23:57 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 65372126D45; Tue, 4 Jul 2017 21:23:57 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id h134so79645962iof.2; Tue, 04 Jul 2017 21:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/pnFIgZB/9WJCI7pJBpDNLeN/pdDOiOZQqSyolpmpuo=; b=JcjyTKOeVVXja/VCMvK94K2naGVm+4kCsHMcaQ7biNojNpvBlWb4koT2WssmYOqJ7y R+t/spXEchXWiUNGWtIlj+CFE9F83CGxCQDbsPlqAGo5uPiGI/4J2utG9CND2U7OAXr6 rQX9sHmT/ag8A6px7ej+DkY9yH+mzj4yng3yYhepHkZbKtJYrRjbPqTIDZUei+jtukjo U3rnW9d0Qncblaj0e69QhCY2aTfIpol2a/zfIP9kxm2gvAnAC7z9jQqSrO+jrXbRUuF/ q793vQVIkgIeB21y4JQUOy7NrkDJYtwpdA8BRdGKQ7dXNCOhXOZ2nzeV8/Hz7pLUOrE1 5nbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/pnFIgZB/9WJCI7pJBpDNLeN/pdDOiOZQqSyolpmpuo=; b=k6eJIBN2bWYXjCzmgxuIIY2TM2gGfGuJL6oNDhH5czmqCodI98nl0IPoU/fAgnK9zi fAhHsVHZFM5sAqLWWo+c5su70WCIH6lWjxar0jj6y9FzZketIKDjtPyZfWmedgvSY3w9 sF1qdZ+UD4Y9b3xzuyfvLQQs8z8IclGT+DrkNaxv8DcHBAwxRrEeCQTZLOTzTYJ+/8PX g7EWylPYo5aUboiKqZUrgh/0wMvBWKpCYOzdRkMzHr1UJlICTPQU+Xlim4AZpDie3WDk 4yYsoMNybehQlh4jX0grDV7l6QvNUgAdMpmBaUjypAs8+s/WZVyE7PPst65bVJMHOZ9I RQcQ==
X-Gm-Message-State: AKS2vOw2bKqdvtpOcH19SMAMtcFUa24eWwJUqM3FwbVMEcy3PY9WhG2S 2Wa+ZrW915xzWrZYcbKXEjnh5ROS8g==
X-Received: by 10.107.58.86 with SMTP id h83mr38243411ioa.28.1499228636762; Tue, 04 Jul 2017 21:23:56 -0700 (PDT)
MIME-Version: 1.0
Sender: phluid61@gmail.com
Received: by 10.107.18.7 with HTTP; Tue, 4 Jul 2017 21:23:56 -0700 (PDT)
In-Reply-To: <20170705031957.834B97D8FBDD@rock.dv.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> <20170705031957.834B97D8FBDD@rock.dv.isc.org>
From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Wed, 05 Jul 2017 14:23:56 +1000
X-Google-Sender-Auth: QrcC7p-hQJl6t_ikxlQyxU-0Svg
Message-ID: <CACweHNCAmZPOUmat5ruh6qkYrECM2fh15n49P+zDcJ0gfoEGvg@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3KjVXrh_NvsqIhp4RUxB_If_9KY>
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 04:24:00 -0000

On 5 July 2017 at 13:19, Mark Andrews <marka@isc.org> wrote:
>
> 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.
>

In the case of http it seems to be by convention, because I can't find
anything anywhere that specifies it.  That said, my actual experience
in resolving URLs only goes as deep as gethostbyname() so it's never
mattered to me.

At a similar level, I *get* how RFC 6761 sits between the 'host' name
and the IP address, but it's far enough outside my expertise that I
don't see how all the bits fit together in any detail.

[snip]

>
> 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.
>

I'm not really a DNS person -- nor am I enough of a sysadmin (nor old
enough) to know much about HS -- which is why I asked.  I guess that
means if someone wanted to wrest control of the names used on the web
from ICANN, they'd have to set up alt-http and alt-https schemes, and
convince everyone that they're better (and to update all their
existing bookmarks, links, templates, etc.)

I guess that's one way of future-proofing us against such an event.
(That's slightly back toward the track of the original discussion,
isn't it?)

Cheers

>
>> 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 ...?
>>

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/