67 votes

Pourquoi Heroku met-il en garde contre les noms de domaine "nus" ?

Je suis tombé sur cette page dans la documentation de Heroku...

Les domaines nus, également appelés domaines nus ou apex, sont configurés dans le DNS via des enregistrements A et ont de sérieuses implications en termes de disponibilité lorsqu'ils sont utilisés dans des environnements hautement disponibles tels que des centres de données massifs sur site, des services d'infrastructure en nuage et des plateformes comme Heroku.

Pour une évolutivité et une résilience maximales, les applications doivent éviter les domaines nus et s'appuyer uniquement sur des noms d'hôtes basés sur des sous-domaines.

Est-ce que quelqu'un ici parle Enterprise ? Quelles sont les "implications de disponibilité" dont ils nous mettent en garde ?

(Je remarque que http://stackoverflow.com fonctionne sans problème, donc manifestement il existe des philosophies alternatives viables sur cette question).

58voto

Shane Madden Points 112034

Ce dont ils parlent, c'est que lorsque vous utilisez un CNAME pour pointer vers leurs services (ce qui n'est possible que sur le sous-domaine, pas sur la racine de la zone - cela ne peut pas coexister avec l'option SOA y NS qui sont nécessaires à la racine de votre zone), ils peuvent apporter une modification à leurs propres enregistrements DNS pour contourner un problème de disponibilité.

Avec une racine de zone, vous devez utiliser un A pour pointer vers une adresse IP spécifique pour le service. S'ils ont un problème de routage, ou une sorte de déni de service contre cette adresse spécifique, ils ne sont pas en mesure de mettre à jour de votre zone A pour pointer vers une autre IP à la volée ; ils peuvent cependant mettre à jour la leur, et c'est ce qu'une CNAME leur permet de le faire.

Cela ne s'applique pas à Stack Exchange car ils n'utilisent pas la plateforme d'un tiers ; ce sont eux qui répondent à un problème de disponibilité, donc qu'il s'agisse d'une CNAME ou un A ne fait aucune différence pour eux.

13voto

mgorven Points 29736

En complément de la réponse de @ShaneMadden, une solution consiste à faire en sorte que la plateforme tierce gère également votre zone DNS. Par exemple, si vous utilisez la solution AWS Équilibreur de charge élastique service, y leur Route 53 vous pouvez faire pointer l'apex de la zone vers une instance ELB en utilisant son service DNS personnalisé. enregistrements d'alias qui leur permet de mettre à jour votre zone DNS en réponse à des problèmes de disponibilité.

Il s'agit toutefois d'un argument contre la no-www le concept, puisque www.example.com peut avoir un CNAME record.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X