Re: Dotless domains

[Mark Andrews <[e-mail]>]

In message <534FD5EDF4F26F5DE55EE826@[192.168.1.118]>, John C Klensin writes:
> --On Monday, January 26, 2009 9:56 AM +1100 Mark Andrews 
> <[e-mail]> wrote:
> 
> > In message <[e-mail]>, John C 
> Klensin writes:
> 
> >> --On Saturday, January 24, 2009 21:02 -0500 Keith Moore
> >> <[e-mail]> 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: [phone]                 INTERNET: [e-mail]