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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf