¿Es _ (subrayado) ilegal en un registro CNAME?

9

Tenemos problemas para crear el registro TXT largo para la clave DKIM en la interfaz web de nuestro host.

Cada línea solo puede aceptar 256 caracteres.

Intentamos varias líneas, luego intentamos agregar ("al principio y ")después del último, como sugieren algunos. Ninguno de los dos funciona.

Luego intentamos hacer un CNAME a un registro en otro proveedor de alojamiento, donde nos podemos hacer los registros DKIM TXT.

Pero ahora la interfaz web se queja sobre el nombre ilegal en el CNAMEregistro.

mail._domainkey.example.com TXTestá bien
mail._domainkey.example.com CNAMEno está bien
mail.domainkey.example.com CNAMEestá bien, pero no es lo que queremos.

¿La interfaz web está decidida a volvernos locos o es realmente "ilegal" tener guiones bajos CNAME?

domain-name-system opendkim

— Lenne
fuente

1

¡El proveedor está arreglando la interfaz web mientras escribo esto!

— Lenne

18

Sí, los nombres DNS (esto también incluye A / AAAA) solo pueden contener [0-9], [a-z], -, por lo que el guión bajo no es válido. Tenga en cuenta que un registro TXT no es un nombre de host, y esta restricción no se aplica. Y una última edición: -tampoco se puede usar como primer carácter, por mail.-domainkey.our.domlo que no sería válido.

https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

Edición final: estaba parcialmente equivocado. Cuando se utiliza un CNAME como nombre de host, se aplican las restricciones anteriores. Parece que un CNAME no se considera un nombre de host en el contexto DKIM y, en ese caso, _debería ser una parte válida de una entrada CNAME. Ver /programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491

— Sven
fuente

¿Pero es un CNAME un nombre de host? Parte de la documentación muestra el uso de subrayado en un cname, por lo que aparentemente funciona. kb.mailchimp.com/accounts/email-authentication/…

— Lenne

Además, los guiones bajos aparecen en las entradas DNS en las zonas integradas de MS Windows Active Directory que subyacen a los Dominios de Windows, al menos en la herramienta de administración de DNS de Microsoft, pero no estoy seguro de si esos guiones bajos son realmente parte del nombre y Windows admite guiones bajos en DNS solicitudes, o si los guiones bajos solo aparecen en el complemento de administración de DNS y en realidad no forman parte de los nombres.

— Todd Wilcox

Tenga en cuenta que la entrada de Wikipedia citada tiene que ver con nombres de Internet, no DNS.

— Jim B

@ Lenne: Un CNAME es un nombre de host válido porque es un alias para un host. @ToddWilcox: sí, esto es conocido, y esta es una violación de especificaciones (¿deliberada?) Por parte de MS que causó que otros sistemas no presenten muchos problemas, ya que aparecen en DNS, DHCP, ... paquetes a pesar de no ser legales.

— mirabilos

2

@mirabilos "Un CNAME es un nombre de host válido" no, el objetivo (RDATA) de un CNAME es un nombre de dominio, no un nombre de host (un nombre de dominio es un superconjunto de todos los posibles nombres de host). _foo CNAME _bares completamente legítimo, puedes probar con named-checkzone.

— Patrick Mevzek

2

Todos los caracteres válidos están permitidos en DNS. Ver https://tools.ietf.org/html/rfc2181#section-11

"El DNS mismo solo impone una restricción en las etiquetas particulares que pueden usarse para identificar registros de recursos. Esa restricción se relaciona con la longitud de la etiqueta y el nombre completo. La longitud de cualquier etiqueta está limitada a entre 1 y 63 octetos. "

El cliente debe validar los valores de nombre, por ejemplo, un registro MX puede contener el valor "Alice", pero después de la búsqueda, ese valor debe ser rechazado ya que "Alice" no es una dirección de correo electrónico válida.

En este caso, parece que su proveedor está "validando" su entrada y debería poder ingresarla manualmente.

— Jim B
fuente

"Todos los caracteres válidos están permitidos en DNS" es un poco más complicado que eso. Hay nombres de dominio y nombres de host. Excepto si se dice lo contrario, en todas partes tiene etiquetas que son nombres de dominio, lo que significa de hecho cualquier carácter, por _lo que o cualquier otra cosa que desee. Pero, para algunos registros, solo puede usar nombres de host y no nombres de dominio. Los nombres de host son solo letras, dígitos y guiones, nada más. Por ejemplo, el propietario de una Ao AAAAregistro es un nombre de host, no un nombre de dominio. El RDATA (destino) de un NSregistro también es un nombre de host, no un nombre de dominio.

— Patrick Mevzek

1

"un registro MX puede contener el valor" Alice ", pero después de la búsqueda, ese valor debe rechazarse ya que" Alice "no es una dirección de correo electrónico válida". ¿Desde cuándo los RR MX hacen referencia a las direcciones de correo electrónico?

— un CVn

0

RFC 1034: las etiquetas deben seguir las reglas para los nombres de host ARPANET. Deben comenzar con una letra, terminar con una letra o 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.

— micmav
fuente

También tengo problemas con Arduino, donde algunas bibliotecas dan un nombre de host como ESP_245537, este nombre se rechaza cuando el servidor DHCP intenta actualizar el DNS.

— Lenne

Esto está mal. La etiqueta de un CNAME no es necesariamente un nombre de host, por lo que todos los caracteres son válidos aquí, incluido el _.

— Patrick Mevzek

1

E incluso sin eso, estas son las viejas reglas. Prohibían los nombres de host que comenzaban con un dígito, pero para acomodar, 3com.compor ejemplo, esta regla se relajó, consulte tools.ietf.org/html/rfc1123#page-13 "Se modifica un aspecto de la sintaxis del nombre de host: la restricción sobre el primer carácter se relaja para permitir una letra o un dígito ".

— Patrick Mevzek

@Lenne si esp_245537se usa como nombre de host, entonces la actualización de DNS debe rechazarse ya que no es un nombre de host válido. Si se usa como nombre de dominio, la actualización de DNS debería tener éxito (de lo contrario, es un error), ya que es una etiqueta de DNS válida.

— Patrick Mevzek

He visto indicios de que es posible traducir caracteres no válidos de DHCP a DNS, pero nunca lo hice funcionar.

— Lenne

0

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 CNAMEregistro 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 Ao AAAAregistro es un nombre de host, no un nombre de dominio. Entonces test.example.com A 192.0.2.1es 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-checkzoneprograma (parte del bindsoftware 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 INes 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: NSno 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 SOAo NSregistros como lo habría hecho una zona verdadera)

— Patrick Mevzek
fuente