Re: Dotless domains

--On Monday, January 26, 2009 9:56 AM +1100 Mark Andrews 
<Mark_Andrews(_at_)isc(_dot_)org> wrote:
> In message <92D1093C43E4FBD3032A5B7B(_at_)PST(_dot_)JCK(_dot_)COM>, John C 
Klensin writes:

> > --On Saturday, January 24, 2009 21:02 -0500 Keith Moore
> > <moore(_at_)network-heretics(_dot_)com> wrote:
> > > IMHO, there should be an RFC explaining that use of a TLD 
as a
> > > terminal domain name was never intended to work, and should
> > > not be expected to be supported by the Internet 
architecture
> > > or software.
> >
> > You know where to find the virtual pencil.  I would certainly
> > support such a document, but the real support would need to 
come
> > from DNS folks.
>         How so?  The DNS is a container to hold information.  The
>         rules about that information are external to the DNS and
>         always have been.
Mark,

I don't want to single you out for abuse because the approach 
you comment shows is pretty common, but comments like the 
above, while certainly true, are one of the reasons we see so 
many uses, and proposed uses, of the DNS that just don't work 
very well operationally.   Sure, the DNS can be viewed as a 
container that can be used to store almost any data.  People 
have discovered that the data of an MX record is more or less 
just a string and that lots of nonsense can be stored there, 
including IP addresses and names of aliases.  In principle, we 
don't need special provisions for IDNs because, after all, 
nothing prevents eight-bit data in labels.  And, yes, the root 
zone is really no different from any other zone and, if folks 
want to put a million delegations there or, for that matter, 
install address records so that "http://./"; or "ftp ." could, 
in principle, work, then the DNS, as a data container, doesn't 
care.
I think there is agreement that at least some of those things 
are dumb and would cause problems in practice.  Perhaps you 
disagree.   But when someone says "this is dumb and there 
should be a document that explains why it should be prohibited/ 
avoided" and you (or some other DNS expert) responds by saying 
"no, the DNS is just a container and doesn't care", those who 
want to do dumb things take that as approval and start 
insisting that they should be able to do whatever they want to 
do and that you (and DNS experts generally) are endorsing it.
>         One of the problems is lots of RFC's say "domain name" when
>         they are actually refering to a "hostname".  This has
>         introduced lots of confusion.
One of the problems is that lots of RFCs are ambiguous or 
contradictory as to whether that distinction exists and all and 
what it means.  If memory serves, two of them are RFC 1034 and 
RFC 1123.
>         RFC921 made it pretty clear that we were to stop using non-
>         heirachical names and that single labels were only ever to
>         be used as aliases for heirachical names.
Sure, but the context of 921 was very different -- not local 
versus hierarchical but host tables versus domain names. 
Whether 921 has any particular meaning today is an interesting 
question.  If you want to cite it as authoritative, you had 
best convince the IESG to change its status from "UNKNOWN" to 
"BCP" at least.
>         Saying that non-heirachical names only have local scope and
>         are to not to be used for global scope addressing would be
>         a good thing.  This leaves "localhost" in local scope.
But, unless I misunderstood Keith's comment, that sort of 
statement/ restriction is exactly what he was asking for and 
with which I was trying to agree.  But a narrow reading of 
either your comment above or some of the statements in RFC 2181 
would say "that is not a DNS issue"... which some people would 
promptly interpret as "'localhost.' is a perfectly reasonable 
FQDN and, in any context in which a string is known to be an 
FQDN, 'localhost' and 'localhost.' are exactly equivalent".
   john