Re: Underscores in host names
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
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
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
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 http://www.sage.org/ for more info.
Re: Underscores in host names
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 http://www.sage.org/ for more info.
Re: Underscores in host names
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
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 http://www.sage.org/ for more info.
Re: Underscores in host names
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
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
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
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
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
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. ProctorGamble.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
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
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
On Wed, 18 May 2005 19:15:44 +1000, Mark Andrews said: ProctorGamble.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
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
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
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. ProctorGamble.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 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
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
(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
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 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
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 http://www.sage.org/ for more info.
Re: Underscores in host names
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
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
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
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
quote who=william(at)elan.net 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
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
In article [EMAIL PROTECTED] you write: quote who=william(at)elan.net 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
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
Re: Underscores in host names
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
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
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
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!
