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
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.
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.
e.g.
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 1.2.3.4.example.net 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
john
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org