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

[Mark Andrews <[e-mail]>]

> 
> --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: [phone]                 INTERNET: [e-mail]
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf