¿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?

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).

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.