--5me2qT3T17SWzdxI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
=20
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.
"hk" is not a legal absolute hostname. The current resolver
code handles all legal absolute hostnames (has a dot in the
middle).
Tools that look in the DNS have to handle *more* than
hostnames such tools may need to treat "hk" as absolute in
which case "hk." is reasonable. "dig" and "nslookup" are
examples of such tools.
Telnet is not a example of a tool that need to support "hk."
as it is expecting hostnames not arbitary domain names.
Web browers are not tools that needs to support "hk.".
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.
=20
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.
You are wanting to extend the definition of a legal absolute
hostname.
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.
There was a clear decision to move from a single label
hostnames to multiple label hostnames (RFC 921). You are
attempting to reverse that decision.
Just because it is technically possible to add A records
at the apex of a tld or to add A records to names with
underscores in them doesn't change the fact that doing
either of these is a bad idea.
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.
No, it doesn't represent clean design. Making them work is
outside of the design scope. Unqualified names being looked
up against search lists was in the design scope. The
official names of hosts having multiple labels was in the
design scope. Single labels were explictly excluded from
being official names in the design scope.
Having single label hostnames match against the root is a
clear implementation error.
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. =20
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.
--=20
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
--5me2qT3T17SWzdxI
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkh0F6MACgkQaUz3f+Zf+XuzqQCcC69WZYCEJvHjCbVDgo4rB6WE
2owAnji2UmzqfY2p2kQTFKfXdZ2toe4Q
=hUoe
-----END PGP SIGNATURE-----
--5me2qT3T17SWzdxI--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf