On Wed, Jul 09, 2008 at 10:54:45AM +1000, Mark Andrews wrote: > > Let me be precise. The resolver treats those names differently because > > it was handed a name that did or did not end in a dot - the resolver's > > syntax for absolute vs. relative pathname. I understand that may > > conflict with application syntax. Applications that do not support an > > explicit notation for absolute domain names will not be able to look > > them up when those names are masked by site-dependent resolution of > > relative names. Both "hk" and "www.isi.deterlab.net" are relative > > names and subject to masking. > > 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. 1034/1035 compliant resolvers are allowed to do site dependent things to relative names and not to absolute ones. > 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. > > > I understand that such maskings are more intuitive with short names like > > "hk", but that limitation of the application interface applies to any > > relative domain name. > > The only reason to want single labels to be looked up "as > is" is reverse the clock and support deprecated naming > schemes. I don't "want" anything in this space. I don't care if the root's unchanged or as wide as .com. If I "want" those labels to work at all it's because their working reflects a clean DNS design. It (irrationally) warms my heart to see that they mostly do. I'm not extending my admiration of the design into an operational recommendation, no matter how much you'd like me to. The fact that the existing TLDs could do this would lead to a pretty boring flat name space - 110 names fit in /etc/hosts or equivalent just fine. A proliferation of TLDs is your problem, of course. I don't think that forcing the seekers of vanity TLDs to prepend "www." to their webserver hostname is going to change anything. After all many browsers will add that for you. 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. For most uses, www.<yournamehere> is just as flat. And just as flat as <yournamehere>.com, I might add. > There are lots of things we do and don't expect infrastructure > zone operators to do that differ from end user zones. Most > of these are not codified. If there are only a few TLDs I really fail to see how this one fits there and if there are a lot of TLDs I don't see how outlawing it helps you. But YMMV and I'm not running a TLD server, so my opinion matters little. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
Attachment:
pgpNi9YpiqGZv.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf