La respuesta de @ Sven, con la edición, ya es correcta, pero solo para expresar las cosas directamente.
TL; DR yes subrayado es válido en un CNAME
registro en ambos lados, lea a continuación para saber por qué.
RFC 1034 y otros definen registros basados en "nombres de dominio", que son etiquetas con cualquier carácter, por ejemplo _
.
Pero algunos registros tienen reglas más estrictas para el nombre del propietario y / o los datos de recursos (RDATA). Solo se aceptará un nombre de host y, de hecho, las reglas son ahora (se relajaron en el pasado donde un nombre de host no podía comenzar con un dígito) que puede usar cualquier letra ASCII (sin distinción entre mayúsculas y minúsculas), cualquier dígito ASCII y los guiones , además de algunas reglas de posición adicionales: sin guiones al inicio o al final y sin guiones dobles en las posiciones 3 y 4 (debido a la "reserva" para los IDN que son de la forma xn--
que solo se permite).
Por ejemplo el nombre del propietario de una A
o AAAA
registro es un nombre de host, no un nombre de dominio. Entonces
test.example.com A 192.0.2.1
es válido por qué todos estos no son:
_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1
Es fácil probar cosas con el named-checkzone
programa (parte del bind
software del servidor de nombres pero puede usarse e instalarse por separado y otros servidores de nombres pueden tener herramientas de verificación similares y probablemente también hay interfaces en línea para eso de todos modos), simplemente coloque los registros en un archivo y ejecute en:
$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)
(el número antes del IN
es el TTL, esto no está relacionado con nuestro problema aquí, pero solo se necesita para pasar la validación de sintaxis de un registro).
Para otros registros, es todo lo contrario: NS
no hay restricciones para el propietario, sino restricciones para el "objetivo" que son los datos. Los datos solo pueden ser un nombre de host, no un nombre de dominio, porque debe apuntar a servidores de nombres autorizados que son hosts físicos que responden a las consultas DNS.
Ahora CNAME
, aquí están las citas relevantes de RFC 1034, en la sección 3.6:
"propietario: que es el nombre de dominio donde se encuentra el RR". lo que significa por defecto cualquier nombre, no solo un nombre de host (como fuente del registro CNAME)
"RDATA: que es el tipo y, a veces, los datos dependientes de la clase que describe el recurso:"
"CNAME un nombre de dominio".
Entonces, tanto el propietario de un CNAME
(lo que está a su izquierda) como los datos de recursos adjuntos a él, su destino / destino (lo que está a su derecha) son nombres de dominio y no solo nombres de host. Básicamente, cualquier personaje, por lo que _
está permitido en ambos lados.
Nuevamente, fácil de probar con named-checkzone
:
$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.
No hay errores en absoluto sobre el CNAME
(se esperan los otros errores ya que en mi zona falsa no puse ninguno SOA
o NS
registros como lo habría hecho una zona verdadera)