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

[Ted Faber <[e-mail]>]

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

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