Re: Underscores in host names
In article <1116377042.592906.137650@g44g2000cwa.googlegroups.com> 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
In article <1116377042.592906.137650@g44g2000cwa.googlegroups.com> 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.
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.
On Wed, May 18, 2005 at 11:08:03AM +1000, Mark Andrews wrote:
In article <1116377042.592906.137650@g44g2000cwa.googlegroups.com> 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 jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The 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
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_peni0000.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.ppppun.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.html join us!
On Wed, May 18, 2005 at 12:11:14AM -0400, Steven Champeon <schampeo@hesketh.com> 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
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.
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 <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
In article <Pine.LNX.4.60.0505180849230.24969@hermes-1.csi.cam.ac.uk> 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
On Thu, 19 May 2005, Mark Andrews wrote:
In article <Pine.LNX.4.60.0505180849230.24969@hermes-1.csi.cam.ac.uk> 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 "postmaster@tv", 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 "postmaster@.tv" or "postmaster@tv." 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 william@elan.net
<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 "postmaster@.tv" or "postmaster@tv."
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 ----------------------------------------------------
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 william@elan.net
In article <1226.24.5.40.13.1116478035.davidu@everydns.net> 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 "postmaster@.tv" or "postmaster@tv."
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
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, <brad@stop.mail-abuse.org> "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.
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 jra@baylink.com Designer Internetworking RFC 2100 Ashworth & Associates Best Practices '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
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 jra@baylink.com Designer Internetworking RFC 2100 Ashworth & Associates Best Practices '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
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, <brad@stop.mail-abuse.org> "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.
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 "fred@gw" 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, <brad@stop.mail-abuse.org> "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.
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 "fred@gw" 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 <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
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: Mark_Andrews@isc.org
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 <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
On Wed, May 18, 2005 at 11:05:56AM +0100, Tony Finch <dot@dotat.at> 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.
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".
As a result of my late night rant (must learn not to read email late at night after getting off an airplane), I have received input that two applications that have issues with the "_" character: 1) Squid/Squid proxy from two people (although there wasn't any indication of the actual issue, presumably Squid won't be able to contact the host to cache the content?) 2) "Create a cert for a host with an _ in the name, install said cert into apache/mod_ssl, try to surf (at least using IE) to that server." -- Matthew Christopher This is useful information and can help the original requester make the business decision as to whether or not he will relax his restriction against "_" in the character string that he'll allow his customer to use in data sent to/received from domain name servers he controls. I suspect the rest of the jihad against heathen characters such as "_" should probably be redirected to namedroppers so I won't comment further. Rgds, -drc On May 18, 2005, at 2:15 AM, Mark Andrews wrote:
A hostname is not a domainname. It's all through RFC's 1033, RFC 1034 and RFC 1035. There are references that make it clear that a domain name is not the same as a hostname.
I quoted one of them. I can find other references.
Proctor&Gamble.com anyone? That is the logical concusion of saying hostnames are arbitary 8 bit strings.
The whole reason for check-names was because of very seriously broken software that would allow shell meta-characters in in-addr.arpa labels to do bad things. I have come to the opinion that if such software still exists, then the people who run that software deserve what they get. Check-names was a bad idea that might have been justified at the time, but pretending it remains justified by 952/1123 has got to stop sometime.
We tried hard to kill check-names. The only reason it still exists is that people wouldn't move from BIND 8 without it.
I havn't run with "check-names answer" enabled in years.
However, that rant was mostly irrelevant. Can you point to _ANY_ application, operating system, or anything else that has any issues whatsoever with an "_" of all characters?
The original query was about a OS / application that had problems with underscores.
The point of RFC's is to promote interoperability. People who attempt to name there machines with underscores either don't know better or don't care about interoperability or both.
The simplest way to fix this is for application that configure hostnames, real or virtual, to reject by default illegal hostnames. Apache should not allow virtual sites with illegal hostnames without explicit overrides. Similarly for your favourite MTA, DNS server etc. If people want to use them they need to know they are stepping out of the area where interoperability should occur.
Note: SRV and Active Directory *both* depend on underscore not being legal in hostnames to keep their names spaces seperate from the hostname namespace.
Half the anti-spam/DNS schemes depend upon underscore not being legal in a hostname.
Mark
Rgds, -drc
On May 17, 2005, at 6:08 PM, Mark Andrews wrote:
RFC 952 and RFC 1123 describe what is currently legal in hostnames.
Underscore is NOT a legal character in a hostname.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
There IS a patch available to "fix" the issue in squid which refuses to pass/cache data from websites/domains with "_" in their name. I'll also note that bind 4.9.4 also has issues with underscores in host/domain names. David Conrad <david.conrad@nominum.com> Sent by: owner-nanog@merit.edu 05/18/2005 12:35 PM To Mark Andrews <Mark_Andrews@isc.org> cc nanog@merit.edu Subject Re: Underscores in host names As a result of my late night rant (must learn not to read email late at night after getting off an airplane), I have received input that two applications that have issues with the "_" character: 1) Squid/Squid proxy from two people (although there wasn't any indication of the actual issue, presumably Squid won't be able to contact the host to cache the content?) 2) "Create a cert for a host with an _ in the name, install said cert into apache/mod_ssl, try to surf (at least using IE) to that server." -- Matthew Christopher This is useful information and can help the original requester make the business decision as to whether or not he will relax his restriction against "_" in the character string that he'll allow his customer to use in data sent to/received from domain name servers he controls. I suspect the rest of the jihad against heathen characters such as "_" should probably be redirected to namedroppers so I won't comment further. Rgds, -drc On May 18, 2005, at 2:15 AM, Mark Andrews wrote:
A hostname is not a domainname. It's all through RFC's 1033, RFC 1034 and RFC 1035. There are references that make it clear that a domain name is not the same as a hostname.
I quoted one of them. I can find other references.
Proctor&Gamble.com anyone? That is the logical concusion of saying hostnames are arbitary 8 bit strings.
The whole reason for check-names was because of very seriously broken software that would allow shell meta-characters in in-addr.arpa labels to do bad things. I have come to the opinion that if such software still exists, then the people who run that software deserve what they get. Check-names was a bad idea that might have been justified at the time, but pretending it remains justified by 952/1123 has got to stop sometime.
We tried hard to kill check-names. The only reason it still exists is that people wouldn't move from BIND 8 without it.
I havn't run with "check-names answer" enabled in years.
However, that rant was mostly irrelevant. Can you point to _ANY_ application, operating system, or anything else that has any issues whatsoever with an "_" of all characters?
The original query was about a OS / application that had problems with underscores.
The point of RFC's is to promote interoperability. People who attempt to name there machines with underscores either don't know better or don't care about interoperability or both.
The simplest way to fix this is for application that configure hostnames, real or virtual, to reject by default illegal hostnames. Apache should not allow virtual sites with illegal hostnames without explicit overrides. Similarly for your favourite MTA, DNS server etc. If people want to use them they need to know they are stepping out of the area where interoperability should occur.
Note: SRV and Active Directory *both* depend on underscore not being legal in hostnames to keep their names spaces seperate from the hostname namespace.
Half the anti-spam/DNS schemes depend upon underscore not being legal in a hostname.
Mark
Rgds, -drc
On May 17, 2005, at 6:08 PM, Mark Andrews wrote:
RFC 952 and RFC 1123 describe what is currently legal in hostnames.
Underscore is NOT a legal character in a hostname.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
David Conrad wrote:
1) Squid/Squid proxy from two people (although there wasn't any indication of the actual issue, presumably Squid won't be able to contact the host to cache the content?)
the resolver library barfs up an error
I suspect the rest of the jihad against heathen characters such as "_" should probably be redirected to namedroppers so I won't comment further.
Not unless namedroppers is authoritative for /etc/hosts now too. That's the whole point here--DNS may be more powerful than what the hostname syntax rules allow, but the mere existence of that capability has zero bearing on the canonocial syntax rules. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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.
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
(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
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
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. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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, <brad@stop.mail-abuse.org> "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.
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
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
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. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Wed, 18 May 2005 21:51:32 -0000, 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. ;)
participants (17)
-
bmanning＠vacation.karoshi.com -
Brad Knowles -
David A. Ulevitch -
David Conrad -
Duane Wessels -
Eric A. Hall -
Jay R. Ashworth -
Laurent Frigault -
Mark Andrews -
Michael.Dillon＠radianz.com -
Paul Vixie -
Stephane Bortzmeyer -
Steven Champeon -
Tony Finch -
trainier＠kalsec.com -
Valdis.Kletnieks＠vt.edu -
william(at)elan.net