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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5 July 2017 at 13:19, Mark Andrews <marka@xxxxxxx> wrote:
>
> In message <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@xxxxxxxxxxxxxx>, Matthew Kerwin writes:
>> On 5 July 2017 at 10:02, Mark Andrews <marka@xxxxxxx> 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/




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]