¿Está bien publicar un registro TLSA para servicios que no sean DNSSEC CNAME?

La configuración:

example.com. IN MX 0 smtp.example.com. ; AD=1
smtp.example.com. IN CNAME smtp.example.org. ; AD=1
smtp.example.org. IN A 192.0.2.1 ; AD=0
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1

Producirá TLS asegurado por DANE con al menos algunas implementaciones de DANE, por ejemplo. Sufijo. Sin embargo, esto puede no funcionar en todos los casos, por dos razones:

1. Los CNAME infringen el requisito de RFC de que el campo intercambio del registro MX ya sea canónico y no un CNAME (consulte enlace ), por lo tanto, aunque no conozco ningún MTA que no permita a los CNAME aquí, cumplirían con la norma si lo hicieran. Sin embargo, en mi encuesta de (hoy) 4,244,642 dominios firmados por DNSSEC que tienen registros MX, encuentro 1,432,478 hosts MX distintos de los cuales 21,262 son CNAMEs (que sirven 34,886 dominios) y aparentemente no tienen problemas. Entonces, en la práctica, los CNAME en los registros MX parecen funcionar.
2. Más importante aún, enlace explica que las búsquedas de TLSA se deben omitir cuando el nombre del host MX se encuentra en una zona sin firma, como lo demuestra el estado de seguridad de sus registros A / AAAA. Cuando no se involucra ningún CNAME, esto es simple, y es poco probable que las implementaciones manejen mal este caso. Cuando el nombre de host MX es un CNAME en una zona insegura, espero que algunas implementaciones (p. Ej. Creo que Exim) no determinará el estado de seguridad del CNAME inicial, y así (a diferencia de Postfix) no intentarán las búsquedas de TLSA en ese caso.

Averiguar si el CNAME RR que apunta a registros inseguros A es seguro requiere una consulta CNAME separada para el mismo nombre, lo que suprime la recursión en el resolvedor y devuelve el estado de seguridad del propio CNAME. Exim, y probablemente algunos otros MTA no pueden hacer eso. Aunque RFC7672 dice que DEBEN hacerlo, es una lógica bastante sutil, y es probable que se omita en las implementaciones.

Línea inferior, si realmente quiere que DANE funcione, evite los CNAME en dominios inseguros y, si es necesario, publique registros A / AAAA en el dominio seguro que dupliquen los registros A / AAAA del host subyacente:

example.com. IN MX 0 smtp.example.com. ; AD=1
; smtp.example.com. IN CNAME smtp.example.org. ; AD=0
smtp.example.com. IN A 192.0.2.1 ; AD=1 (cloned from smtp.example.org)
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1

  

1. ¿Tendría sentido en este caso publicar también registros DANE / TLSA dobles como usted sugiere en enlace ?
  

La elección de los tipos de registros TLS que se usarán para la administración robusta de claves es, en su mayoría, un problema separado. Así que sí, por supuesto, probablemente debería haber al menos dos registros, ya sea doble "3 1 1" (actual + siguiente) o "3 1 1" + "2 1 1" (servidor + emisor).

Sin embargo:

  

2. Además, el certificado usado probablemente no coincidirá con smtp.example.com. Supongo que eso realmente no importa, porque los servidores de correo no suelen coincidir con el nombre del servidor con el certificado. Correcto?
  

El certificado debe coincidir con todos los nombres de host MX utilizados por cualquier dominio para dirigir el correo al servidor en cuestión. Eso es para lo que subjectAlternativeName está en el certificado. Mientras que en SMTP, la coincidencia de los registros TLSA con el uso de certificados DANE-EE (3) ignora explícitamente los nombres DNS en el certificado, tomando el enlace de nombre del registro TLSA en DNS, lo mismo no es cierto para el uso de certificados DANE-TA . Así que asegúrese de enumerar todos los nombres de requisitos en el certificado.