Underscores in host names
trainier at kalsec.com
trainier at kalsec.com
Wed May 18 16:38:41 UTC 2005
There IS a patch available to "fix" the issue in squid which refuses to
pass/cache data from websites/domains with "_" in their name.
I'll also note that bind 4.9.4 also has issues with underscores in
host/domain names.
David Conrad <david.conrad at nominum.com>
Sent by: owner-nanog at merit.edu
05/18/2005 12:35 PM
To
Mark Andrews <Mark_Andrews at isc.org>
cc
nanog at merit.edu
Subject
Re: Underscores in host names
As a result of my late night rant (must learn not to read email late
at night after getting off an airplane), I have received input that
two applications that have issues with the "_" character:
1) Squid/Squid proxy from two people (although there wasn't any
indication of the actual issue, presumably Squid won't be able to
contact the host to cache the content?)
2) "Create a cert for a host with an _ in the name, install said
cert into apache/mod_ssl, try to surf (at least using IE)
to that server." -- Matthew Christopher
This is useful information and can help the original requester make
the business decision as to whether or not he will relax his
restriction against "_" in the character string that he'll allow his
customer to use in data sent to/received from domain name servers he
controls.
I suspect the rest of the jihad against heathen characters such as
"_" should probably be redirected to namedroppers so I won't comment
further.
Rgds,
-drc
On May 18, 2005, at 2:15 AM, Mark Andrews wrote:
> A hostname is not a domainname. It's all through RFC's 1033,
> RFC 1034 and RFC 1035. There are references that make it clear
> that a domain name is not the same as a hostname.
>
> I quoted one of them. I can find other references.
>
> Proctor&Gamble.com anyone? That is the logical concusion of
> saying hostnames are arbitary 8 bit strings.
>
>
>> The whole reason for check-names was because of very seriously broken
>> software that would allow shell meta-characters in in-addr.arpa
>> labels to do bad things. I have come to the opinion that if such
>> software still exists, then the people who run that software deserve
>> what they get. Check-names was a bad idea that might have been
>> justified at the time, but pretending it remains justified by
>> 952/1123 has got to stop sometime.
>>
>
> We tried hard to kill check-names. The only reason it still
> exists is that people wouldn't move from BIND 8 without it.
>
> I havn't run with "check-names answer" enabled in years.
>
>
>> However, that rant was mostly irrelevant. Can you point to _ANY_
>> application, operating system, or anything else that has any issues
>> whatsoever with an "_" of all characters?
>>
>
> The original query was about a OS / application that had
> problems with underscores.
>
> The point of RFC's is to promote interoperability. People
> who attempt to name there machines with underscores either
> don't know better or don't care about interoperability or
> both.
>
> The simplest way to fix this is for application that
> configure hostnames, real or virtual, to reject by default
> illegal hostnames. Apache should not allow virtual sites
> with illegal hostnames without explicit overrides. Similarly
> for your favourite MTA, DNS server etc. If people want to
> use them they need to know they are stepping out of the
> area where interoperability should occur.
>
> Note: SRV and Active Directory *both* depend on underscore
> not being legal in hostnames to keep their names spaces
> seperate from the hostname namespace.
>
> Half the anti-spam/DNS schemes depend upon underscore not
> being legal in a hostname.
>
> Mark
>
>
>> Rgds,
>> -drc
>>
>> On May 17, 2005, at 6:08 PM, Mark Andrews wrote:
>>
>>> RFC 952 and RFC 1123 describe what is currently legal
>>> in hostnames.
>>>
>>> Underscore is NOT a legal character in a hostname.
>>>
>>
>>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050518/8175acd0/attachment.html>
More information about the NANOG
mailing list