RFC 2181在1997年开放了DNS名称中的可接受字符。但是人们似乎仍然对在主机名中使用下划线感到忧心忡忡。 （例如，GoDaddy不会出售带有下划线的二级域名，如“this_bites.com”）
在几分钟的testing中，包含下划线的第三级主机名称对我的办公室中的所有内容都“正常工作”。 （例如，that_guy.example.com，我的DNS主机是Amazon Route 53）
它在Win XP和Win 7，Mac OSX 10.7，IE8和9，现代的Firefox，Safari和Chrome上“仅仅工作”。
我在哪里可以期待它不工作？
（为什么我要关心？我正在给学生分配虚拟机，我想使用他们在主机名中select的用户ID来提醒他们，他们在盒子上的行为是直接归因于他们的。不幸的是，很大一部分预先存在的学生用户ID包含下划线。）
为了清楚起见，DNS从一开始就一直被允许使用下划线。 RFC 1034有这样的标签语法的说法：
3.5。 首选名称语法
DNS规范试图尽可能通用于构build域名的规则。 这个想法是，任何现有的对象的名称可以表示为一个域名，只需要很less的变化。 但是，在为对象分配域名时，谨慎的用户将select既满足域系统规则又满足对象任何现有规则的名称，无论这些规则是已发布的还是已有的程序隐含的。
这意味着：如果您将主机名放在DNS中，请将自己限制为主机名的规则。 如果你把邮件域，限制自己的RFC 822规则如果你把DKIM或ENUMlogging在DNS（这不是主机名），限制自己的语法这些协议。 如果你把其他的东西，请按照适当的语法。 但是DNS本身不会限制你。
RFC 1034继续对指定不带下划线的标签的语法进行保护。 但这只是一个build议。 它说“以下语法将导致更less的问题”。
所以肯定GoDaddy是否否认“this_bites.com”是错误的。 即使在主机名称中明确禁止使用下划线，也可能需要使用代表主机名称之外的DNS名称来填充此域名。 DNS注册服务商和域名服务提供商不应该禁止！
接下来的问题是，实际主机名是否允许使用下划线？
RFC 1034对主机名称说“应遵循HOSTS.TXT的旧规则”。 但是，如果RFC1034写的HOSTS.TXT的规则是旧的，那么现在是古代的历史！ RFC 1034的写法是当用户名通常不能超过8个字符，而且所有内容都是ASCII。 世界已经改变。
我会说，没有一组规则定义什么是有效的主机名。 这取决于使用的软件支持哪些字符，这些字符可能是系统用来指定自己和同伴的主机名称的一部分。 我所说的“软件”是指所有以某种方式处理主机名的软件，从操作系统到networking监视代理以及其间的所有内容。
如果你有理由相信你的环境中没有任何东西会阻塞一个包含下划线的主机名（现在我认为这是一个很好的假设），那么我认为你可以安全地使用它们。
如果有什么东西阻止你在主机名中使用下划线，但是，它不是DNS，从来没有。
Android和Java似乎在域中有下划线的问题。 特别是Java中的URI类将无法正确parsingURI，并抛出UnknownHostExceptions。
RFC2181只是澄清了同样的规则（从来没有DNS本身，不允许下划线）。
关于主机名的限制因素具体是互联网主机名的定义，RFC2181并没有改变。
为了兼容性，我认为推荐下面的主机名Internet主机名规则（基本上是DNS规范中的build议）是有意义的，而其他types的名称将有不同的规则。
至于注册pipe理机构或者个人注册服务商是否应该对域名施加互联网主机名规则是有争议的。
绝大多数注册人将使用他们的域名作为主机名称，在这方面，这样的规则在某种程度上是有道理的，但是从DNS纯粹的angular度来看，没有理由有这样的规则。