Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

[John C Klensin <[e-mail]>]

--On Friday, 04 July, 2008 09:14 +1000 Mark Andrews
<[e-mail]> wrote:

> 
>> Mark Andrews wrote:
>> 
>> > The Internet went to multi-label hostnames ~20 years ago.
>> 
>> As noted in RFC 2821 as "one dot required" syntax, also
>> mentioned in RFC 3696.  Recently *overruled* by 2821bis.
> 
> 	There is a difference between allowing protocol to be used
> 	in a "local" only mode (single label) and a "global" mode
> 	(multi-label) and saying you must support single label in
> 	a global context.
> 
> 	Single label names are local in scope.  Attempting to use
> 	them in a global context does not work.  As the names in
> 	"." get more interesting the probability of collisions with
> 	existing names goes up.  Not many people choose two letter
> 	labels for the least significant parts of their host names
> 	unless they are choosing their initials.
> 
> 	Museum on the other hand is a real English word.  I'm sure
> 	you will find lots other uses of "museum" in the DNS.  The
> 	same thing will happen with other TLD's as the rules are
> 	relaxed.
> 
> 	Single label hostnames are not globally unique.  They SHOULD
> 	NOT be used in a context where globally unique names are
> 	required.

Mark,

With the understanding that I agree with everything you say
above, there are some interesting problems with SMTP (and maybe
some other protocols) as well as with how ICANN is proceeding.
In no particular order...

(1) ICANN is well aware of the problem you mention with "museum"
and presumably with "coop", "jobs", "name", and maybe some
others I've forgotten at the moment.  As I understand it, they
have explicitly decided to ignore that problem except for names
of countries.  The problem also gets orders of magnitude worse
as we move to IDNs, especially it we also consider
transliterations of non-ASCII strings into scripts other than
the those to which the relevant word is native (whatever that
means -- the concept is extremely dubious for some languages).   

Whether the decision to enable the searching risks associated
with the use of names, rather than short mnemonics of
pre-specified length, is the result of realizing that the
problem is hopelessly intractable (it is) or the result of
rampant commercialism is probably in the eye of the beholder.


(2) Regardless of what some of us may think about the
desirability (or not) of associating services with TLD names, as
soon as we accept the idea that top-level domain names have
semantic content and are associated with fields of endeavor,
types of organizations or enterprises, etc., the desire to
associate, e.g., directory services or "help" functions with the
TLD follows almost naturally.   For years, we managed to dodge
that problem with conventional subdomains (e.g., nic.example.),
but we have not, to my knowledge, ever promoted those uses via,
e.g., a BCP that strongly recommends them (unlike the email
case, where RFC2142 does just that).

In the absence of reserved-name recommendations strong enough to
substitute for services associated with TLDs (and the horse has
probably let the barn on doing that), I think it is inevitable
that we will see more and more demand for the functionality
implied by

   some-protocol://TLD-name./

(with or without that trailing dot).   Some sort of directory
service for the domain is the obvious case, but there are
others.  I can think of only three ways to get that
functionality:

	(i) Associate services with the TLD in the DNS.
	
	(ii) Install a TLD wildcard that points to the relevant
	services (and pray that it doesn't point to anything
	else)
	
	(iii) Reserve conventional subdomain names so that an
	application can turn "some-protocol://TLD-name/" into,
	e.g., 
	  some-protocol://some-protocol.TLD-name/

But, as discussed above, I believe we have waited much too long
to do anything effective about the third possibility.  And
simply saying "this is a bad way to use the DNS" is clearly not
going to get us anywhere in the current environment, even if it
were true.


(3)  SMTP does not permit an explicit trailing period in
addresses on the wire, so 
    RCPT TO:<somemailbox@example.>
is a syntax error.   RFC 2821 permitted it (as Frank points
out), unlike RFC 821 (which, I think, predated the discovery
that being able to explicitly specify the root was sometimes
important).  Discussion about 2821bis concluded that permitting
the trailing period caused more problems than it solved, so we
are back to not permitting it.   What 2821bis says in essence is
that it is the responsibility of the sending application to
figure out whether, if a user presents "somemailbox@example",
that implies the "example" TLD or an invitation to start
searching.  The application is expected to provide local syntax
when necessary to assist in making that distinction.

So, much as I'd like it if we could say "Single label names are
local in scope...does not work", I fear that it is unrealistic
in practice unless we can somehow turn the clock back 15 years
or so.  If one even wanted to try to do that, the first step
would be to write that BCP that recommended a set of
role-specific second-level names.   Changes to the 2606 list are
irrelevant to that goal.

    john


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