ALIASES d'enregistrement DNS A et différences d'enregistrement ANAME

Nous avons un certain nombre de groupes de serveurs sur AWS qui utilisent des trios de serveurs pour desservir les sites. Chaque serveur ou ensemble de serveurs se trouve dans une région de disponibilité différente, dont l'un est un serveur de redirection tandis que les deux autres sont les serveurs principaux accessibles derrière un équilibreur de charge élastique. Nous avons enfin un client à bord pour utiliser Route53 et recherchions des détails sur les domaines de pointe de zone de pointage aux équilibres de charge élastiques. La plupart des fournisseurs DNS qui prennent en charge cela semblent se référer à cela comme des alias DNS des enregistrements A. Cependant, certains sites semblent faire référence à un enregistrement similaire appelé enregistrement ANAME. Ce n'est pas le CNAME typique ou l'enregistrement DNAME atypique. La plupart de ces sites renvoient également à DNSMadeEasy ~~simpleDNS~~ qui l'utilise.

Alors, quelle est la différence entre Route53 (ou ailleurs) A record ALIASes et ANAME records? Est-ce qu'il y a un? Est-ce que l'un de ceux-ci a, ou est inclus dans un document d'implémentation IEFT RFC ou les enregistrements alias sont-ils tous implémentés dans le fournisseur sur lequel ils sont utilisés?

[modifier]: fournisseur DNS incorrect répertorié pour une utilisation ANAME

— dcmbrown
source

Les "enregistrements" ALIAS et ANAME ne sont incorporés par aucun RFC.

— Andrew B

Cela devrait être mis à jour pour indiquer que les enregistrements ANAME sont dans un projet de groupe de travail de l'IETF: datatracker.ietf.org/doc/draft-ietf-dnsop-aname

— Christopher_G_Lewis

Il semble que ce ANAMEsoit un nom à consonance standard composé par DNS Made Easy pour décrire une offre de service qui est extrêmement similaire à ce que fait un Alias Route 53.

J'ai décrit les différences entre un alias et CNAMErécemment sur Stack Overflow , mais pour résumer ici:

Un serveur DNS provisionné avec un CNAMEpour un hôte donné distribue une référence indiquant le nom canonique de l'hôte recherché, nécessitant souvent une deuxième requête par le résolveur d'origine pour rechercher ce nom alternatif; un alias (et à première vue, un ANAME) utilise des informations internes que le serveur DNS connaît sur la "vraie" destination pour simplement répondre directement à la demande, sans avoir besoin d'une deuxième recherche et sans aucune visibilité des informations intermédiaires dans le Échanges de protocoles DNS.

En plus de cela, un alias offre la possibilité d'utiliser les informations que Route 53 a en sa possession sur les adresses IP actuellement valides pour les points de terminaison du site Web S3, ELB et Cloudfront, pour répondre aux requêtes d'enregistrement A avec des informations faisant autorité qui sont exactes en temps quasi réel, ce qui, si vous utilisez ces services, n'est pas quelque chose que tout autre fournisseur aura à sa disposition; bien sûr, l'inverse est également vrai, un alias Route 53 ne peut pas être utilisé pour rechercher et renvoyer des informations qui ne sont pas intrinsèquement disponibles pour Route 53. Vous ne pouvez pas simplement utiliser "n'importe quelle cible" pour un alias - seul le points de terminaison des trois services que j'ai mentionnés ci-dessus, ou d'autres enregistrements dans la même zone hébergée au sein de Route 53.

Dans ce sens, un ANAMEet un alias ne sont pas équivalents, selon le service qui fournit le back-end ... à moins que le ANAMEpointage (en interne) vers des informations statiques.

Un ANAMEenregistrement sur le service d'un autre hôte DNS ne pourrait pas fournir les mêmes capacités que Route 53 si la destination est S3, ELB ou CloudFront, de la même manière qu'un alias sur Route 53 ne serait pas en mesure de renvoyer des réponses pointant vers un autre Emplacements périphériques du fournisseur CDN utilisant des informations disponibles en interne, car les informations ne sont pas disponibles en interne pour l'infrastructure du fournisseur. Sinon, la fonctionnalité semble en grande partie la même.

— Michael - sqlbot
source

Juste une note rapide qu'à ce jour, Route 53 ne prend toujours pas en charge le domaine apex CNAME ni aucune alternative.

— Fabien Snauwaert

@FabienSnauwaert qui n'est pas précis. Route 53 prend en charge les alias d'enregistrement A au sommet, qui peuvent refléter la valeur d'un point de terminaison S3, CloudFront, ELB / ALB ou Elastic Beanstalk. Route 53 ne prend pas en charge un CNAME au sommet d'une zone, et ne le sera probablement jamais, car ce n'est pas une configuration valide.

— Michael - sqlbot

Merci pour la clarification, Michael, je l'apprécie. J'essayais de faire référence à ce qu'on appelle ALIASchez DNSimple, ANAMEchez DNS Made Easy, ANAMEchez easyDNS, ALIASchez PointDNS et CNAME(un faux nom) chez CloudFlare et permet de dire mydomain.com (www-less) à un autre domaine (par exemple: myapp.herokuapp. com). Pour autant que je sache, Route 53 n'offre pas une telle option pour le moment. (EDIT: J'en ai discuté ici à propos d'une autre société d'hébergement.)

— Fabien Snauwaert

L'absence d'un CNAME à la racine d'un domaine était un oubli dans le RFC d'origine qui aurait dû être corrigé il y a longtemps. De toute évidence, un CNAME à la racine devrait être pour toutes les demandes d'enregistrement SAUF une SOA, plutôt que d'en faire une erreur, car c'est complètement sans ambiguïté et fonctionne très bien ... même avec les serveurs de mise en cache hérités (essayez-le ... pirater un serveur DNS et servir un CNAME à partir de la racine ... il se résoudra et sera correctement mis en cache!).

— Erik Aronesty

@ErikAronesty ce n'est vraiment pas complètement sans ambiguïté. Piratez le serveur DNS, puis essayez d'envoyer des e-mails au domaine. Qui est l'échangeur de courrier? Si vous voulez faire une exception pour SOA, vous avez besoin d'une exception pour MX, TXT, NS, ... puisque CNAME signifie que ce nom d'hôte est un alias pour un autre, cela implique que ces enregistrements doivent être recherchés pour l'autre nom d'hôte. et cela n'a généralement pas de sens, en particulier pour l'hébergement Web.

— Michael - sqlbot

Commençant ici même dans la FAQ, il explique qu'un enregistrement d'alias est un pointeur spécifique Route53, similaire à un enregistrement CNAME, mais non visible par un résolveur.

— mortenya
source

C'est à peu près ce à quoi je m'attendais. Tout en testant cette configuration dans un format d'enregistrement simple, il semble fonctionner à peu près comme un enregistrement DNS A à tour de rôle, avec la mise en cache DNS locale jusqu'à ce qu'il expire, puis le plus souvent, basculez vers l'enregistrement opposé.

— dcmbrown