ietf
[Top] [All Lists]

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

2017-07-04 23:24:20
On 5 July 2017 at 13:19, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:

In message 
<CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA(_at_)mail(_dot_)gmail(_dot_)com>,
 Matthew Kerwin writes:
On 5 July 2017 at 10:02, Mark Andrews <marka(_at_)isc(_dot_)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/

<Prev in Thread] Current Thread [Next in Thread>