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

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

 




	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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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