Re: HTML5 and Public Suffix

On Thu, Jan 29, 2009 at 08:16:30PM +0000, Ian Hickson wrote:
> Our requirements are:
> 
>  * given a domain/hostname, it should be possible to determine if this is 
>    a domain whose next level can have hosts from different authorities.
>    Specifically, the desire here is to be able to distinguish 
>    foo.example.com/bar.example.com (which is fine) from 
>    example.com/sample.com (which is not).

But this is exactly the mistake.  The DNS is divided into zones for
administrative purposes _of the DNS_ (I'll call that
dns-administrative division).  There is nothing whatever about it that
determines whether a given zone is under the same
authority-administrative control.  You cannot get that information out
of a DNS name, period.  It's not there, and it never was there.

To illustrate this, let's consider some use cases. In your example
foo.example.com and bar.example.com, let's substitute "blogspot" for
"example".  Is it ok now that these hosts are not considered to be
"from different authorities"?

If you think that one's ok, well, then, what about if we substitute
"dyndns.org" for "example.com"?

Ah, but now you will say, "Exactly.  This is what the list is supposed
to accomplish!"  But it doesn't, I submit, because you simply can't
know this from the labels.  Some of the zones inside dyndns.com
probably _are_ from the same authority, and ought perfectly well to be
able to be treated the same.  But this mechanism can't do it.

Moreover, what about the impending release of all the new TLDs?
Imagine IBM buys one.  Do we somehow get ibm.com == .ibm as well?  If
so, who maintains the list of equivalencies?  Not IANA or ICANN last I
checked (has that changed?)  If not, why not?  The reason could only
be because of the broken assumptions you're trying to paper over: that
there is some authority-administrative relationship to be divined from
labels in the DNS.

>From the point of view of the consumer of the DNS, the protocol was
designed as a single tree without the kind of barrier markings that
you want.  All of the mechanisms I've seen so far to pull those
barriers out of the existing DNS are badly broken, because they either
make a number of assumptions about the way the DNS tree is broken up,
or they have what I regard as seriously objectionable social baggage
(e.g. control over the definition divorced from the registration and
operation authorities for the label in question), or both.

>  * it shouldn't be spoofable (i.e. it should not be possible for a public 
>    component to be labelled as a private component). It's ok if private 
>    components get marked as public ones, though.

I'm not sure I see how the current arrangement meets this criterion
either, but I don't think we're going to get very far debating that
one, so I'll leave it alone.

A 

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

Received on Thursday, 29 January 2009 21:04:58 UTC