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

Matthew Kerwin <> Wed, 05 July 2017 04:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 073E9129AEA; Tue, 4 Jul 2017 21:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.149
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XpYvvfGDj1I5; Tue, 4 Jul 2017 21:23:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65372126D45; Tue, 4 Jul 2017 21:23:57 -0700 (PDT)
Received: by with SMTP id h134so79645962iof.2; Tue, 04 Jul 2017 21:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id h83mr38243411ioa.28.1499228636762; Tue, 04 Jul 2017 21:23:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 4 Jul 2017 21:23:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Matthew Kerwin <>
Date: Wed, 5 Jul 2017 14:23:56 +1000
X-Google-Sender-Auth: QrcC7p-hQJl6t_ikxlQyxU-0Svg
Message-ID: <>
To: Mark Andrews <>
Cc: dnsop <>, IETF Rinse Repeat <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jul 2017 04:24:00 -0000

On 5 July 2017 at 13:19, Mark Andrews <> wrote:
> In message <>om>, Matthew Kerwin writes:
>> On 5 July 2017 at 10:02, Mark Andrews <> 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.


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


>> 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 using it. Unless you don't want to
>> expose your new hierarchy to the web ...?

  Matthew Kerwin