Modification d'un logging «A» sur un «CNAME» sans time d'arrêt

J'ai un nom de domaine (actuellement hébergé sur dyn.com) avec un logging indiquant notre adresse IP de production.

Nous passons à Amazon EC2 et utilisons un équilibreur de charge, avec la recommandation d'utiliser un CNAME au lieu d'un logging A , car les équilibreurs de charge peuvent périodiquement modifier l'adresse IP.

Malheureusement, je ne semble pas pouvoir effectuer cette transition de façon transparente – je dois d'abord supprimer l'logging A, puis append le CNAME, ce qui pourrait entraîner des time d'arrêt à mesure que le nouvel logging se propage.

Existe-t-il un moyen de le faire sans problème avec un time d'arrêt zéro (ou très minime)?

2 Solutions collect form web for “Modification d'un logging «A» sur un «CNAME» sans time d'arrêt”

Il y a une astuce que vous pouvez utiliser ici. Cela dit, Wesley est un mec intelligent et vous devriez l'écouter. Je ne suis pas payé pour dire cela, mais j'espère changer cela un jour.

En supposant que vous essayez de modifier un logging appelé www dans une zone appelée example.com.

  • Créez un logging temporaire temporaire Un logging ( * ) dans la zone. Commencez le changement. Testez-le, assurez-vous que le disque générique fonctionne comme prévu et remplace les réponses NXDOMAIN.
  • Supprimez l'logging www . Commettre.
  • Ajoutez votre nouveau record CNAME. Commettre. Testez à nouveau.
  • Supprimez l'logging du caractère générique * lorsque vous êtes satisfait.
  • Suivez les conseils de Wesley et trouvez un fournisseur de DNS qui ne vous force pas à sauter à travers des cerceaux comme celui-ci.

Puisque c'est votre réputation sur la ligne, vous voudrez peut-être une mise à jour rapide sur ce que Wikipedia a à dire sur la façon dont les caractères generics sont traités. Assurez -vous d'append un caractère générique avec le même nombre de points que l'logging que vous supprimez, car les loggings generics ne traversent pas un point. (connu sous le nom d'une label, si vous voulez le bon terme RFC)

En outre, cela devrait aller de soi, mais tous ces tests devraient être exécutés directement contre vos servers faisant autorité. ( pas contre le résolveur par défaut configuré pour l'ordinateur dont vous exécutez le test)

Nous passons à Amazon EC2 et utilisons un équilibreur de charge, avec la recommandation d'utiliser un CNAME au lieu d'un logging A

J'espère sincèrement que vous n'êtes pas le nom de votre domaine principal. Si votre hôte DNS est autonome, il ne sera pas autorisé. Si c'est un hôte honteux et visqueux, vous pourrez, mais vous allez perdre un morceau de votre âme (mais vous utilisez EC2 de toute façon, il semble que le souci pour votre âme soit déjà minime).

Quoth Amazon:

Vous ne pouvez pas utiliser un logging CNAME pour associer votre apex de zone avec votre instance Elastic Load Balancing. Les règles DNS interdisent la création d'un logging CNAME au niveau de la zone (exemple, example.com). Par exemple, si vous possédez le nom de domaine example.com, vous pouvez utiliser un logging CNAME pour le nom de sous-domaine foo.example.com, mais pas pour l'exemple de Zone d'exemple.com.

Continuer …

… puisque les équilibreurs de charge peuvent changer périodiquement l'adresse IP.

Non, les équilibreurs de charge ne doivent pas changer périodiquement les adresses IP. C'est leur sharepoint vue. Ils restnt les mêmes et agissent comme une couche d'abstraction entre les consommateurs et l'infrastructure de contenu. Si quelqu'un vous a indiqué que l'adresse IP de l'équilibreur de charge peut changer périodiquement, requestz-leur de la clarté.

Amazon ELB est en place, donc le but est de CNAME votre domaine au nom de ELB. Je comprends la situation maintenant.

Malheureusement, je ne semble pas pouvoir effectuer cette transition de façon transparente – je dois d'abord supprimer l'logging A, puis append le CNAME, ce qui pourrait entraîner des time d'arrêt à mesure que le nouvel logging se propage.

Sans quelques shenanigans de multidiffusion et peut-être même une panoplie de bogis de BGP, le DNS lui-même n'est pas destiné à avoir des changements de time d'arrêt. Vous pouvez cependant minimiser le potentiel d'immobilisation en supprimant les valeurs TTL de vos loggings jusqu'à la plus faible quantité possible de time. En règle générale, 60 secondes, mais si votre hôte DNS ne lui permet pas d'aller aussi bas, alors, ajoutez vos forets fourrés parce que c'est horrible. Quoi qu'il en soit, déposez vos loggings au plus petit nombre possible, mais attendez la durée de la précédente valeur TTL. Si votre valeur TTL précédente était de 3600 secondes, attendez une heure après avoir changé votre valeur TTL jusqu'à 60 secondes.

Une fois que vous avez attendu longtime, vous pouvez modifier votre logging A à un CNAME et vous n'aurez que 60 secondes de time d'arrêt à peu près.

J'ai effectué des basculement similaires qui impliquaient un time d'arrêt nul, mais la synchronisation a été effectuée sur les magasins de données, de sorte que lors de la période de coupure obscure, toutes les transactions qui ont filtré vers l'ancien et les nouveaux systèmes ont été synchronisées avec des magicks de backend. Cela coûte généralement plus de time et d'efforts que ce qui est justifié, sauf si vous avez affaire à beaucoup d'users et à de l'argent.

Le TTL est déjà de 60 secondes, mais SOA NXDOMAIN TTL est de 1800 secondes

… ce qui ne sera qu'un problème si votre domaine a quelque chose qui returnne une réponse NXDOMAIN, ce qui ne sera pas lorsque vous modifiez votre logging d'un A à un CNAME.

afin de supprimer l'logging A existant entraînera peut-être jusqu'à 30 minutes de réduction (dans la mesure où je peux le dire)

Non, parce que vous ne supprimez pas, que vous changez et que tout hôte DNS raisonnable commettrait la suppression de l'logging A et l'ajout du CNAME tout en un seul coup, donc vous ne répondrez pas avec NXDOMAIN à toutes les requêtes.

Si Dyn fait chaque changement dans votre zone une action atomique qui s'engage individuellement dans le file de zone, alors oui, vous pourriez potentiellement renvoyer les réponses NXDOMAIN. Ce qui est terrible pour Dyn fait, mais ne serait pas tout à fait surprenant.

que je ne semble pas pouvoir changer avec dyn.com

Mon avis (qui, combiné avec 5 $, peut vous donner une tasse de café chez Starbucks): Dyn est un terrible hôte DNS.

  • Comment obtenez-vous une IP permanente pour votre server DNS?
  • Détection de règles Snort pour la détection de packages DNS de type NULL
  • Aidez-vous à utiliser un CNAME
  • Protection d'un server dns
  • Un enregistrement DNS CNGE générique est-il valide?
  • Un logging CNAME ne peut-il pas inclure www?
  • Comment définir www et .com comme les versions canoniques du domaine?
  • DNS pour restreindre le contenu de youtube
  • Configuration du server de noms - lier
  • Puis-je utiliser CNAME pour envoyer un directory sur un autre server, ou seulement la page racine?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.