dns - subdomains - Los subdominios can(domain name) tienen un guión bajo "_" en él?
subdomain traductor (6)
Una nota sobre la terminología, en apoyo de la respuesta de Bortzmeier
Uno debe tener claro las definiciones. Como se usa aquí:
- nombre de dominio es el identificador de un recurso en una base de datos DNS
- etiqueta es la parte de un nombre de dominio entre puntos
- nombre de host es un tipo especial de nombre de dominio que identifica los hosts de Internet
El nombre de host está sujeto a las restricciones de RFC 952 y la ligera relajación de RFC 1123
RFC 2181 deja en claro que hay una diferencia entre un nombre de dominio y un nombre de host:
... [el hecho de] que cualquier etiqueta binaria pueda tener un registro MX no implica que se pueda usar ningún nombre binario como parte del host de una dirección de correo electrónico ...
Por lo tanto, los guiones bajos en los nombres de host son un no-no, los subrayados en los nombres de dominio son a-ok.
En la práctica, uno puede ver nombres de host con guiones bajos. Como dice el Principio de robustez : "Sé conservador en lo que envías, liberal en lo que aceptas".
Una nota sobre la codificación
¡En el siglo XXI, resulta que los nombres de host y los nombres de dominio pueden estar internacionalizados! Esto significa recurrir a codificaciones en el caso de etiquetas que contienen caracteres que están fuera del conjunto permitido.
En particular, permite codificar _ en nombres de host (Actualización 2017-07: Esto es dudoso, vea comentarios. _ Aún no se puede usar en nombres de host. De hecho, ni siquiera se puede usar en etiquetas internacionalizadas).
El primer RFC para la internacionalización fue RFC 3490 de marzo de 2003, "Internacionalización de nombres de dominio en aplicaciones (IDNA)". Hoy tenemos:
- RFC 5890 "IDNA: Definiciones y Marco del documento"
- RFC 5891 "IDNA: Protocolo"
- RFC 5892 "Los puntos de código Unicode y IDNA"
- RFC 5893 "Guiones de derecha a izquierda para IDNA"
- RFC 5894 "IDNA: antecedentes, explicación y justificación"
- RFC 5895 " Capas de mapeo para IDNA 2008"
También es posible que desee comprobar la entrada de Wikipedia
RFC 5890 introduce el término etiqueta LDH (Letter-Digit-Hypen) para etiquetas utilizadas en nombres de host y dice:
Esta es la forma de etiqueta clásica utilizada, aunque con algunas restricciones adicionales, en nombres de host (RFC 952). Su sintaxis es idéntica a la descrita como la "sintaxis de nombre preferido" en la Sección 3.5 de RFC 1034 modificada por RFC 1123. Brevemente, es una cadena que consiste en letras ASCII, dígitos y el guión con la restricción adicional de que el guión no puede aparecer al principio o al final de la cadena. Como todas las etiquetas DNS, su longitud total no debe exceder los 63 octetos.
Volviendo a épocas más simples, este borrador de Internet es una propuesta temprana para la internacionalización del nombre de host . Los nombres de host con caracteres internacionales se pueden codificar usando, por ejemplo, la codificación ''RACE'' .
El autor de la propuesta de ''codificación RACE'' observa:
De acuerdo con RFC 1035, las partes del host no deben distinguir entre mayúsculas y minúsculas, comienzan y terminan con una letra o un dígito, y contienen solo letras, dígitos y el carácter de guión ("-"). Esto, por supuesto, excluye cualquier personaje internacionalizado, así como muchos otros personajes en el repertorio de caracteres ASCII. Además, las partes del nombre de dominio deben ser de 63 octetos o más cortas de longitud ... Todas las partes de nombres post-convertidos que contienen caracteres internacionalizados comienzan con la cadena "bq--". (...) Se eligió la cadena "bq--" porque es extremadamente improbable que exista en partes del host antes de que se produzca esta especificación.
¿Pueden los subdominios (nombres de dominio) subrayar _ en ellos?
Aclarando bortzmeyer y David Tonhofer , las etiquetas de nombre de dominio y subdominio pueden contener guiones bajos destacados, pero en ningún otro lado.
Como escribió David Tonhofer , las etiquetas son las partes entre periodos y deben seguir la regla LDH excepto cuando se especifican las etiquetas de servicio y las etiquetas de puerto para diferenciarlas de las etiquetas normales. Luego deben aparecer al principio de la etiqueta, que deben ser los "Nombres cortos" del Registro del nombre del servicio y del número de puerto , el número de puerto sin 0 iniciales o el protocolo (es decir, tcp, udp). Estas etiquetas de servicio están limitadas a 15 caracteres.
- RFC2782 especifica el prefijo de subdominios de registro de servicio con guiones bajos.
- RFC6698 especifica el prefijo de los números de puerto con guiones bajos en los registros de certificados de TLSA.
Contrariamente a la respuesta de David Tonhofer , IDN no permite la codificación del guión bajo (''_'' U + 005F LOW LINE) o cualquier otro carácter ASCII no válido.
De RFC5890
[...] dos nuevos subconjuntos de etiquetas de LDH se crean con la introducción de IDNA. Estas se denominan etiquetas de LDH reservadas (etiquetas de R-LDH) y etiquetas de LDH no reservadas (etiquetas de NR-LDH). Las etiquetas de LDH reservadas, conocidas como "nombres de dominio etiquetados" en algunos otros contextos, tienen la propiedad de que contienen "-" en los caracteres tercero y cuarto, pero que de otro modo se ajustan a las reglas de etiqueta de LDH .
Punycode codifica todos los puntos de código ASCII como ASCII directamente, incluyendo subrayado. El R-LDH resultante no cumpliría las reglas de la etiqueta LDH. Por ejemplo, Σ_.com se codificaría como xn--_-zmb.com que infringe las reglas. Puede haber un punto de código homográfico que se parece a un guión bajo que puede codificarse legalmente (tal vez ''_'' línea máxima U + FF3F de bajo ancho), pero estos tipos de puntos de código se clasificarían como NO ADJUDICADOS por RFC5892 en 2.3 IgnorableProperties como Noncharacter_Code_Point.
RACE (el otro esquema de codificación de IDN propuesto) no fue aceptado como estándar por IETF y no debe ser utilizado.
Aquí mis 2 centavos del mundo de Java:
Desde una consola Spark Scala, con 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 es una mala idea ^^
Hay una cosa adicional que puede necesitar saber: si el host o la parte del subdominio de la url contiene un guión bajo, IE9 (no ha probado otras versiones) no puede escribir cookies.
Así que ten cuidado con eso. :-)
La mayoría de las respuestas dadas aquí son falsas . Es perfectamente legal tener un guión bajo en un nombre de dominio. Permítanme citar el estándar, RFC 2181, sección 11, "Sintaxis de nombre" :
El DNS coloca solo una restricción en las etiquetas particulares que se pueden usar para identificar registros de recursos. Esa restricción se relaciona con la longitud de la etiqueta y el nombre completo. [...] Las implementaciones de los protocolos DNS no deben imponer ninguna restricción a las etiquetas que se pueden usar. En particular, los servidores DNS no deben negarse a servir una zona porque contiene etiquetas que podrían no ser aceptables para algunos programas cliente DNS.
Consulte también la especificación DNS original, RFC 1034 , sección 3.5 "Sintaxis del nombre preferido", pero léala detenidamente.
Los dominios con guiones bajos son muy comunes en la naturaleza. Compruebe _jabber._tcp.gmail.com o _sip._udp.apnic.net .
Otros RFC mencionados aquí se ocupan de diferentes cosas. La pregunta original era para nombres de dominio . Si la pregunta es para nombres de host (o URL, que incluyen un nombre de host), esto es diferente, el estándar relevante es RFC 1123 , sección 2.1 "Nombres y números de host " que limita los nombres de host a letras-dígitos-guión.
Seguí el enlace a RFC1034 y leí la mayor parte y me sorprendió ver esto:
Las etiquetas deben seguir las reglas para los nombres de host ARPANET. Deben comenzar con una letra, terminar con una letra o un dígito y tener como caracteres interiores solo letras, dígitos y guiones. También hay algunas restricciones en la longitud. Las etiquetas deben tener 63 caracteres o menos.
A modo de aclaración, los nombres de dominio están formados por etiquetas que están separadas por puntos ".". Esta especificación debe estar desactualizada porque no menciona el uso de guiones bajos. Puedo entender la confusión si alguien tropieza con esta especificación sin saber que está obsoleta. Está obsoleto, ¿no?
Seguí el enlace a RFC2181 y leí algo de eso. Especialmente en lo que respecta a la cuestión de qué es un nombre autorizado o canónico, y la cuestión de qué hace una etiqueta DNS válida.
Como se publicó anteriormente, indica que solo hay una restricción de longitud y luego, para resumir, se lee:
(sobre nombres y etiquetas válidas)
Estos ya están adecuadamente especificados, sin embargo, las especificaciones parecen a veces ser ignoradas. Buscamos reforzar las especificaciones existentes.
Me deja pensando si "una restricción de longitud solamente" es "adecuada". ¿Vamos a comenzar a ver nombres de dominio como @ # $% !! ¿pronto? ¿Internet no está tan mal?