[Top] [All Lists]

Re: Dotless domains

2009-01-28 01:00:41

In message <534FD5EDF4F26F5DE55EE826(_at_)[192(_dot_)168(_dot_)1(_dot_)118]>, 
John C Klensin writes:
--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 
or software.

You know where to find the virtual pencil.  I would certainly
support such a document, but the real support would need to 
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.


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 

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.

        I'm not saying that there shouldn't be a document.  The DNS
        is the wrong place to focus the document.

        I've added lots of checks to named (BIND) to catch all
        sorts of rubbish.  I've also received lots of flac from
        various quarters.

             check-names (labels are ldh) but even with check-names
        you need to have exceptions like "." which passes as it is
        used as a place holder.
        And there is only so much a DNS implementation can do.  LDH
        applies to both alias and hostnames but as CNAMES are a
        general aliasing mechanism in the DNS you can't enforce LDH
        on CNAME owners as you do on A record owners.

        Did in the MX data start out as a address
        or a hostname?

        We do what we can to catch badness.  We can't catch all of
        it however as only the consumer of the data can tell if it
        is bad or not.

        check-integrity <boolean>;
        check-mx ( fail | warn | ignore );
        check-mx-cname ( fail | warn | ignore );
        check-names ( master | slave | response ) ( fail | warn | ignore );
        check-sibling <boolean>;
        check-srv-cname ( fail | warn | ignore );
        check-wildcard <boolean>;

    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. 

        Host table had or was in the process of having hierarchical
        names added as well as unqualified aliases.

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".

        RFC 952 says hostnames don't have trailing periods.  They
        are only seperators of labels.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews(_at_)isc(_dot_)org

<Prev in Thread] Current Thread [Next in Thread>