Bonnes pratiques relatives à Amazon Route 53 DNS

Les plans de données pour Route 53, y compris les bilans de santé, et le contrôle de routage d'Amazon Application Recovery Controller (ARC) sont distribués dans le monde entier et sont conçus pour garantir une disponibilité et des fonctionnalités à 100 %, même en cas d'événements graves. Ils s'intègrent les uns aux autres et ne dépendent pas de la fonctionnalité du plan de contrôle. Bien que les plans de contrôle de ces services, y compris leurs consoles, soient généralement très fiables, ils sont conçus de manière plus centralisée et privilégient la durabilité et la cohérence plutôt que la haute disponibilité. Pour les scénarios tels que le basculement pendant la reprise après sinistre, nous vous recommandons d'utiliser des fonctionnalités telles que les contrôles de santé de Route 53 et le contrôle du routage ARC qui s'appuient sur les fonctionnalités du plan de données pour mettre à jour le DNS. Pour plus d’informations, consultez Concepts de plan de données et contrôle et Blog : Création de mécanismes de reprise après sinistre avec Amazon Route 53.

La TTL de DNS est la valeur numérique (en secondes) que les résolveurs DNS utilisent pour décider pendant combien de temps un registre peut être mis en cache sans effectuer une autre requête à Route 53. Tous les registres DNS doivent avoir une TTL spécifiée. La plage recommandée pour les valeurs de TTL est comprise entre 60 et 172 800 secondes.

Le choix d'une TTL est un compromis entre la latence et la fiabilité, et la réactivité au changement. Avec un enregistrement plus court TTLs , les résolveurs DNS constatent les mises à jour de l'enregistrement plus rapidement car ils doivent effectuer des requêtes plus fréquemment. Cela augmente le volume (et le coût) de la requête. Lorsque vous augmentez la TTL, les résolveurs DNS répondent plus souvent aux requêtes du cache, ce qui est généralement plus rapide, moins coûteux et, dans certains cas, plus fiable, car cela évite les requêtes sur Internet. Il n'y a pas de valeur correcte, mais il vaut la peine de réfléchir à la question de savoir si la réactivité ou la fiabilité est plus importante pour vous.

Points à prendre en compte lors de la définition des valeurs de la TTL :

Pour plus d'informations, consultez TTL (secondes).

Les registres CNAME DNS permettent de pointer un nom de domaine vers un autre. Si un résolveur DNS résout le domaine 1.exemple.com et trouve un CNAME pointant vers domain-2.example.com, le résolveur DNS doit procéder à la résolution domain-2.example.com avant qu'il ne puisse répondre. Ces registres sont utiles dans de nombreuses situations, par exemple pour garantir la cohérence lorsqu'un site Web possède plusieurs noms de domaine.

Cependant, les résolveurs DNS doivent effectuer davantage de requêtes pour y répondre CNAMEs, ce qui augmente le temps de latence et les coûts. Dans la mesure du possible, une alternative plus rapide et moins coûteuse consiste à utiliser un registre Route 53 alias. Les enregistrements d'alias permettent à Route 53 de répondre directement aux AWS ressources (par exemple, un équilibreur de charge) et aux autres domaines de la même zone hébergée.

Pour de plus amples informations, veuillez consulter Acheminement du trafic Internet vers vos AWS ressources.

Pour plus d’informations, consultez Routage de géolocalisation, Routage par géoproximité et Routage basé sur la latence.

Lorsque vous créez ou mettez à jour un registre ou une zone hébergée à l'aide de la console ou de l'API Route 53, il faut un certain temps avant que la modification soit reflétée sur Internet. C'est ce qu'on appelle propagation du changement. Bien que la propagation dure généralement moins d'une minute, il arrive parfois qu'une modification soit retardée, par exemple, en raison de problèmes de synchronisation avec un emplacement ou, dans de rares cas, de problèmes du plan de contrôle central. Si vous créez des flux de travail de provisionnement automatisés et qu'il est important d'attendre que la propagation des modifications soit terminée avant de passer à l'étape suivante du flux de travail, utilisez l'GetChangeAPI pour vérifier que vos modifications DNS sont entrées en vigueur (Status =INSYNC).

Lorsque vous déléguez plusieurs niveaux de sous-domaines dans DNS, il est important de toujours déléguer à partir de la zone parente. Par exemple, si vous déléguez www.dept.example.com, vous devez le faire à partir du dept.example.com zone, pas depuis le example.com zone. Les délégations à partir d'un grand-parent vers une zone enfant peuvent ne pas fonctionner du tout ou fonctionner de manière incohérente. Pour de plus amples informations, veuillez consulter Acheminement du trafic pour les sous-domaines.

Évitez de créer des réponses uniques volumineuses. Si les réponses dépassent les 512 octets, de nombreux résolveurs DNS doivent réessayer sur TCP plutôt que sur UDP, ce qui peut entraîner une fiabilité réduite et des réponses plus lentes. Nous vous recommandons d'utiliser le routage de réponse multivaleur qui choisit huit adresses IP surveillées et aléatoires pour conserver les réponses dans la limite de 512 octets.

Pour plus d'informations, consultez Multivalue answer routing (Routage de réponse multivaleur) et DNS Reply Size Test Server (Serveur de test de taille de réponse DNS).