Re: Underscores in host names

[william(at)elan.net]

On Fri, 20 May 2005 [EMAIL PROTECTED] wrote:
It would be written "chto ti hochesh videti" or "chto ti xochesh
videti". Russian transliterations are rather easy to follow since they are
phonetic. We are not counting 3l33t speakers.
When Russian is written using English letters, it is phonetic. The native
speakers understand it. The non-native speakers look at it the same way as
they view domain names that do not contain recognizable words.
Even in your own example you used "x" in place of "h" - this is not 
phonetic but literal representation of russian letter "x". So while it
is for the most part phonetic, it really depends on who is writing
and I've yet to see two people use exactly the same transliteration of 
russian in latin letters; as an example I would write above as
"chto ty hochesh videt'".

Oh, and did I mention that written cyrillic russian difers from spoken 
language and as it regularly has ambigous soft/hard sounds transliterated 
only as hard. When transliterating to latin many do it from spoken language
sounds, so don't be surprised to see "shto ty hochesh videt'" (which might
turn into "wto ty hochew videt" for those few who represent "sh" as "w"
because letters are visually similar eventhough sounds are not) and then
others do it the other way around making everything hard and even getting
rid of yat' derived letters - "chto ti hochesh videt".

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Underscores in host names

[alex]

> And people who write Russian in mobile phone SMS
> will often write things like
> 
> 4to ti xo4esh videt?

It would be written "chto ti hochesh videti" or "chto ti xochesh
videti". Russian transliterations are rather easy to follow since they are
phonetic. We are not counting 3l33t speakers.

> Russia is an interesting country with respect to
> domain names. Sometimes you will see a domain name
> written in cyrillic characters that are intended to
> be transliterated one-by-one into latin characters.
> This is signified by using cyrillic for the .ru ending.
> And sometimes you see a cyrillic domain name with
> a russian word which is intended to be translated 
> into the english word to form the domain name.

When Russian is written using English letters, it is phonetic. The native
speakers understand it. The non-native speakers look at it the same way as
they view domain names that do not contain recognizable words.


Alex

Re: Underscores in host names

[Michael . Dillon]

> You know what the constraints are -- no zone local semantics (e.g., case
> folding rules, courtesy H.A.) for a glyph repetoire that in some ranges
> is also a character set, no intermediate tables, no flag day(s) for 
apps,
> and so on.

It's sad that one of the constraints isn't for this to
be explained in plain English. Sometimes I think people
take jargon too far. Yes, we do need some special vocabulary
to talk about detailed technical things, but every time we
invent new vocabulary, we compartmentalize knowledge into
stovepipes and we prevent cross-fertilization with other
fields of knowledge.

> P.S. 17th century French lacked a "w" character, "8" is a "u" atop an 
"o".

And people who write Russian in mobile phone SMS
will often write things like

4to ti xo4esh videt?

Where the "4" represents "ch" and the two
occurences of "i" represent two separate
cyrillic letters.

Russia is an interesting country with respect to
domain names. Sometimes you will see a domain name
written in cyrillic characters that are intended to
be transliterated one-by-one into latin characters.
This is signified by using cyrillic for the .ru ending.
And sometimes you see a cyrillic domain name with
a russian word which is intended to be translated 
into the english word to form the domain name.

--Michael Dillon

Re: Underscores in host names

[Edward Lewis]

At 17:53 -0400 5/19/05, Eric A. Hall wrote:
Edward Lewis wrote:
 It's true that the xn-- convention isn't the best way to encode
 IDN's, but it has proven to be the optimal one in design (at least).
It's the necessary minimum for compatibilty purposes, but not anywhere
near the optimal design.
Moreover, those have nothing to do with each other.
"Optimal" is so subjective.  ;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.

Re: Underscores in host names

[Eric A. Hall]

Edward Lewis wrote:

> It's true that the xn-- convention isn't the best way to encode 
> IDN's, but it has proven to be the optimal one in design (at least). 

It's the necessary minimum for compatibilty purposes, but not anywhere
near the optimal design.

Moreover, those have nothing to do with each other.


-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: Underscores in host names

[Brad Knowles]

At 11:45 AM -0400 2005-05-19, Jay R. Ashworth wrote:
No, they don't, but .ws and .gw are not going to be the only ones
 doing this kind of thing, and this problem won't go away unless
 something is done to expressly prohibit this kind of behaviour.
 Perhaps I left my program in the men's room, but wasn't the point of
 this thread that "something has already been done to prohibit this"?
 IE: 2821 says that's an invalid address?
	Right now, we're on the fence.  There's a piece of paper that 
says we're supposed to be on one side (and most people are), but 
there are a number of people who are on the other side.

	One way or the other, we need to get everyone on the same side of 
the fence.  And we need to make sure that is actually enforced at a 
very low level within the basic library routines implemented on all 
OSes.  For a short while, it might be convenient to try to fix this 
problem within the DNS, but I think that's what has gotten us into 
this mess in the first place.

We need to fix this problem, and we need to fix it in the right place.
	However, regardless of which side of the fence you think we 
should be on, and where you think the right place is to further 
discuss this topic, I can assure you that NANOG is not it.

--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
  SAGE member since 1995.  See  for more info.

Re: Underscores in host names

[Eric Brunner-Williams in Portland Maine]

> Supporting "IDN" is a necessary job.  That's been made clear to the 
> Internet community.  If it "complicates" things, well, then that's 
> what has to be done.  If the Internet is to be global, it can't 
> restrict the world to just a few convenient languages.

Not to quibble unnecessarily, but the folks I came to the dance with at
IETF-50, eventually went home fairly disapointed after -51, and -52,with
none of their proposed mechanisms drafts having obtained even working group
draft status.

You know what the constraints are -- no zone local semantics (e.g., case
folding rules, courtesy H.A.) for a glyph repetoire that in some ranges
is also a character set, no intermediate tables, no flag day(s) for apps,
and so on.

To describe that as "IDN", rather than "a way to represent, poorly for
some, not so poorly for others, character sets other than ASCII in apps",
leaves the later reader ignorant of the baroque design choices available
and discarded on the road to RACE II.

In Abenaki, "w", "ou" and "8" all collate to the same code point, and the
representation of the code point is application specific (modern, early,
and 17thrCa styles).

Eric

P.S. 17th century French lacked a "w" character, "8" is a "u" atop an "o".

Re: Underscores in host names

[Edward Lewis]

At 8:52 -0700 5/19/05, Roger Marquis wrote:
On Thu, 19 May 2005 [EMAIL PROTECTED] wrote:
...
 Don't like RFC3490 and its xn-- hostnames? ;)
xn--... aren't host names, they are domain names.  The host name 
corresponding to that would be something my simple minded mail 
application can't accept as input.

Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with "-", TLD names shorter than 2 or longer than 4 characters,
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.
There is real value in KIS, and not just from the perspective of a
security-minded coder...
KIS is great, if it gets the job done.  Systems that are too simple 
are useless too.

Supporting "IDN" is a necessary job.  That's been made clear to the 
Internet community.  If it "complicates" things, well, then that's 
what has to be done.  If the Internet is to be global, it can't 
restrict the world to just a few convenient languages.

It's true that the xn-- convention isn't the best way to encode 
IDN's, but it has proven to be the optimal one in design (at least). 
It would have been nice to use a new domain name label type, but 
we've about run out of them.  It would have been nice to use domain 
classes and use this to create a new domain name syntax, but that 
can't be done either.  Encoding IDNs this way ("xn--") is optimal 
according to the considered opinion of the IETF, at least those 
working on RFC 3490 (published in 2003), when you consider impacts on 
other protocols and applications.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.

Re: Underscores in host names

[Jay R. Ashworth]

On Thu, May 19, 2005 at 08:52:56AM -0700, Roger Marquis wrote:
> Most definitely not, and if this were 1985 I'd be {rf}commenting on
> the inadvisability of such hostnames, and those beginning or ending
> with "-", TLD names shorter than 2 or longer than 4 characters,

> spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
> useful but infinitely problematic features.

I understand your other concerns, there, but TLD length?

To preserve assumptions in old apps?

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: Underscores in host names

[Jay R. Ashworth]

On Thu, May 19, 2005 at 12:01:54PM -0300, MARLON BORBA wrote:
> Hmm, they've always teached to me that . (dot) at the end of hostnames
> indicates the (hidden) Root domain:
>
> blah.domain.com.[Root]

This much is true.

> And my teachers always said that we don't need to write the final .
> because every domain belongs to the Root domain.

This, not so much.  Well, kinda.

Specifically, as I think was noted earlier on the thread in passing, as
well, that trailing dot is a hint *to your local name resolver* that
says "do not attempt to apply any locally defined DNS search path to
this name; look it up once, anchored to the DNS root[0], and if you get
an NXDOMAIN, believe it".

Semantically, that trailing dot, as it is presented to an application,
*is not part of the domain name*.  It's ephemeral; only existing on the
machine where you type it in -- specifically, it does not get sent in
queries (SFIAK), even if you typed it in.

So, no, you *don't* need to write it, unless you as an application user
are trying specifically to pin the name on the root... but it's
invisible to the rest of the system, just as the names themselves are
invisible to the TCP stack once you've looked them up and opened a
stream.

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: Underscores in host names

[bmanning]

On Thu, May 19, 2005 at 11:45:31AM -0400, Jay R. Ashworth wrote:
> 
> On Thu, May 19, 2005 at 11:47:09AM +0200, Brad Knowles wrote:
> > At 3:39 PM +1000 2005-05-19, Mark Andrews wrote:
> > >   Any tld that thinks this will ever work reliably need their
> > >   heads read.  There was a good reason all the unqualified
> > >   hosts got moved into .ARPA.  Single label hosts do not work
> > >   well on a global scale.
> > 
> > No, they don't, but .ws and .gw are not going to be the only ones 
> > doing this kind of thing, and this problem won't go away unless 
> > something is done to expressly prohibit this kind of behaviour.
> 
> Perhaps I left my program in the men's room, but wasn't the point of
> this thread that "something has already been done to prohibit this"?
> IE: 2821 says that's an invalid address?  

er... RFC 2821 was published -after- this was an established
practice.  

--bill

> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth[EMAIL 
> PROTECTED]
> Designer   InternetworkingRFC 2100
> Ashworth & Associates  Best  Practices '87 e24
> St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274
> 
>   If you can read this... thank a system administrator.  Or two.  --me

Re: Underscores in host names

[Edward Lewis]

At 12:01 -0300 5/19/05, MARLON BORBA wrote:
Hmm, they've always teached to me that . (dot) at the end of hostnames
indicates the (hidden) Root domain:
blah.domain.com.[Root]
And my teachers always said that we don't need to write the final . because
every domain belongs to the Root domain.
This thread needs to consider the layering of applications.  E.g.,
 Applications:   Mail, Web, things using gethostbyname(host names, etc.)

 Infrastructure: DNS, etc, (such as X.500)(domain names)
Apps deal with host names, DNS deals with domain names.  To the DNS, 
host names are a subset of domain names.  To applications, domain 
names per DNS are "behind that interface."  Apps deal with host names 
and other names, all of which, if running over DNS, are mapped into 
domain names.

Referring to the above text, yes, a full qualified domain name ends 
in a "dot."  Whenever talking to or among DNS elements, the "dot" 
terminates the FQDN.  It must syntactically - a zero length label is 
the "null termination" of the domain name.

Applications passing domain names to the DNS (not strings of domain 
names) must have this terminating null.  However, this does not mean 
that the applications have to make the user or GUI require the null, 
as that interface is likely to be dealing with a string version of 
the name.

Some DNS applications, such as dig, don't require a dot at the end of 
the name - if one is missing, the dot is appended.  The user is 
alleviated of the burden of adding the dot - but on the other hand - 
the dot is forced upon the user.

Some applications, being agnostic, won't add anything to the user's 
input.  (This is true for non-DNS applications too.)  This gives the 
knowledgeable user more power - unique things can be done.  But it 
means that novices have more to learn.

Some applications assume the user is lazy and adds the dot in all 
instances.  Knowledgeable users get burned because now here are two 
terminating dots at times - until these users remember to "fall back" 
to not terminating domain names.

I've seen all three kinds of applications.  The latter ones tend to 
be the quick and dirty prototypes that don't see the light of day.

The moral is that applications are choosing when to add the 
terminating dot.  It's always there in DNS, but people don't access 
the DNS without going through an application.

As far as whether an "_" is "legal" in a host name, you can attack 
the question in many ways.

When cast into a domain name, "_" is legal.  DNS assigns no special 
meaning to that character in domain names.  Not even in the SRV 
record - if one reads the document carefully, there is no special 
meaning assigned by DNS, only a convention proffered that uses the 
"_".  The convention is a function of the applications using the SRV, 
not the manipulation of the SRV within the DNS.

When cast into a host name, "_" is not among the legal characters 
specified in the ancient documents.  But documents are just documents 
- arguing over what's legal according to them is about as useful as 
watching haircuts.  (Unless you are on a software design & 
implementation team.)

When thrown into applications, "_" may or may not have a special 
meaning.  Some applications will raise exception to "_".  The more 
interesting question is why?  Is this simply because of the ancient 
documents' restrictions?  Is there some parsing consideration?  Is 
there a special semantic inferred?

It really isn't important whether the character is "legal" or not 
(until there is a network police force).  What is more important is 
whether the character will work in all environments in which the name 
is needed.

Will the "_" work in DNS domain names?  Yes, unless there is a but in 
the DNS implementation (always a caveat).  Will the "_" work in a 
host name?  Only if the applications in use, referring to the host, 
can handle such a name.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.

Re: Underscores in host names

[Roger Marquis]

On Thu, 19 May 2005 [EMAIL PROTECTED] wrote:
On Thu, 19 May 2005 08:04:31 PDT, Roger Marquis said:
Laurent Frigault wrote:
gethostbyaddr (and may be other functions) will return NULL under at
least FreeBSD/NetBSD for ANY PTR having the "_" character.
As it should.  I wish it would also return a null for hostnames
containing sequential non-alphanumerics (--, ---, __, ___, ...).
Don't like RFC3490 and its xn-- hostnames? ;)
Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with "-", TLD names shorter than 2 or longer than 4 characters,
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.
There is real value in KIS, and not just from the perspective of a
security-minded coder...
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Re: Underscores in host names

[Jay R. Ashworth]

On Thu, May 19, 2005 at 11:47:09AM +0200, Brad Knowles wrote:
> At 3:39 PM +1000 2005-05-19, Mark Andrews wrote:
> > Any tld that thinks this will ever work reliably need their
> > heads read.  There was a good reason all the unqualified
> > hosts got moved into .ARPA.  Single label hosts do not work
> > well on a global scale.
> 
>   No, they don't, but .ws and .gw are not going to be the only ones 
> doing this kind of thing, and this problem won't go away unless 
> something is done to expressly prohibit this kind of behaviour.

Perhaps I left my program in the men's room, but wasn't the point of
this thread that "something has already been done to prohibit this"?
IE: 2821 says that's an invalid address?  

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer   InternetworkingRFC 2100
Ashworth & Associates  Best  Practices '87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: Underscores in host names

[Edward Lewis]

At 8:04 -0700 5/19/05, Roger Marquis wrote:
Laurent Frigault wrote:
 gethostbyaddr (and may be other functions) will return NULL under at
 least FreeBSD/NetBSD for ANY PTR having the "_" character.
As it should.  I wish it would also return a null for hostnames
containing sequential non-alphanumerics (--, ---, __, ___, ...).
If null were returned for all "host names" containing "--" then IDN 
names wouldn't "work."  (See RFC 3490, section 5.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

Re: Underscores in host names

[Tony Finch]

On Thu, 19 May 2005, Roger Marquis wrote:
>
> As it should.  I wish it would also return a null for hostnames
> containing sequential non-alphanumerics (--, ---, __, ___, ...).

It is possible to reject multiple dots, both in theory and in practice (in
fact it's a useful for spotting certain kinds of spamware that generates
bogus HELO domains).

You can't reject double hyphens because they are permitted by the syntax
and used by IDN, for example.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: Underscores in host names

[Valdis . Kletnieks]

On Thu, 19 May 2005 08:04:31 PDT, Roger Marquis said:
> 
> Laurent Frigault wrote:
> > gethostbyaddr (and may be other functions) will return NULL under at
> > least FreeBSD/NetBSD for ANY PTR having the "_" character.
> 
> As it should.  I wish it would also return a null for hostnames
> containing sequential non-alphanumerics (--, ---, __, ___, ...).

Don't like RFC3490 and its xn-- hostnames? ;)


pgp7ouDwfJQQq.pgp
Description: PGP signature

Re: Underscores in host names

[Roger Marquis]

Laurent Frigault wrote:
gethostbyaddr (and may be other functions) will return NULL under at
least FreeBSD/NetBSD for ANY PTR having the "_" character.
As it should.  I wish it would also return a null for hostnames
containing sequential non-alphanumerics (--, ---, __, ___, ...).
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

Re: Underscores in host names

[MARLON BORBA]

Hmm, they've always teached to me that . (dot) at the end of hostnames 
indicates the (hidden) Root domain:

blah.domain.com.[Root]

And my teachers always said that we don't need to write the final . because 
every domain belongs to the Root domain.

As for DNS servers for the Root domain, they are the reason for putting that 
"hint" files into our /var/named directory, "non"?

Regards,

Marlon Borba, CISSP

Abraços,
Marlon Borba, CISSP.

"Por que 100? Bastaria
um se eu estivesse errado!"
--Albert Einstein, sobre o livro dos nazistas
"100 cientistas contra Einstein".
>>> "Peter & Karin Dambier" <[EMAIL PROTECTED]> 05/19/05 9:00 AM >>>
[...]
Because programmes like
check_soa from the O'Reilly book "DNS and BIND" or
sendmail
believe it makes sense to force a dot at the end of
every name they look up.

There are nameservers in the root zone file that DNS will
not find. /etc/hosts is the only way to get them.
Dont forget to have both names with and without dot.

Re: Underscores in host names

[Valdis . Kletnieks]

On Wed, 18 May 2005 21:51:32 -, Paul Vixie said:

(yes, I know this probably belongs on dnsops or someplace)

> just because you own an A RR doesn't make you a hostname.

I'll buy that..

> just because you're pointed to by an MX RR doesn't make you a mailname.

But I'm dubious on that one - what legal configs have an MX pointing at a
non-mailname? (Feel free to include the "technically legal but dumb" options
I'm managing to not remember this early in the morning. ;)



pgp8HMBgqaw3a.pgp
Description: PGP signature

Re: Underscores in host names

[Peter & Karin Dambier]

> --- original message ---
> from: Mark Andrews <[EMAIL PROTECTED]>
> to: nanog@merit.edu
> Re: Underscores in host names
> Datum: Thu, 19 May 2005 10:40:32 +1000 (EST)
> 
>   Hostnames can't have a dot at the end either.  The dot at the
>   end is a local resolver indication to not use the search list.
> 

/etc/hosts:

217.29.76.4   IT2.MIX-IT.NET  IT2.MIX-IT.NET.

Why?

Because programmes like
check_soa from the O'Reilly book "DNS and BIND" or
sendmail
believe it makes sense to force a dot at the end of
every name they look up.

There are nameservers in the root zone file that DNS will
not find. /etc/hosts is the only way to get them.
Dont forget to have both names with and without dot.

That is horrible, but I have to live with it

Regards,
Peter and Karin Dambier

-- 
Peter und Karin Dambier 
Graeffstrasse 14 
D-64646 Heppenheim 
+49-6252-671788 (Telekom) 
+49-6252-599091 (O2 Genion) 
+1-360-226-6583-9738 (INAIC)
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
http://iason.site.voila.fr
peter-dambier.site.voila.fr

Re: Underscores in host names

[Tony Finch]

On Thu, 19 May 2005, Brad Knowles wrote:
>
>   Check Guinea-Bissau for .gw.  This has been a source of heartburn for
> many years.  Any site that has a mail gateway system and uses unqualified
> hostnames is at risk, because mail to "[EMAIL PROTECTED]" could legitimately 
> be
> interpreted two different ways, and mail could be mis-directed.
>
>   I did some consulting at a major wall street trading firm that had
> this problem, and the only reason we ever found out that something truly
> bizarre was going on was because we were getting back these bounces which we
> couldn't explain, because we knew for sure that the user portion was
> legitimate.  Then we started looking closer at where the bounces were actually
> coming from.

This reminds me of the problems with JANET-order versus Internet-order
mail domains that caused some email for cl.cam.ac.uk to go via Chile.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: Underscores in host names

[Michael . Dillon]

>There is a solution for this problem.  Use 32-bit character sets 
> which are defined to include the entire collection of known character 
> sets in all other languages on the planet.

This doesn't solve the problem of case-sensitivity and
its relatives. You probably don't want NANOG.org, nanog.org
and NaNoG.org to be three different domain names. There
are related issues with other scripts, for instance in
Arabic most letters can have different forms
depending on whether they are written isolated, at
the beginning, in the middle or at the end of a word.

Then there are the ambiguities that go across scripts.
For instance, the numeric digits are repeated in both
the arabic form and the common western form. In Russian
the letters HAC are spelled en-ah-ess but they look
like the English letters aitch-ey-see even though they
are encoded differently. Also, Cyrillic Unicode includes
historical letters that are not currently used which
means that many words have more than one spelling.

Unicode is not a workable solution for hostnames or
domain names or any sort of identifier where you want
to unambiguously distinguish the identifiers. For that
we need some kind of mapping that maps all unicode characters
into one single unambigous subset of unicode that can
be used for hostnames, etc.

The good thing is that when we deploy that mapping, you
will be able to use underscores in hostnames. But don't be
surprised if it gets automatically mapped to a dash in
order to avoid ambiguity.

--Michael Dillon

Re: Underscores in host names

[Brad Knowles]

At 3:39 PM +1000 2005-05-19, Mark Andrews wrote:
Any tld that thinks this will ever work reliably need their
heads read.  There was a good reason all the unqualified
hosts got moved into .ARPA.  Single label hosts do not work
well on a global scale.
	No, they don't, but .ws and .gw are not going to be the only ones 
doing this kind of thing, and this problem won't go away unless 
something is done to expressly prohibit this kind of behaviour.

--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
  SAGE member since 1995.  See  for more info.

Re: Underscores in host names

[Brad Knowles]

At 6:10 PM -0700 2005-05-18, william(at)elan.net wrote:
 The only reason it has not been discussed more actively is that no
 TLD operator has yet come forward and said that they are going to use
 TLD host for emails, but as soon as one does this would have to be
 accommodated and quickly (otherwise it will remain as an open issue
 for future update to SMTP - probably RFC4821 if this numbering
 continues :)
	Check Guinea-Bissau for .gw.  This has been a source of heartburn 
for many years.  Any site that has a mail gateway system and uses 
unqualified hostnames is at risk, because mail to "[EMAIL PROTECTED]" could 
legitimately be interpreted two different ways, and mail could be 
mis-directed.

	I did some consulting at a major wall street trading firm that 
had this problem, and the only reason we ever found out that 
something truly bizarre was going on was because we were getting back 
these bounces which we couldn't explain, because we knew for sure 
that the user portion was legitimate.  Then we started looking closer 
at where the bounces were actually coming from.

--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
  SAGE member since 1995.  See  for more info.

Re: Underscores in host names

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>
>
>> Since changing SMTP2821 and waiting until everyone complies and accepts
>> email addresses with no "." is not an option, the solutions proposed are
>> to either have address like "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]"
>>
>> The only reason it has not been discussed more actively is that no TLD
>> operator has yet come forward and said that they are going to use
>> TLD host for emails, but as soon as one does this would have to be
>> accommodated and quickly (otherwise it will remain as an open issue for
>> future update to SMTP - probably RFC4821 if this numbering continues :)
>>
>
>.ws has an MX record.
>host -t mx ws. ==> mail.worldsite.ws
>
>Most MUA's (unix ones tended to work, not surprisingly) complain or break
>on "send" but technically it works. :)
>
>Thanks,
>David Ulevitch
>
>
>   David A. Ulevitch - Founder, EveryDNS.Net
>   http://david.ulevitch.com -- http://everydns.net
>

Any tld that thinks this will ever work reliably need their
heads read.  There was a good reason all the unqualified
hosts got moved into .ARPA.  Single label hosts do not work
well on a global scale.

Mark

Re: Underscores in host names

[william(at)elan.net]

On Wed, 18 May 2005, David A. Ulevitch wrote:
.ws has an MX record.
host -t mx ws. ==> mail.worldsite.ws
Most MUA's (unix ones tended to work, not surprisingly) complain or break
on "send" but technically it works. :)
Read 2.3.5 of RFC2821 and note that "A domain (or domain name) consists of 
one or more dot-separated components"

So technically its not supposed to work, but not everyone is compliant 
with standards...

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Underscores in host names

[David A. Ulevitch]

> Since changing SMTP2821 and waiting until everyone complies and accepts
> email addresses with no "." is not an option, the solutions proposed are
> to either have address like "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]"
>
> The only reason it has not been discussed more actively is that no TLD
> operator has yet come forward and said that they are going to use
> TLD host for emails, but as soon as one does this would have to be
> accommodated and quickly (otherwise it will remain as an open issue for
> future update to SMTP - probably RFC4821 if this numbering continues :)
>

.ws has an MX record.
host -t mx ws. ==> mail.worldsite.ws

Most MUA's (unix ones tended to work, not surprisingly) complain or break
on "send" but technically it works. :)

Thanks,
David Ulevitch


   David A. Ulevitch - Founder, EveryDNS.Net
   http://david.ulevitch.com -- http://everydns.net

Re: Underscores in host names

[william(at)elan.net]

On Thu, 19 May 2005, Mark Andrews wrote:
In article <[EMAIL PROTECTED]> you write:
There are also mail domains to consider. They have superficially the same
syntax as host names (they cannot have a trailing dot) but they are
generally checked much more strictly for conformance to that syntax. I'm
not sure whether the original post was about a mail domain or the name of
a mail host, but if it was the former I would be surprised if the customer
could claim that it works most of the time.
Hostnames can't have a dot at the end either.  The dot at the
end is a local resolver indication to not use the search list.
Actually its been discussed and we may yet see trailing in mail address.
The reason why its been considered is that SMTP RFC2821 spec is flowed
as it requires at least one "." in the hostname (unlike DNS specs that
do not have this requirement for hostname) and that means that you can
not accept as valid email address something like "[EMAIL PROTECTED]", i.e.
if TLD is also a valid host you can not have an email address there.
Since changing SMTP2821 and waiting until everyone complies and accepts
email addresses with no "." is not an option, the solutions proposed are 
to either have address like "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]"

The only reason it has not been discussed more actively is that no TLD 
operator has yet come forward and said that they are going to use 
TLD host for emails, but as soon as one does this would have to be
accommodated and quickly (otherwise it will remain as an open issue for 
future update to SMTP - probably RFC4821 if this numbering continues :)

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Underscores in host names

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>There are also mail domains to consider. They have superficially the same
>syntax as host names (they cannot have a trailing dot) but they are
>generally checked much more strictly for conformance to that syntax. I'm
>not sure whether the original post was about a mail domain or the name of
>a mail host, but if it was the former I would be surprised if the customer
>could claim that it works most of the time.

Hostnames can't have a dot at the end either.  The dot at the
end is a local resolver indication to not use the search list.

Mark

Re: Underscores in host names

[Eric A. Hall]

Paul Vixie wrote:

> putting these checks in for master zones, slave zones, and response
> data was a significant over-reach on my part.  THAT is what i'm
> apologizing for here. (and THAT is what CERT had asked me to do, since
> changing gethostbyaddr() would not, by itself, have protected Sendmail
> from newlines in its qf* files.)

Alright then. Personally I've found them useful at different times in
different places but that's some hair-splitting neither of us is
particularly interested in.

> just because you own an A RR doesn't make you a hostname.
> 
> just because you're pointed to by an MX RR doesn't make you a mailname.
> 
> (what a relief to finally be able to say that.)

At the risk of hair-splitting that I've already disclaimed, I'll halfway
agree (a host that doesn't accept connections arguably isn't a host) and
halfway disagree (the target of an MX must be a valid hostname). To ensure
that this thread dies now, I'll point out that I categorized some of this
as part of my second stab at the great white whale of i18n DNS [see
http://www.ehsco.com/misc/I-Ds/draft-hall-dns-datatypes-00.txt which
ensures nobody comes back]

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: Underscores in host names

[Paul Vixie]

> So, you found some pre-existing rules, used them as cover for your
> problem, and now that your ~problem is fixed the pre-existing rules
> shouldn't matter to anybody anymore? Come on now, isn't it slightly
> possible that those rules were pre-existing for reasons that have nothing
> to do with you?

here's the stretchy part that makes me want to undo what was done.

gethostbyname() knows it's dealing with hostnames.  also gethostbyaddr()
and the modern equivilents (getaddrinfo/getnameinfo/whatever).  also, these
library calls can get their host name/address data from sources other than
dns.  it is in my view perfectly reasonable for these library calls to
demand RFC952-compliance, or compliance with a later specification for "host"
names, if there ever is such.

however, inside BIND4 named.boot and BIND8/BIND9 named.conf you will find
that the server is capable of enforcing hostname (RFC952) and mailname (RFC821)
rules on DNS data like "owner of A RRset" or "owner or target of MX RRset",
on the very stretchy supposition that these names, because they are being
used as part of A-RR or MX-RR sets, must be getting used as "hostnames" or
"mailnames".  that might often be the case, or always-to-date be the case,
but it ain't NECESSARILY the case.

putting these checks in for master zones, slave zones, and response data was
a significant over-reach on my part.  THAT is what i'm apologizing for here.
(and THAT is what CERT had asked me to do, since changing gethostbyaddr()
would not, by itself, have protected Sendmail from newlines in its qf* files.)

> ...
> I'm glad you fixed your problem, but really, this isn't about DNS, it is
> about universal representation of hostnames despite the media that is used
> to convey those names.

and i'd agree if you said "logic that's meant to support hostnames/mailnames
ought to enforce the known rules about those names."  by which i'd be thinking
of the library calls gethostbyname(), gethostbyaddr(), and so on.  and by which
i would expressly not be referring to anything in the DNS.

just because you own an A RR doesn't make you a hostname.

just because you're pointed to by an MX RR doesn't make you a mailname.

(what a relief to finally be able to say that.)
-- 
Paul Vixie

Re: Underscores in host names

[Brad Knowles]

At 3:51 PM -0400 2005-05-18, Eric A. Hall wrote:
 but it was wrong, and the need for it is past, and it's time for redress.
 So, you found some pre-existing rules, used them as cover for your
 problem, and now that your ~problem is fixed the pre-existing rules
 shouldn't matter to anybody anymore?
Who said the problem is fixed?
   Come on now, isn't it slightly
 possible that those rules were pre-existing for reasons that have nothing
 to do with you?
	Man, did you get up on the wrong side of the world?  Everything 
I've seen from you lately seems to be very acidic and bordering on 
intentionally insulting.

	Can we try to have a decent intelligent discussion?  More 
importantly, can't we have this discussion in a more appropriate 
place?

 Alternatively (and what we have in the pre-existing rules) is to forbid
 those characters entirely, so that nobody is forced to kautau to a
 specific nationalized character set.
	There is a solution for this problem.  Use 32-bit character sets 
which are defined to include the entire collection of known character 
sets in all other languages on the planet.

	But this means you have to have a flag day, unless you can come 
up with some way to also be backwards compatible.  And so long as 
you're backwards compatible, you can't get rid of the legacy 
problems.  So, you're right back where you started.

   While that may feasible in protocol
 commands and such, it's not feasible to mandate that /etc/hosts MUST
 always use US-ASCII code-point values for characters that may not even
 exist in the local nationalized charset.
	The problem is that /etc/hosts is a 30 year old solution, and we 
knew twenty years ago that it didn't properly solve the problem, and 
didn't solve it in the right way.  So long as you're going to call it 
/etc/hosts, I don't see how you can change the character set.

   Really, spend some time with the
 ECMA derivative sets and you'll see what I mean--there are characters in
 some of them that aren't in the others, or they are misplaced, or they are
 defined as alternates, and so forth.
	I live in Belgium.  Been there, seen that.  Exchanging one 
country-specific character set for another is not a solution.  You 
need a more over-arching solution that is equally applicable 
everywhere.

 I'm glad you fixed your problem, but really, this isn't about DNS, it is
 about universal representation of hostnames despite the media that is used
 to convey those names.
	A standalone machine is worthless.  In fact, the definition of a 
truly secure machine is one that is completely isolated from every 
other machine on the planet.  And if that machine is going to be 
connected to others, you have to talk about representational issues, 
which means the DNS.

	Like it or not, when you talk about hostnames, you must also talk 
about DNS.

Now, can we please take this discussion to a more appropriate place?
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
  SAGE member since 1995.  See  for more info.

Re: Underscores in host names

[Eric A. Hall]

Paul Vixie wrote:
> (why are we talking about this on NANOG rather than NAMEDROPPERS?)

because it's not relevant to the underlying rules

>>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.

> at the time of check-names, i outlawed _ as a side effect of punting.  in
> order to strip/prevent newline characters in PTR targets, i had to be able
> to refer to an RFC (lest people come to me with many individual sob stories
> about this or that special character that either should or should not be
> stripped/prevented in gethostbyaddr().)  the only RFC i found that had any
> remote chance of getting me off this hook was #952.  ergo, _ had to die in
> order that my inbox might live.
> 
> but it was wrong, and the need for it is past, and it's time for redress.

So, you found some pre-existing rules, used them as cover for your
problem, and now that your ~problem is fixed the pre-existing rules
shouldn't matter to anybody anymore? Come on now, isn't it slightly
possible that those rules were pre-existing for reasons that have nothing
to do with you?

Consider the code-point value of "$" as it is used in iso-646-us versus
iso-646-de or any of the other ECMA derivatives, or any of the other ISO-*
derivatives that don't have direct ASCII character mappings. That
character (and many others) can have different and distinct code-point
values in multiple character sets, but it has to be identical everywhere
in order for it to have meaning. Thus, allowing the "character" to be used
means mandating a specific code-point value for that character.
Alternatively (and what we have in the pre-existing rules) is to forbid
those characters entirely, so that nobody is forced to kautau to a
specific nationalized character set. While that may feasible in protocol
commands and such, it's not feasible to mandate that /etc/hosts MUST
always use US-ASCII code-point values for characters that may not even
exist in the local nationalized charset. Really, spend some time with the
ECMA derivative sets and you'll see what I mean--there are characters in
some of them that aren't in the others, or they are misplaced, or they are
defined as alternates, and so forth.

I'm glad you fixed your problem, but really, this isn't about DNS, it is
about universal representation of hostnames despite the media that is used
to convey those names.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: Underscores in host names

[bmanning]

> > 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?
> 
> at the time of check-names, i outlawed _ as a side effect of punting.  in
> order to strip/prevent newline characters in PTR targets, i had to be able
> to refer to an RFC (lest people come to me with many individual sob stories
> about this or that special character that either should or should not be
> stripped/prevented in gethostbyaddr().)  the only RFC i found that had any
> remote chance of getting me off this hook was #952.  ergo, _ had to die in
> order that my inbox might live.
> 
> but it was wrong, and the need for it is past, and it's time for redress.

does this mean that i can get my .com  delegation back?
its to support ADA-act compliant web servers.

--bill

Re: Underscores in host names

[Paul Vixie]

(why are we talking about this on NANOG rather than NAMEDROPPERS?)

> 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.

yes.  mea cupla, i let CERT twist my arm into paving over a hole with
BIND that should have been patched in Sendmail.

> I have come to the opinion that if such software still exists, then the
> people who run that software deserve what they get.

me too.

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

at the time of check-names, i outlawed _ as a side effect of punting.  in
order to strip/prevent newline characters in PTR targets, i had to be able
to refer to an RFC (lest people come to me with many individual sob stories
about this or that special character that either should or should not be
stripped/prevented in gethostbyaddr().)  the only RFC i found that had any
remote chance of getting me off this hook was #952.  ergo, _ had to die in
order that my inbox might live.

but it was wrong, and the need for it is past, and it's time for redress.
-- 
Paul Vixie

Re: Underscores in host names

[Laurent Frigault]

On Wed, May 18, 2005 at 12:33:46AM -0700, David Conrad wrote:

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

gethostbyaddr (and may be other functions) will return NULL under at
least FreeBSD/NetBSD for ANY PTR having the "_" character.

There must be many applications impacted.

-- 
Laurent Frigault - NOC GANDI

Re: Underscores in host names

[Eric A. Hall]

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.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: Underscores in host names

[trainier]

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 <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
05/18/2005 12:35 PM




To
Mark Andrews <[EMAIL PROTECTED]>


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: [EMAIL PROTECTED]
>

Re: Underscores in host names

[David Conrad]

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: [EMAIL PROTECTED]

Re: Underscores in host names

[Duane Wessels]

Just one?
Squid.
By default Squid complains if it finds an underscore in a URL
hostname.  It returns an "Invalid URL" error message and explains
that underscores are not allowed in hostnames.  Of course you can
make Squid accept underscores if you prefer.
We felt this was better than returning a "the domain name does not
exist" error message.  It sucks for the user when a name can be
resolved by one machine or by one application, but not by another.
Even on FreeBSD you get different answers from different apps:
chef-wessels ~ 8> host super_bikes.tripod.com
super_bikes.tripod.com has address 209.202.240.100
chef-wessels ~ 9> ping super_bikes.tripod.com
ping: cannot resolve super_bikes.tripod.com: Unknown server error
Duane W.

Re: Underscores in host names

[Eric A. Hall]

David Conrad wrote:

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

Your personal pendulum has no bearing on the relevance on 952/1123.
Hostnames still have their own rules, apart from the media used to
represent those hostnames (eg, hosts or DNS is irrelevant--a hostname is
still a hostname is still a hostname).

> 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.

There's absolutely no corrolation between those two points. Or at least,
the latter point has nothing to do with the former.

As for the latter point in particular, anybody is perfectly free to use
any 8-bit value they want for any label in any domain name, and that point
is hardly in dispute. The point for this thread however, is that 952/1123
defines its own rules for the syntax that can be used to represent a
connection target on the Internet (aka "hosts"). Those rules are quite
clear: letters, digits and hyphen only, length restrictions, etc.

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

Just one?

Squid.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: Underscores in host names

[Valdis . Kletnieks]

On Wed, 18 May 2005 19:15:44 +1000, Mark Andrews said:

>   Proctor&Gamble.com anyone?  That is the logical concusion of
>   saying hostnames are arbitary 8 bit strings.

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

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


pgpVNxozpN5AG.pgp
Description: PGP signature

Re: Underscores in host names

[Stephane Bortzmeyer]

On Wed, May 18, 2005 at 11:05:56AM +0100,
 Tony Finch <[EMAIL PROTECTED]> wrote 
 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.

Re: Underscores in host names

[Tony Finch]

On Wed, 18 May 2005, Mark Andrews wrote:
>
>   No one is saying that a domain name can't be any 8 bit value.

However case insensitivity puts a big spanner in the works.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: Underscores in host names

[Mark Andrews]

> 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

> 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: [EMAIL PROTECTED]

Re: Underscores in host names

[Tony Finch]

There are also mail domains to consider. They have superficially the same
syntax as host names (they cannot have a trailing dot) but they are
generally checked much more strictly for conformance to that syntax. I'm
not sure whether the original post was about a mail domain or the name of
a mail host, but if it was the former I would be surprised if the customer
could claim that it works most of the time.

Names of mail hosts are another matter, especially the names they declare
in HELO. When I analysed this back in December, I found that about 1/3 of
legitimate mail hosts declared invalid hostnames. This is orthogonal to
the issue of host name syntax, but it does show that being excessively
strict will cause you pain. However it is worth checking mail host names
for gross syntax violations since some fairly common spamware puts all
sorts of binary junk in its HELO command.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: Underscores in host names

[Stephane Bortzmeyer]

On Wed, May 18, 2005 at 12:11:14AM -0400,
 Steven Champeon <[EMAIL PROTECTED]> wrote 
 a message of 92 lines which said:

> So, these are *all* non-compliant?

Yes, and you can easily check that the FreeBSD resolver, for instance,
cannot retrieve them (the GNU libc resolver on Linux can).

notux:~ % uname 
FreeBSD
notux:~ % ping Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr
ping: cannot resolve Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr: 
Unknown server error

myriam:~ % uname
Linux
myriam:~ % ping Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr
PING Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr (82.127.31.191) 56(84) 
bytes of data.
64 bytes from Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr
(82.127.31.191): icmp_seq=1 ttl=118 time=49.0 ms

Re: Underscores in host names

[David Conrad]

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.

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.

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?

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.

Re: Underscores in host names

[Steven Champeon]

on Wed, May 18, 2005 at 11:08:03AM +1000, Mark Andrews wrote:
>   RFC 952 and RFC 1123 describe what is currently legal
>   in hostnames.
> 
>   Underscore is NOT a legal character in a hostname.

So, these are *all* non-compliant? Perhaps someone should tell them that.
Certainly would have been nice not to get spammed by them, or to have an
even easier reason to reject same.

003_150.pool-clientes.gilat.com.pe
131_202.btc-net.bg
153_199_103_66-wifi_hotspots.eng.telusmobility.com
154_ras_01.dial-ip.plugon.com.br
194_30_119_112_maca0001.lpp_za_bi.ips.sarenet.es
200.126.99.247.block7_dsl.surnet.cl
200_13_215_210.colomsat.net.co
200_63_222_138.uio.satnet.net
203_221_178_213.easynet.net.au
208_218_35_14.huntsville6.56k.cvalley.net
208_75.compnet.com.pl
212_218.bytom.compnet.com.pl
212_81_214_10_peni.gignu_adsl_ma_ma.ips.sarenet.es
229.usuarios_dhcp-195-219-18.gemytel.net
63_224_210_245.spkn.uswest.net
64_192_75_146.wcg.net
82_119_148_246.stv.ru
Laubervilliers-151_12-16-191.w82-127.abo.wanadoo.fr
adm_node207.ral.esu3.k12.ne.us
adsl_basico_1196-170.etb.net.co
adsl_lav178_218.datastream.com.mt
adsl_pool_20_standard93137-133.etb.net.co
adsl_pool_22_standard93139-190.etb.net.co
adsl_standard_2450-46.etb.net.co
c_178_237.tv-naruto.ne.jp
clientes_corpor_7549-2.etb.net.co
clientes_corporativos69100-82.etb.net.co
corporativo_16780-201.pool.etb.net.co.80.167.65.in-addr.arpa
customer125_200.grm.net
d7_annex_palu_a.lac.telkom.net.id
dean_rm135_2xp.business.colostate.edu
dhcp-210_169_160_191.ttn.ne.jp
dialup_67-36-145-125.ndemand.com
dsl_61_161_30_212.turbonet.com
extremo_pool_11934-63.etb.net.co
extremo_pool_11943-164.etb.net.co
h107_17.u.datacomsa.pl
hfc3-9_32.melitaonline.net
host-195_87_69_26-koc.net
host-200-75-132-202.cliente_202_net-uno.net
host85_14_64_224.galileusz.3s.pl
host_169_253.compower.pl
host_88-hra.susice-net.cz
igld-83_130_117_32.inter.net.il
igld-83_130_130_243.inter.net.il
igld-83_130_141_197.inter.net.il
ip_167_68.omni-tech.net
ip_199.directservices.com
maroochydore_client185.hypermax.net.au
neterra139_250.neterra.net
nev_dial_11.stv.ru
p165_223.knu.ac.kr
pc_163_209.smrw.lodz.pl
pool_245224-151.etb.net.co
potter_313.caasdphb.brown.edu
price3_highspeed-109.preciscom.com
ras56_196.un.vsnl.net.in
red_200.32.64_customer_7.static.impsat.net.ve
red_200.41.118_cust_17.static.impsat.net.ve
sistemas__s21278-010__slv-son-001.man.newskies.net
slerpool4_69121-134.etb.net.co
slerpool5_69122-26.007mundo.com
slerpool8_93159-211.etb.net.co
sp.200_155_13_3.8x.com.br
sp.200_155_9_57.datacenter1.com.br
sp_200_219_192_94.datacenter1.com.br
st00_162.dorm.depaul.edu
sun_b035.doggy.com.au
tnt_norman_int493149-194.etb.net.co
tnt_pool_11979-199.etb.net.co
tntcuisdnixd_169106-123.007mundo.com
tntmuzuixd_169105-36.etb.net.co
tv_cable_bmga7546-72.etb.net.co
ubr2-5_38.onvol.net
user_155_208.kutztown.edu
wks_177_10.dom_bci_prod.cl
ws_541a.ff.uni-lj.si

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.htmljoin us!

Re: Underscores in host names

[Jay R. Ashworth]

On Wed, May 18, 2005 at 11:08:03AM +1000, Mark Andrews wrote:
> In article <[EMAIL PROTECTED]> you write:
> >Hello all.
> >We have a client containing an underscore in the email address domain
> >name.  Our email server rejects it because of it's violation of the RFC
> >standard.  This individuals claim is that he doesn't have problems
> >anywhere else and if this is going to be a problem he's "going to take
> >his business elsewhere"!
> >
> >I understand it's a violation of the standard, but does it pose a
> >security hole to the email server to allow this sort of mail?
> 
>   RFC 952 and RFC 1123 describe what is currently legal
>   in hostnames.
> 
>   Underscore is NOT a legal character in a hostname.
> 
>   Before anyone says that domain names allow underscore which
>   they do.
> 
>   RFC 1034 Section 3.3
> 
> For hosts, the mapping depends on the existing syntax for host names
> which is a subset of the usual text representation for domain names,  
> together with RR formats for describing host addresses, etc.  Because we
> need a reliable inverse mapping from address to host name, a special
> mapping for addresses into the IN-ADDR.ARPA domain is also defined.
> 
>   Mail domains follow the same rules as for hostnames.  RFC
>   821 and its replacement RFC 2821 havn't extended the syntax
>   to include underscores.

Those with long memories will remember when Apple got strict on this
years ago, and lots of websites became unreachable to their users...

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: Underscores in host names

[Mark Andrews]

One should note that COM and other tld's stopped giving out
domains outside of LDH to prevent these sorts of interoperability
issues.  COM actually retrieved the ones they had delegated.

Re: Underscores in host names

[Valdis . Kletnieks]

In article <[EMAIL PROTECTED]> you write:
>Hello all.
>We have a client containing an underscore in the email address domain
>name.  Our email server rejects it because of it's violation of the RFC
>standard.  This individuals claim is that he doesn't have problems
>anywhere else and if this is going to be a problem he's "going to take
>his business elsewhere"!
>
>I understand it's a violation of the standard, but does it pose a
>security hole to the email server to allow this sort of mail?

No *security* hole as such, other than you need to make sure that if you're
going to accept such cruft, you make *damned* sure that you never leak it
back out and have some *other* standard-conformant site get on *your* case
about it

Oh, and make sure that none of *your* automated tools that summarize maillogs
and the like choke on it. And that your e-mail admin is using software that
doesn't choke on it (otherwise if they send you e-mail, you can't reply.. ;)

You may want to balance the costs of making sure that *all* your stuff is
underscore-ready  (don't forget ongoing maintenance costs, as you'll probably
have to re-patch each new release of any tools) against what this customer is
willing to pay you.



pgp52u6Q4SjVH.pgp
Description: PGP signature

Re: Underscores in host names

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>Hello all.
>We have a client containing an underscore in the email address domain
>name.  Our email server rejects it because of it's violation of the RFC
>standard.  This individuals claim is that he doesn't have problems
>anywhere else and if this is going to be a problem he's "going to take
>his business elsewhere"!
>
>I understand it's a violation of the standard, but does it pose a
>security hole to the email server to allow this sort of mail?
>
>Thanks
>

RFC 952 and RFC 1123 describe what is currently legal
in hostnames.

Underscore is NOT a legal character in a hostname.

Before anyone says that domain names allow underscore which
they do.

RFC 1034 Section 3.3

For hosts, the mapping depends on the existing syntax for host names
which is a subset of the usual text representation for domain names,  
together with RR formats for describing host addresses, etc.  Because we
need a reliable inverse mapping from address to host name, a special
mapping for addresses into the IN-ADDR.ARPA domain is also defined.

Mail domains follow the same rules as for hostnames.  RFC
821 and its replacement RFC 2821 havn't extended the syntax
to include underscores.

Mark