Os subdomínios (nome de domínio) podem ter um sublinhado "_"?

Os subdomínios (nomes de domínio) podem ter sublinhado _neles?

A maioria das respostas dadas aqui são falsas . É perfeitamente legal ter um sublinhado em um nome de domínio. Deixe-me citar o padrão, RFC 2181, seção 11, "Sintaxe de nome" :

O próprio DNS coloca apenas uma restrição nos rótulos específicos que podem ser usados ​​para identificar registros de recursos. Essa restrição está relacionada ao comprimento do rótulo e ao nome completo. [...] As implementações dos protocolos DNS não devem colocar restrições nos rótulos que podem ser usados. Em particular, os servidores DNS não devem se recusar a atender a uma zona, pois ela contém rótulos que podem não ser aceitáveis ​​para alguns programas clientes DNS.

Consulte também a especificação DNS original, RFC 1034 , seção 3.5 "Sintaxe de nome preferencial", mas leia-a com atenção.

Domínios com sublinhados são muito comuns na natureza. Marque _jabber._tcp.gmail.comou _sip._udp.apnic.net.

Outras RFC mencionadas aqui lidam com coisas diferentes. A pergunta original era para nomes de domínio . Se a pergunta for para nomes de host (ou URLs, que incluem um nome de host), então isso é diferente, o padrão relevante é a RFC 1123 , seção 2.1 "Nomes e números de host ", que limita os nomes de host a letras-dígitos-hífen.

Uma nota sobre terminologia, em apoio à resposta de Bortzmeyer

Deve-se ter clareza sobre as definições. Como usado aqui:

• nome de domínio é o identificador de um recurso em um banco de dados DNS
• label é a parte de um nome de domínio entre pontos
• hostname é um tipo especial de nome de domínio que identifica hosts da Internet

O nome do host está sujeito às restrições da RFC 952 e ao leve relaxamento da RFC 1123

O RFC 2181 deixa claro que há uma diferença entre um nome de domínio e um nome de host:

... [o fato de] qualquer rótulo binário poder ter um registro MX não implica que qualquer nome binário possa ser usado como parte do host de um endereço de email ...

Portanto, sublinhados em nomes de host são um não-não, sublinhados em nomes de domínio são ok.

Na prática, é possível ver nomes de host com sublinhados. Como o Princípio da robustez diz: "Seja conservador no que envia, liberal no que aceita".

Uma observação sobre codificação

No século 21, acontece que nomes de host e nomes de domínio podem ser internacionalizados! Isso significa recorrer a codificações no caso de etiquetas que contenham caracteres que estão fora do conjunto permitido.

Em particular, ela permite codificar o _em nomes de host (Atualização 2017-07:. Este é duvidosa, ver os comentários A _.. Ainda não pode ser usado em nomes de host Na verdade, ele não pode ser usado até mesmo em rótulos internacionalizados)

A primeira RFC para internacionalização foi a RFC 3490 de março de 2003, "Internacionalizando nomes de domínio em aplicativos (IDNA)". Hoje nós temos:

• RFC 5890 "IDNA: Definições e Estrutura de Documentos"
• RFC 5891 "IDNA: Protocolo"
• RFC 5892 "Os pontos de código Unicode e IDNA"
• RFC 5893 "Scripts da direita para a esquerda para IDNA"
• RFC 5894 "IDNA: Antecedentes, Explicação e Justificativa"
• RFC 5895 "Caracteres de mapeamento para o IDNA 2008"

Você também pode verificar a entrada da Wikipedia

A RFC 5890 introduz o termo rótulo LDH (Letter-Digit-Hypen) para rótulos usados ​​em nomes de host e diz:

Essa é a forma clássica de etiqueta usada, embora com algumas restrições adicionais, nos nomes de host (RFC 952). Sua sintaxe é idêntica à descrita como a "sintaxe do nome preferido" na Seção 3.5 da RFC 1034, modificada pela RFC 1123. Resumidamente, é uma string que consiste em letras, dígitos e hífen ASCII, com a restrição adicional de que o hífen não pode aparecem no início ou no final da string. Como todos os rótulos de DNS, seu comprimento total não deve exceder 63 octetos.

Voltando aos tempos mais simples, este projecto de Internet é uma proposta cedo para hostname internacionalização. Nomes de host com caracteres internacionais podem ser codificados usando, por exemplo, a codificação 'RACE' .

O autor da proposta 'codificação RACE' observa:

De acordo com a RFC 1035, as partes do host devem diferenciar maiúsculas de minúsculas, iniciar e terminar com uma letra ou dígito e conter apenas letras, dígitos e o caractere hífen ("-"). Isso, é claro, exclui caracteres internacionalizados, bem como muitos outros caracteres no repertório de caracteres ASCII. Além disso, as partes de nomes de domínio devem ter 63 octetos ou menos. Todas as partes de nomes pós-convertidas que contêm caracteres internacionalizados começam com a cadeia "bq--". (...) A string "bq--" foi escolhida porque é extremamente improvável que exista nas partes do host antes que essa especificação seja produzida.

Há uma coisa adicional que você precisa saber: se a parte do host ou subdomínio da URL contiver um sublinhado, o IE9 (não testou outras versões) não poderá escrever cookies.

Portanto, tenha cuidado com isso. :-)

O esclarecimento de bortzmeyer e David Tonhofer , rótulos de nome de domínio e nome de subdomínio pode conter sublinhados principais, mas em nenhum outro lugar.

Como escreveu David Tonhofer , os rótulos são as partes entre os períodos e devem seguir a regra LDH, exceto ao especificar rótulos de serviço e rótulos de portas para diferenciá-los dos rótulos regulares. Em seguida, eles devem ocorrer no início do rótulo, que deve ser o "Nomes abreviados" do Registro de nome e número de porta do serviço , o número da porta sem 0s iniciais ou o protocolo (por exemplo, tcp, udp). Essas etiquetas de serviço estão ainda mais limitadas a 15 caracteres.

• RFC2782 especifica prefixo de subdomínios de registro de serviço com sublinhados.
• RFC6698 especifica prefixo de números de porta com sublinhados nos registros de certificado TLSA.

Ao contrário da resposta de David Tonhofer , o IDN não permite a codificação de sublinhado ('_' U + 005F LOW LINE) ou qualquer outro caractere ASCII inválido.

From RFC5890

[..] dois novos subconjuntos de rótulos LDH são criados pela introdução do IDNA. Eles são chamados de rótulos LDH reservados (rótulos R-LDH) e rótulos LDH não reservados (rótulos NR-LDH). Os rótulos LDH reservados, conhecidos como "nomes de domínio marcados" em alguns outros contextos, têm a propriedade que eles contêm "-" no terceiro e quarto caracteres, mas que, de outra forma, estão em conformidade com as regras de rótulo LDH .

O Punycode codifica todos os pontos de código ASCII como ASCII diretamente, incluindo sublinhado. O R-LDH resultante não está em conformidade com as regras do rótulo LDH. Por exemplo, Σ_.comseria codificado como o xn--_-zmb.comque viola as regras. Pode haver um ponto de código homográfico que se parece com um sublinhado que pode ser codificado legalmente (talvez a linha baixa de largura total U + FF3F), mas esses tipos de pontos de código seriam categorizados como DISALLOWED by RFC5892 em 2.3 IgnorableProperties como Noncharacter_Code_Point.

O RACE (o outro esquema de codificação IDN proposto) não foi aceito como padrão pelo IETF e não deve ser usado.

Eu segui o link para RFC1034 e li a maioria e fiquei surpreso ao ver isso:

Os rótulos devem seguir as regras para os nomes de host da ARPANET. Eles devem começar com uma letra, terminar com uma letra ou um dígito e ter como caracteres internos apenas letras, dígitos e hífen. Existem também algumas restrições no comprimento. Os rótulos devem ter 63 caracteres ou menos.

Para esclarecimento, os nomes de domínio são compostos de etiquetas separadas por pontos ".". Essa especificação deve estar desatualizada porque não menciona o uso de sublinhados. Eu posso entender a confusão se alguém tropeçar nessa especificação sem saber que ela é obsoleta. É obsoleto, não é?

Eu segui o link para RFC2181 e li alguns deles. Especialmente no que diz respeito à questão do que é um nome autoritário ou canônico e à questão do que torna um rótulo DNS válido.

Como publicado anteriormente, ele afirma que há apenas uma restrição de comprimento e, para resumir, ele lê:

(sobre nomes e rótulos válidos)

Eles já estão especificados adequadamente, no entanto, as especificações parecem às vezes ignoradas. Procuramos reforçar as especificações existentes.

Meio que me deixa pensando se "uma restrição de comprimento único" é "adequada". Vamos começar a ver nomes de domínio como @ # $% !! em breve? A internet não está estragada o suficiente?

Recentemente, o fórum do CAB (*) decidiu que

Todos os certificados contendo um caractere de sublinhado em qualquer entrada dNSName e com um período de validade de mais de 30 dias DEVEM ser revogados antes de 15 de janeiro de 2019. https://cabforum.org/2018/11/12/ballot-sc-12- sunset-of-underscores-in-dnsnames /

Isso significa que você não tem mais permissão para usar sublinhados em domínios que terão um certificado ssl / tls.

(*) O Fórum do navegador da autoridade de certificação (CA / Forum do navegador) é uma reunião voluntária dos principais emissores de certificados (conforme definido na seção 2.1 (a) (1) e (2) abaixo) e fornecedores de software de navegador da Internet e outros aplicativos que use certificados (Consumidores de certificado, conforme definido na Seção 2.1 (a) (3) abaixo).

Os DPNs individuais podem colocar suas próprias regras e restrições nos nomes de domínios, conforme entenderem, como para acomodar os idiomas locais.

Por exemplo, de acordo com o CIRA , os .canomes de domínio do Canadá são permitidos:

• Letras aatravés z, e os seguintes caracteres acentuados: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Observe que os nomes de domínio não diferenciam maiúsculas de minúsculas. Isso significa que não haverá distinção entre maiúsculas e minúsculas ( A= a);

• Os números 0123456789e

• O caractere hífen (" -) (embora não possa ser usado para iniciar ou encerrar um nome de domínio).

O tamanho máximo é de 63 caracteres, exceto que cada caractere acentuado reduz esse limite em 4 caracteres.

( Fonte )

_{Aliás, isso permite cerca de 4 quadragintilhões de possibilidades de nomes de domínio (sem contar subdomínios) para domínios dot-ca.}

Aqui estão meus 2 centavos do mundo Java:

Em um console Spark Scala, com 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

É definitivamente uma má ideia ^^

Acabei de criar projeto local (com vagrant) e estava funcionando perfeitamente quando acessado pelo endereço IP. Em seguida, adicionei some_name.test ao arquivo hosts e tentei acessá-lo dessa maneira, mas estava recebendo "bad request - 400" o tempo todo. Perdi horas até descobrir que apenas mudar o nome do domínio para some-name.test resolve o problema. Portanto, pelo menos localmente no Mac OS, não está funcionando.

Não, você não pode usar sublinhado no subdomínio, mas hífen (traço). ou seja, meu_dominio.agahost.com é aceitável e meu_dominio.agahost.com não seria aceitável.

Não se você quiser resolver na Internet.

Você não pode ter: http://my_subdomain.example.com é inválido.

Você pode ter: http://my-subdomain.example.com com um hífen.