On 5 July 2017 at 13:19, Mark Andrews <ma...@isc.org> wrote: > > In message > <CACweHNCAi7JcOW9CX=6fviv1wuoe5fhn7dej2eiep2-d_fh...@mail.gmail.com>, Matthew > Kerwin writes: >> On 5 July 2017 at 10:02, Mark Andrews <ma...@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/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
