Underscores in host names

Mark,

Grump.

I used to be in the 952/1123 sect, but I have since reformed and
continue to do penance for my sins.

The "hostname is not a domain name" dodge is simply wrong. If you
like, I can get a signed affadavit from the author of the DNS
specifications (assuming he's in the office tomorrow) to the effect
that it was always his intent that domain names be composed of any 8-
bit value. That's the whole reason for length encoding the labels.
RFC 2181, for all its other warts, explicitly clarified this
particular issue.

  No one is saying that a domain name can't be any 8 bit value.

  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

However case insensitivity puts a big spanner in the works.

Tony.

a message of 12 lines which said:

However case insensitivity puts a big spanner in the works.

And the fact that you can use any 8-bits character in a domain name
but nothing says what the encoding is. UTF-8 ? Latin-1 ? Big5 ? (Some
unscrupulous vendors promoted "international domain names" using that
trick.)

Hence the RFC 3490.

No, that's merely a lemma along the way.

The logical *conclusion* would be "no xn-- in hostnames".

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

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@nominum.com
Sent by: owner-nanog@merit.edu

05/18/2005 12:35 PM

To
Mark Andrews Mark_Andrews@isc.org

cc
nanog@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@isc.org
>

David Conrad wrote:

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?)

the resolver library barfs up an error

I suspect the rest of the jihad against heathen characters such as
"_" should probably be redirected to namedroppers so I won't comment
further.

Not unless namedroppers is authoritative for /etc/hosts now too.

That's the whole point here--DNS may be more powerful than what the
hostname syntax rules allow, but the mere existence of that capability has
zero bearing on the canonocial syntax rules.