Re: Update of RFC 2606 based on the recent ICANN changes ?

[Keith Moore <[e-mail]>]

>> 	The (some) resolver handles names differently if it contains a dot.
> 
> The distinction that I have been unclearly stating is between absolute
> and relative names.  RFC 1034 (i said 1035 earlier, but it's 1034) lays
> out a convention for specifying which one you want by appending the dot.
> As long as you tell the resolver which one you want, it matters little
> if the dot character is at the end or not.

in my experience, far too often applications don't tell the resolver 
which one they want.  also, APIs can vary enough from one implementation 
to another that a "portable" application may behave differently 
depending on which API implementation it is using.

> 1034/1035 compliant resolvers are allowed to do site dependent things to
> relative names and not to absolute ones.

for better or worse, application protocols and applications haven't 
strictly followed 1034/1035 in this regard.

>> 	There is a good case to be made that "pet" should *never*
>> 	be looked up as plain "pet" if there is not a match on the
>> 	search list.
>>
>> 	There is a good case to be made that "pet.com" should never
>> 	be looked up against the search list.
> 
> I prefer the 1034/1035 view that this sort of decision is up to the
> application and the DNS admin and that the DNS simply provides the
> ability to do both.

in general I agree, but I think we've learned a few things since then 
about the corner cases.

(I would _almost_ agree that "pet" should never be looked up as plain 
"pet" - except that I think it should be possible to directly query a 
server to find out what RRs that server has (right or wrong) and I 
wouldn't want the server to lie or the API to prevent such queries. 
That's why I would rather forbid servers to forward single-label queries 
- and perhaps, to refuse to cache NS records for them.)

> If I "want" those labels to work at all it's because their working
> reflects a clean DNS design.  

Cleanliness is secondary to function.  The purist in me likes regularity 
too.  But even if the _protocol_ is the same at the root as for any 
other zone, the root of the _name space_ really is special, and 
inherently so (given that these labels have semantics associated with 
them).  At a certain very technical level there is no difference between 
the root and any other zone.  But at a different level the root has a 
special role and is different than the other zones.  It is a single 
point of failure - not in the sense of a single server or a single 
network link but in the sense of a single organization running it whose 
mistakes affect the entire network.  Also, the relationship between the 
root and its subdomains is likely to be very different than that between 
any other domain and its subdomains.

> If you're worried about a flat namespace, attack the right problem - a
> proliferation of TLDs, not this business of the TLD having an A record
> at the top. 

Vanity TLDs are indeed part of the problem.  Without vanity TLDs there 
would be much less incentive to have single-label domain names.

(I guess I need a better name than "vanity" TLDs for these - but I think 
you get what I mean.)

Keith
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf