Des enregistrements SRV publiés pointant vers un alias CNAME en violation de la RFC 2782?

Au cours de certaines responsabilités professionnelles, je dois me concentrer sur les enregistrements SRV, et j'essaie de concilier une déclaration Wikipedia avec ce que je vois dans les fouilles DNS.

Selon l'entrée de l'enregistrement SRV de Wikipedia ,

la cible dans les enregistrements SRV doit pointer vers le nom d'hôte avec un enregistrement d'adresse (enregistrement A ou AAAA). Le fait de pointer vers un nom d'hôte avec un enregistrement CNAME n'est pas une configuration valide.

mais je vois des enregistrements où digrenvoie un enregistrement SRV pointant vers un nom qui est l'alias dans un enregistrement CNAME.

Autrement dit, quelque chose comme ça:

> 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

Il semble que l'enregistrement SRV soit configuré exactement de la même manière que l'entrée Wikipedia n'est pas autorisée. Qu'est-ce que je comprends mal? Cela ne montre-t-il pas que l'enregistrement SRV pointe sur alias.domain.com, qui a un enregistrement CNAME, pas un enregistrement d'adresse?

domain-name-system cname-record srv-record

— Scott
source

dans mon entreprise, nous utilisons beaucoup les enregistrements SRV, et la plupart d'entre eux utilisent des CNAME et cela fonctionne bien, donc contre les règles ou non, cela fonctionne bien :)

— olivierg

Réponses:

L'article de Wikipédia que vous citez rapporte ce que dit la RFC 2782 pour les enregistrements SRV:

Cible

Le nom de domaine de l'hôte cible. Il DOIT y avoir un ou plusieurs enregistrements d'adresse pour ce nom, le nom NE DOIT PAS être un alias (au sens de RFC 1034 ou RFC 2181).

Ce que vous voyez est une violation claire des règles; cependant, cela peut fonctionner (et c'est généralement le cas), si l'application cliente qui recherche cet enregistrement SRV est suffisamment intelligente pour gérer correctement un enregistrement CNAME, même si elle ne devrait s'attendre qu'à un enregistrement A dans la réponse.

Mais cela peut aussi ne pas fonctionner du tout: il n'est pas pris en charge et dépend entièrement de l'application cliente; il convient donc de l'éviter, car il ne suit pas les règles appropriées et pourrait conduire à des résultats erronés et / ou imprévisibles.

Cela revient à pointer un enregistrement MX vers un CNAME, qui est défini comme juste faux dans non seulement un , mais deux RFC, et pourtant c'est une pratique assez courante (et aucun serveur de messagerie ne semble avoir de problème avec cela).

— Massimo
source

Gardez à l'esprit que «assez intelligent» est relatif. Certains concepteurs de logiciels sont d'avis que la mise en œuvre d'implémentations braindead ne fait qu'encourager davantage d'implémentations. La RFC 2781 n'a été mise à jour que par une seule RFC et le langage sur ce à quoi s'attendre est très ferme, donc je ne m'attendrais pas à beaucoup de pitié ici.

— Andrew B

La plupart des applications clientes s'appuient uniquement sur les bibliothèques système pour effectuer des requêtes DNS, et la plupart des bibliothèques (en particulier dans les langages de niveau supérieur) feront de leur mieux pour résoudre toutes les requêtes que vous leur lancerez, et suivront joyeusement et silencieusement un CNAME vers sa destination Un enregistrement et Adresse IP.

— Massimo

L'application n'a pas besoin de beaucoup d'intelligence, elle demandera simplement au système d'exploitation de se connecter à "alias.domain.com" sur le port 4443 et de lui laisser tous les détails.

— Massimo

L'application cliente et les bibliothèques système n'auront pas la possibilité de suivre l'alias si le récurseur en amont rejette les données faisant autorité et refuse de continuer. (qui est l'intelligence relative à laquelle je faisais référence) La gestion des NSenregistrements et des alias interdits par BIND en est l'exemple classique. Quoi qu'il en soit, nous sommes d'accord pour dire que c'est le jeu de n'importe qui avec des résultats imprévisibles.

— Andrew B

Certains serveurs de messagerie ont commencé à ignorer activement les MX vers les CNAME, par exemple GMX medienconsulting.at/…

— Marcel Waldvogel

C'est un exemple du comportement restreint, oui. La restriction elle-même provient de la RFC 2781 dans la définition de "cible":

   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.

Malheureusement, le logiciel serveur DNS permettant des configurations interdites n'a rien de nouveau. Cela peut arriver et se produit, comme c'est le cas avec d'autres types d'enregistrement où les cibles aliasées sont interdites telles que NSet MX. (mentionné ci-dessus)

Ce n'est pas parce qu'il peut être trouvé dans la nature qu'il est "correct", et ce qui se passe quand une norme est ignorée varie d'un produit à l'autre. Je n'ai pas testé l'interaction avec les SRVenregistrements, mais une décision de conception très connue par ISC BIND en ce qui concerne les NSenregistrements pointant sur des alias consiste à supprimer complètement l'enregistrement s'il est trouvé pendant la récursivité. Si tous les NSenregistrements sont supprimés de cette manière, le résultat de toutes les requêtes sera SERVFAILpour le sous-domaine en question.

En bref, respectez la norme. C'est la seule chose sûre à faire.

— Andrew B
source