这里给出的大多数答案都是错误的。这是完全合法的 域名中的下划线。让我引用标准，RFC 2181，第11节，“名称语法”:

DNS本身对特定的标签只有一个限制 可用于标识资源记录。那一个 限制涉及到标签的长度和完整 的名字。[…DNS协议的实现不能放置任何 对可使用标签的限制。特别是DNS 服务器不能因为一个区域包含标签而拒绝提供服务 这对于某些DNS客户端程序来说可能是不可接受的。

请参见原始DNS规范，RFC 1034，第3.5节 "首选名称语法"但请仔细阅读。

带下划线的域在野外非常常见。检查_jabber._tcp.gmail.com或_sip._udp.apnic.net。

这里提到的其他RFC处理不同的事情。最初的 问题是关于域名的。如果问题是关于主持人的 名称(或者对于包含主机名的url)，则为 不同的是，相关的标准是RFC 1123，章节2.1“主机 名称和数字”，将主机名限制为 letters-digits-hyphen。

不，你不能在子域中使用下划线，只能在连字符(破折号)中使用。例如，my-subdomain.agahost.com是可以接受的，my_subdomain.agahost.com是不可以接受的。

澄清bortzmeyer和David Tonhofer，域名和子域名标签可以包含前导下划线，但没有其他地方。

如David Tonhofer所述，标签是介于句号之间的部分，除了指定服务标签和端口标签以区别于普通标签外，其他部分都应遵循LDH规则。然后，它们必须出现在标签的开头，标签应该是来自服务名称和端口号注册表的“短名称”，端口号不带前导0，或者协议(即。tcp, udp)。这些服务标签进一步限制为15个字符。

RFC2782指定前缀 带下划线的服务记录子域。 RFC6698指定前缀 TLSA证书记录中带下划线的端口号。

与David Tonhofer的回答相反，IDN不允许编码下划线('_' U+005F LOW LINE)或任何其他无效的ASCII字符。

从RFC5890

(. .]两个新的LDH标签子集由 介绍IDNA。这些被称为保留LDH标签(R-LDH 非保留LDH标签(NR-LDH标签)。保留LDH 标签，在其他一些情况下被称为“带标签的域名”，具有 它们在第三和第四个中包含“——”的属性 其他符合LDH标记规则的字符。

Punycode将所有ASCII码点直接编码为ASCII，包括下划线。生成的R-LDH不符合LDH标签规则。例如，Σ_.com将被编码为xn——_-zmb.com，这违反了规则。可能会有一个单应码点，看起来像一个下划线，可以合法编码(可能是'_' U+FF3F fullwidth low line)，但这些类型的码点将被RFC5892在2.3 IgnorableProperties中归类为不允许的非character_code_point。

RACE(另一个提议的IDN编码方案)没有被IETF接受为标准，不应该被使用。

关于术语的注释，有助于Bortzmeyer的回答

人们应该清楚定义。在这里使用:

域名是DNS数据库中资源的标识符 标签是域名中点与点之间的部分 主机名是一种特殊类型的域名，用于标识Internet主机

主机名受RFC 952和RFC 1123的限制

RFC 2181明确了域名和主机名之间的区别:

.．.任何二进制标签都可以有MX记录这一事实并不意味着任何二进制名称都可以用作电子邮件地址的主机部分……

所以主机名中的下划线是不可以的，域名中的下划线是可以的。

在实践中，很可能会看到带有下划线的主机名。正如稳健性原则(robust Principle)所言:“送出的东西要保守，接受的东西要自由。”

关于编码的说明

在21世纪，事实证明，主机名和域名都可能国际化!这意味着在标签包含允许集合之外的字符的情况下求助于编码。

特别是，它允许在主机名中编码_(更新2017-07:这是可疑的，见评论。“_”仍然不能用于主机名。事实上，它甚至不能用于国际化的标签。)

第一个国际化的RFC是2003年3月的RFC 3490，“国际化应用程序中的域名(IDNA)”。今天，我们有:

RFC 5890“IDNA:定义和文档框架” RFC 5891“IDNA:协议” RFC 5892“统一码位和IDNA” RFC 5893“IDNA的从右向左脚本” RFC 5894《IDNA:背景、解释和基本原理》 RFC 5895“IDNA 2008的映射字符”

你可能还想查看维基百科词条

RFC 5890为主机名中使用的标签引入了术语LDH(字母-数字-连字符)标签，并表示:

这是在主机名中使用的经典标签形式，尽管有一些额外的限制(RFC 952)。它的语法与RFC 1123修改的RFC 1034章节3.5中描述的“首选名称语法”相同。简单地说，它是一个由ASCII字母、数字和连字符组成的字符串，进一步的限制是连字符不能出现在字符串的开头或结尾。与所有DNS标签一样，它的总长度不能超过63个字节。

回到更简单的时代，这个Internet草案是主机名国际化的早期建议。带有国际字符的主机名可以使用，例如，'RACE'编码进行编码。

“RACE编码”提案的作者指出:

According to RFC 1035, host parts must be case-insensitive, start and end with a letter or digit, and contain only letters, digits, and the hyphen character ("-"). This, of course, excludes any internationalized characters, as well as many other characters in the ASCII character repertoire. Further, domain name parts must be 63 octets or shorter in length.... All post-converted name parts that contain internationalized characters begin with the string "bq--". (...) The string "bq--" was chosen because it is extremely unlikely to exist in host parts before this specification was produced.

以下是我在Java世界的2点看法:

在Spark Scala控制台，使用Java 8:

scala> new java.net.URI("spark://spark_master").getHost
res10: String = null

scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master

scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null

scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr

scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr

scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null

这绝对是个坏主意^^

不管主机名和域名的讨论如何，在url的主机部分使用下划线肯定是一个非常糟糕的主意。它会给你带来悲伤。它可能在浏览器中很好地工作，但在最近的一个案例中，我遇到了一个应用程序拒绝使用*.s3的完全有效的通配符证书建立tls连接。Amazonaws.com，因为通配符主机名部分有一个下划线，并且不生效。我相信底层库使用了openssl。