¿Registros SRV publicados que apuntan al alias CNAME en violación de RFC 2782?

En el curso de algunas responsabilidades laborales, necesito relacionarme con los registros SRV, y estoy tratando de conciliar una declaración de Wikipedia con lo que estoy viendo en las excavaciones de DNS.

De acuerdo con la entrada del registro SRV de Wikipedia ,

el objetivo en los registros SRV debe apuntar al nombre de host con un registro de dirección (registro A o AAAA). Señalar un nombre de host con un registro CNAME no es una configuración válida.

pero veo registros donde digdevuelve un registro SRV que apunta a un nombre que es el alias en un registro CNAME.

Es decir, algo como esto:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

Parece que el registro SRV está configurado exactamente como la entrada de Wikipedia dice que no está permitido. ¿Qué estoy malentendido? ¿No muestra que el registro SRV apunta a alias.domain.com, que tiene un registro CNAME, no un registro de dirección?

domain-name-system cname-record srv-record

— Scott
fuente

en mi empresa usamos SRV registra una gran cantidad, y la mayoría de ellos están utilizando CNAMEs y trabaja muy bien, tan en contra de las reglas o no, funciona muy bien :)

— olivierg

Respuestas:

El artículo de Wikipedia que está citando informa lo que dice el RFC 2782 relevante para registros SRV:

Objetivo

El nombre de dominio del host de destino. DEBE haber uno o más registros de dirección para este nombre, el nombre NO DEBE ser un alias (en el sentido de RFC 1034 o RFC 2181).

Lo que está viendo es una clara violación de las reglas; sin embargo, podría funcionar (y generalmente lo hace) si la aplicación cliente que está buscando ese registro SRV es lo suficientemente inteligente como para manejar adecuadamente un registro CNAME, incluso si solo debería esperar un registro A en la respuesta.

Pero también podría no funcionar en absoluto: no es compatible y depende completamente de la aplicación del cliente; por lo tanto, debe evitarse porque no sigue las reglas adecuadas y podría dar lugar a resultados erróneos o impredecibles.

Esto es similar a apuntar un registro MX a un CNAME, que se define como incorrecto no solo en uno , sino en dos RFC, y sin embargo es una práctica bastante común (y ningún servidor de correo parece tener un problema).

— Massimo
fuente

Tenga en cuenta que "lo suficientemente inteligente" es relativo. Algunos diseñadores de software piensan que soportar las implementaciones de braindead solo fomenta más implementaciones de las mismas. RFC 2781 solo ha sido actualizado por un solo RFC y el lenguaje sobre qué esperar es muy firme, por lo que no esperaría mucha piedad aquí.

— Andrew B

La mayoría de las aplicaciones cliente solo confían en las bibliotecas del sistema para realizar consultas DNS, y la mayoría de las bibliotecas (especialmente en idiomas de nivel superior) harán todo lo posible para resolver cualquier consulta que les envíes, y seguirán feliz y silenciosamente un CNAME hasta su registro A de destino y Dirección IP.

— Massimo

La aplicación no necesita mucha inteligencia, simplemente le pedirá al sistema operativo que se conecte a "alias.domain.com" en el puerto 4443 y le deje todos los detalles.

— Massimo

La aplicación cliente y las bibliotecas del sistema no tendrán la oportunidad de seguir el alias si el recurrente ascendente rechaza los datos autorizados y se niega a continuar. (que es la inteligencia relativa a la que me refería) El manejo NSclásico de los registros y el alias prohibido de BIND es el ejemplo clásico de esto. De todos modos, estamos de acuerdo en que es el juego de cualquiera con resultados impredecibles.

— Andrew B

Algunos servidores de correo comenzaron a ignorar activamente MXes a CNAME, por ejemplo, GMX medienconsulting.at/…

— Marcel Waldvogel

Ese es un ejemplo del comportamiento restringido, sí. La restricción en sí proviene del RFC 2781 en la definición de "objetivo":

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

El software del servidor DNS que permite configuraciones prohibidas no es nada nuevo, desafortunadamente. Puede suceder y sucede, como sucede con otros tipos de registros donde los objetivos con alias están prohibidos, como NSy MX. (mencionado anteriormente)

El hecho de que se pueda encontrar en la naturaleza no significa que esté "bien", y lo que sucede cuando se ignora un estándar varía de un producto a otro. No he probado la interacción con los SRVregistros, pero una decisión de diseño muy conocida de ISC BIND con respecto a los NSregistros que apuntan a alias es eliminar el registro por completo si se encuentra durante la recursividad. Si todos los NSregistros se eliminan de esta manera, el resultado de todas las consultas será SERVFAILpara el subdominio en cuestión.

En resumen, atenerse al estándar. Es la única cosa segura que hacer.

— Andrew B
fuente