Chuck Yerkes writes:
> Quoting Peter Seebach (seebs@plethora.net):
> > So, Mozilla and a couple of other programs are consistently failing to look
> > up any name with _'s in it.  The most obvious (and topical) example would
> > be http://dear_raed.blogspot.com/.  "nslookup" finds it; "ping" doesn't.
> 
> You mean hosts that violate the DNS RFCS?

They don't violate any DNS RFCs.  If they violate anything, it's
RFC952, the "DOD Internet Host Table Specification", which predates
the DNS.

> In 95 or so, apple came out with (OS) system 7 (AFAIR).
> It's DNS implementation strictly complies with the RFCs.
> It didn't support _ in hostnames.

That implementation is not compliant.  Any DNS implementation which
does not support all 256 possible octet values in DNS names (whether
they are used as "hostnames" or for other purposes) is broken; see
RFC2181 section 11.

> This, of course, caused the Apples to not be able to get
> to various Notes servers named ny_foo_bar.sub.example.com.
> Names which we told them were BAD names (ny was the subdomain,
> so have it in the host) and ILLEGAL names.

Two separate errors conspired to cause this problem.  The ny_foo_bar
administrators violated RFC952 by using underscores in the name of an
Internet host, and Apple violated the DNS specification by making
their DNS implementation reject perfectly good DNS names.

> I'm surprised the blogspot.com's DNS servers don't emit an error.

That's because as far as the DNS is concerned, there was no error.

The name checking code that is causing all these problems was
originally added as a misguided workaround for broken applications
that used the strings returned from gethostbyaddr() insecurely, for
example making them part of the argument to system() despite the fact
that they could contain shell metacharacters.  Adding the checks was a
bad idea - not only does the checking violate the DNS specification and
reduce the usefulness of the DNS, but the fact that some systems do
such checking can give application programmers a false sense of
security by making them think data returned from the DNS is always
guaranteed to be free from metacharacters when it in fact is not.
-- 
Andreas Gustafsson, gson@gson.org