Pode (Nome de domínio) subdomínios ter um underscore "" nele?
os subdomínios (nomes de domínio) podem ter sublinhado {[[0]} neles?
7 answers
A maioria das respostas dadas aqui são falsas. É perfeitamente legal ter um sublinhado num nome de domínio. Deixe-me citar a norma, RFC 2181, section 11, "Name syntax":
O próprio DNS coloca apenas uma restrição nos rótulos específicos. isso pode ser usado para identificar registros de recursos. Aquele. a restrição refere-se ao comprimento do rótulo e à nome. [...] As implementações dos protocolos DNS não devem colocar qualquer restrições à etiquetas que podem ser usadas. Em especial, DNS os servidores não devem recusar-se a servir uma zona porque contém etiquetas isso pode não ser aceitável para alguns programas de clientes DNS.
Ver também a especificação original do DNS, RFC 1034 , secção 3. 5 "Preferred name syntax" but read it carefully.
Domínios com sublinhados são muito comuns na natureza. Verificar _jabber._tcp.gmail.com ou _sip._udp.apnic.net.
Uma nota sobre terminologia, em complemento da resposta de Bortzmeier
As definições devem ser claras. Como se usa aqui:
- o nome de domínio é o identificador de um recurso numa base de dados DNS
- o rótulo é a parte de um nome de domínio entre pontos
- o hostname é um tipo especial de nome de domínio que identifica as máquinas da Internet
O nome da máquina {[12] } está sujeito ao restrições de RFC 952 e o relaxamento ligeiro da RFC 1123
RFC 2181 deixa claro que existe uma diferença entre um nome de domínio e um nome de máquina:
...[the fact that] any binary label can have an MX record does not insinued that any binary name can be used as the host part of an e-mail address...
Os sublinhados em nomes de máquinas são um Não-Não, os sublinhados em nomes de domínio são a-ok.
Em prática, pode-se ver nomes de máquinas com sublinhados. Como diz o princípio da robustez: "seja conservador naquilo que envia, liberal naquilo que aceita".
Uma nota sobre a codificação
No século XXI, acontece que os nomes de hostnames assim como os nomes de domínio podem ser internacionalizados! Isto significa recorrer a codificações no caso de etiquetas que contenham caracteres que estejam fora do conjunto permitido.
Em particular, permite one to encode the_ in hostnames (Update 2017-07: This is doubtful, see comments. O _ ainda não pode ser usado nos nomes das máquinas. Com efeito, nem sequer pode ser utilizado em rótulos internacionais.)
O primeiro RFC para internacionalização foi RFC 3490 de Março de 2003, " internacionalização dos nomes de domínio em aplicações (IDNA)". Hoje, temos:
- RFC 5890 "IDNA: Definitions and Document Framework"
- RFC 5891 " IDNA: Protocolo "
- RFC 5892 "the Unicode Code Points and IDNA"
- RFC 5893 "programas da direita para a esquerda para IDNA"
- RFC 5894 "IDNA: Background, Explanation, and Rationale"
- RFC 5895 "caracteres de mapeamento para IDNA 2008"
Também poderá querer verificar o item da Wikipédia
O RFC 5890 introduz o termo LDH (Letter-Digit-Hypen) label para labels usado em E diz:
Este é o formato de etiqueta clássica usado, embora com algumas restrições adicionais, em nomes de máquinas (RFC 952). Sua sintaxe é idêntica à descrita como a" sintaxe de nome preferido " na seção 3.5 da RFC 1034, modificada pela RFC 1123. Brevemente, é uma cadeia que consiste de letras ASCII, dígitos, e o hífen com a restrição adicional que o hífen não pode aparecer no início ou no fim da cadeia. Como todos os rótulos DNS, o seu comprimento total não deve exceder 63 octetos.
Voltando aos tempos mais simples, este projecto de Internet é uma proposta inicial parahostname internacionalização. Os nomes das máquinas com caracteres internacionais podem ser codificados usando, por exemplo, codificação'RACE' .
O autor da proposta "codificação racial" notas:
De acordo com a RFC 1035, as partes da máquina devem ser insensíveis em caso, Iniciar e terminar com uma letra ou dígito, e conter apenas letras, dígitos, e o personagem hífen (" -"). Isto, é claro, exclui quaisquer personagens internacionalizados, bem como muitos outros personagens no repertório de personagens ASCII. Além disso, as partes de nomes de domínio devem ser 63 octetos ou mais curtos em comprimento.... Todas as partes de nomes pós-convertidos que contêm caracteres internacionalizados começam com a string "bq--". (...) A string "bq--" foi escolhida porque é extremamente improvável existir em partes hospedeiras antes desta especificação ser produzida.
Há uma coisa adicional que você pode precisar saber: se a máquina ou a parte subdominada da url contém um sublinhado, o IE9 (não testou outras versões) não pode escrever cookies.
Tem cuidado com isso. :-)Clarifying bortzmeyer and David Tonhofer , domain name and subdomain name labels can contain leading underscores, but nowhere else.
Como David Tonhofer escreveu, as etiquetas são as partes entre os períodos e devem seguir a regra LDH excepto {[13] } ao especificar as etiquetas de serviço e as etiquetas de porta para as diferenciar das etiquetas regulares. Em seguida, eles devem ocorrer no início do rótulo que deve ser os "nomes curtos" do nome do Serviço e registo do número do Porto, o número do porto sem 0s iniciais, ou o protocolo (ie. tcp, udp). Estas etiquetas de serviço estão ainda limitadas a 15 caracteres.
- RFC2782 especifica o prefixo subdomínios de registo de serviço com sublinhados.
- RFC6698 especifica o prefixo números de Porto com sublinhados nos registos do certificado TLSA.
Ao contrário da resposta de David Tonhofer, a IDN não permite codificar sublinhado ('_'U+005F low LINE) ou qualquer outro carácter ASCII inválido.
De RFC5890
[..] dois novos subconjuntos de rótulos LDH são criados pela introdução de IDNA. Estes são chamados de rótulos LDH reservados (R-LDH) etiquetas) e etiquetas LDH não reservadas (etiquetas NR-LDH). LDH reservado rótulos, 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 outro modo, correspondem a Regras do rótulo LDH.
O Punycode codifica todos os pontos de código ASCII como ASCII directamente, incluindo o sublinhado. O R-LDH resultante não estaria em conformidade com as regras do rótulo LDH. Por exemplo, Σ_.com seria codificado como xn--_-zmb.com o que viola as regras. Pode haver um ponto de código homográfico que se parece com um sublinhado que pode ser codificado legalmente( talvez '＿' U+FF3F fullwidth low line), mas estes tipos de pontos de código seriam categorizados como excluídos por RFC5892 sob 2.3 Ignoráveis como um ponto de não-Caracteres.
RACE (o outro esquema de codificação IDN proposto) não foi aceite como norma pelo IETF e não deve ser utilizado.
Segui a ligação ao RFC1034 e li A maior parte e fiquei surpreendido ao ver isto:
As etiquetas devem seguir as regras para os nomes das máquinas ARPANET. Eles devem começar com uma letra, terminar com uma letra ou dígito, e ter como interior caracteres apenas letras, dígitos e hífen. Há também alguns restrições ao comprimento. As etiquetas devem ser de 63 caracteres ou menos.
Para clarificação, um nome de domínio é composto por etiquetas que são separadas por pontos ".". Esta especificação deve estar desactualizado porque não menciona o uso de sublinhados. Posso entender a confusão se alguém tropeçar nesta especificação sem saber que é obsoleta. É obsoleto, não é?
Segui a ligação ao RFC2181 e li alguns deles. Especialmente quando se trata da questão do que é um nome autoritário, ou canônico, e da questão do que faz um rótulo DNS válido. Como postado anteriormente, diz que só há uma restrição de comprimento e depois resumi-la. lê:(acerca dos nomes e rótulos válidos)
estes já estão adequadamente especificados, no entanto, as especificações parecem ser por vezes ignoradas. Procuramos reforçar as especificações existentes.
Deixa-me a pensar se "uma restrição só de comprimento" é "adequada". Vamos começar a ver nomes de domínio como@#$%!! em breve? A internet não está suficientemente estragada?De uma consola 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
Não pode ter: http://my_subdomain.somedomainname.com é inválido.
Podes ter: http://my-subdomain.somedomainname.com com um hífen.