Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Bonnes pratiques relatives à Amazon Route 53
Cette section présente les meilleures pratiques relatives aux différents composants d'Amazon Route 53, notamment :
1. **Bonnes pratiques en matière de DNS :**
+ Comprenez les compromis entre les valeurs de durée de vie (TTL) et la réactivité par rapport à la fiabilité.
+ Utilisez des enregistrements alias plutôt que des enregistrements CNAME lorsque cela est possible pour améliorer les performances et réduire les coûts.
+ Configurez les politiques de routage par défaut pour garantir que tous les clients reçoivent une réponse.
+ Tirez parti du routage basé sur la latence pour minimiser la latence des applications et du geolocation/geoproximity routage pour la stabilité et la prévisibilité.
+ Vérifiez la propagation des modifications à l'aide de l'`GetChange`API pour les flux de travail automatisés.
+ Déléguez les sous-domaines de la zone parent pour un routage cohérent.
+ Évitez les réponses uniques volumineuses en utilisant le routage des réponses à valeurs multiples.
1. **Meilleures pratiques en matière de résolution :**
+ Empêchez les boucles de routage en évitant d'associer le même VPC à la fois à une règle de résolution et à son point de terminaison entrant.
+ Mettez en œuvre des règles de groupe de sécurité afin de réduire les frais de suivi des connexions et d'optimiser le débit des requêtes.
+ Configurez les points de terminaison entrants avec des adresses IP dans plusieurs zones de disponibilité à des fins de redondance.
+ Soyez conscient des attaques potentielles basées sur les zones DNS et contactez le AWS Support si vos terminaux subissent un ralentissement.
1. **Bonnes pratiques en matière de bilans de santé :**
+ Suivez les recommandations pour optimiser les bilans de santé d'Amazon Route 53 afin de garantir une surveillance fiable de vos ressources
En adhérant à ces meilleures pratiques, vous pouvez optimiser les performances, la fiabilité et la sécurité de votre infrastructure DNS, en garantissant un routage efficace du trafic vers vos applications et services
**Topics**
+ [Bonnes pratiques relatives à Amazon Route 53 DNS](best-practices-dns.md)
+ [Bonnes pratiques pour VPC Resolver](best-practices-resolver.md)
+ [Bonnes pratiques relatives aux vérifications de l'état d'Amazon Route 53](best-practices-healthchecks.md)
# Bonnes pratiques relatives à Amazon Route 53 DNS
Suivez ces bonnes pratiques pour obtenir les meilleurs résultats lorsque vous utilisez le service DNS Amazon Route 53.
**Utilisation des fonctions de plan de données pour le basculement DNS et la récupération d'applications**
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](route-53-concepts.md#route-53-concepts-control-and-data-plane) et [Blog : Création de mécanismes de reprise après sinistre avec Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/).
**Choix des valeurs TTL pour les registres DNS**
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 :
+ Définissez un enregistrement DNS TTLs pour la durée que vous pouvez vous permettre d'attendre avant qu'une modification prenne effet. Cela est particulièrement vrai pour les délégations (ensembles de registres NS) ou d'autres registres qui changent rarement, par exemple les registres MX. Pour ces enregistrements, une durée plus longue TTLs est recommandée. Une valeur comprise entre une heure (3 600 s) et un jour (86 400 s) est un choix courant.
+ Pour les enregistrements qui doivent être modifiés dans le cadre d'un mécanisme de basculement rapide (en particulier les enregistrements dont l'état est vérifié), une valeur inférieure TTLs est appropriée. La définition d'une TTL de 60 ou 120 secondes est un choix courant pour ce scénario.
+ Lorsque vous souhaitez apporter des modifications à des entrées DNS critiques, nous vous recommandons de raccourcir temporairement le TTLs. Vous pouvez ensuite effectuer les modifications, les observer et procéder rapidement à une restauration, si nécessaire. Lorsque les modifications sont finalisées et fonctionnent comme prévu, vous pouvez augmenter les TTL.
Pour plus d'informations, consultez [TTL (secondes)](resource-record-sets-values-shared.md#rrsets-values-common-ttl).
**Enregistrements CNAME**
Les registres CNAME DNS permettent de pointer un nom de domaine vers un autre. Si un résolveur DNS résout domain-1.example.com et trouve un CNAME pointant vers domain-2.example.com, le résolveur DNS doit procéder à la résolution de domain-2.example.com avant de pouvoir 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](routing-to-aws-resources.md).
**Routage DNS avancé**
+ Lorsque vous utilisez la géolocalisation, la géoproximité ou le routage basé sur la latence, définissez toujours une valeur par défaut, sauf si vous souhaitez que certains clients reçoivent des réponses *Aucune réponse*.
+ Pour réduire la latence des applications, utilisez le routage basé sur la latence. Ce type de données de routage peut changer fréquemment.
+ Pour assurer la stabilité et la prévisibilité du routage, utilisez la géolocalisation ou le routage de géoproximité.
Pour plus d’informations, consultez [Routage de géolocalisation](routing-policy-geo.md), [Routage par géoproximité](routing-policy-geoproximity.md) et [Routage basé sur la latence](routing-policy-latency.md).
**Propagation de la modification du DNS**
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'[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API pour vérifier que vos modifications DNS sont entrées en vigueur (`Status =INSYNC`).
**Délégation DNS**
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 depuis la zone dept.example.com, pas la zone example.com. 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](dns-routing-traffic-for-subdomains.md).
**Taille de la réponse DNS**
É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)](routing-policy-multivalue.md) et [DNS Reply Size Test Server (Serveur de test de taille de réponse DNS)](https://www.dns-oarc.net/oarc/services/replysizetest/).
# Bonnes pratiques pour VPC Resolver
Cette section fournit les meilleures pratiques pour optimiser le résolveur VPC Amazon Route 53, en abordant les sujets suivants :
1. **Éviter les configurations de boucle avec les points de terminaison du résolveur :**
+ Empêchez les boucles de routage en vous assurant que le même VPC n'est pas associé à la fois à une règle de résolution et à son point de terminaison entrant.
+ AWS RAM À utiliser pour partager VPCs entre comptes tout en conservant des configurations de routage appropriées.
Pour de plus amples informations, consultez [Évitez les configurations de boucle avec les points de terminaison Resolver.](best-practices-resolver-endpoints.md).
1. **Dimensionnement des points de terminaison du résolveur :**
+ Mettez en œuvre des règles de groupe de sécurité qui autorisent le trafic en fonction de l'état de la connexion afin de réduire les frais de suivi des connexions
+ Suivez les règles de groupe de sécurité recommandées pour les points de terminaison du résolveur entrants et sortants afin d'optimiser le débit des requêtes.
+ Surveillez les combinaisons d'adresses IP et de ports uniques générant du trafic DNS afin d'éviter les limitations de capacité.
Pour de plus amples informations, consultez [Mise à l'échelle du point de terminaison Resolver](best-practices-resolver-endpoint-scaling.md).
1. **Haute disponibilité pour les points de terminaison Resolver :**
+ Créez des points de terminaison entrants avec des adresses IP dans au moins deux zones de disponibilité à des fins de redondance.
+ Fournir des interfaces réseau supplémentaires pour garantir la disponibilité pendant la maintenance ou les pics de trafic
Pour de plus amples informations, consultez [Haute disponibilité pour les points de terminaison Resolver](best-practices-resolver-endpoint-high-availability.md).
1. **Prévention des attaques basées sur les zones DNS :**
+ Soyez conscient des attaques potentielles basées sur les zones DNS, dans le cadre desquelles les attaquants tentent de récupérer tout le contenu des zones DNS signées par le protocole DNSSEC.
+ Si vos terminaux subissent un ralentissement en raison d'une suspicion de franchissement de zone, contactez le AWS Support pour obtenir de l'aide.
Pour de plus amples informations, consultez [Parcours de zone DNS](best-practices-resolver-zone-walking.md).
En suivant ces bonnes pratiques, vous pouvez optimiser les performances, l'évolutivité et la sécurité de vos déploiements de résolveurs VPC, en garantissant une résolution DNS fiable et efficace pour vos applications et ressources.
# Évitez les configurations de boucle avec les points de terminaison Resolver.
N'associez pas le même VPC à une règle Resolver et à son point de terminaison entrant (qu'il s'agisse d'une cible directe du point de terminaison ou via un serveur DNS local). Lorsque le point de terminaison sortant d'une règle Resolver pointe vers un point de terminaison entrant qui partage un VPC avec la règle, il peut provoquer une boucle dans laquelle la requête est continuellement transmise entre les points de terminaison entrants et sortants.
La règle de transfert peut toujours être associée à d'autres VPCs règles partagées avec d'autres comptes en utilisant AWS Resource Access Manager (AWS RAM). Les zones hébergées privées associées au hub, ou à un VPC central, sont toujours résolues à partir des requêtes vers les points de terminaison entrants car une règle de réacheminement de résolveur ne modifie pas cette résolution.
# Mise à l'échelle du point de terminaison Resolver
Les groupes de sécurité du point de terminaison Resolver utilisent le suivi de connexion pour collecter des informations sur le trafic en provenance ou à destination des points de terminaison. Chaque interface de point de terminaison dispose d'un nombre maximal de connexions qui peuvent être suivies, et un volume élevé de requêtes DNS peut dépasser les connexions et provoquer une limitation et une perte de requête. Le suivi des connexions AWS est le comportement par défaut pour surveiller l'état du trafic passant par les groupes de sécurité (SGs). L'utilisation du suivi des SGs connexions permet de réduire le débit du trafic, mais vous pouvez implémenter des connexions non suivies pour réduire les frais généraux et améliorer les performances. Pour plus d'informations, voir [Connexions non suivies](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).
Si le suivi des connexions est appliqué en utilisant des règles de groupe de sécurité restrictives ou si les requêtes sont acheminées via Network Load Balancer ([voir Connexions suivies automatiquement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), le nombre maximum de requêtes par seconde et par adresse IP pour un point de terminaison peut être inférieur à 1 500.
**Recommandations relatives aux règles du groupe de sécurité d'entrée et de sortie pour le point de terminaison entrant du résolveur**
****
|
|
| **Règles d'entrée** |
| --- |
| Type de protocole | Numéro de port | IP Source |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **Règles de sortie** |
| --- |
| Type de protocole | Numéro de port | IP de destination |
| TCP | Tous | 0.0.0.0/0 |
| UDP | Tous | 0.0.0.0/0 |
**Recommandations relatives aux règles des groupes de sécurité d'entrée et de sortie pour le point de terminaison Resolver sortant**
****
|
|
| **Règles d'entrée** |
| --- |
| Type de protocole | Numéro de port | IP Source |
| TCP | Tous | 0.0.0.0/0 |
| UDP | Tous | 0.0.0.0/0 |
| **Règles de sortie** |
| --- |
| Type de protocole | Numéro de port | IP de destination |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**Note**
**Exigences relatives aux ports du groupe de sécurité :**
Les **points de terminaison entrants** nécessitent des règles d'entrée permettant aux protocoles TCP et UDP sur le port 53 de recevoir des requêtes DNS de votre réseau. Les règles de sortie peuvent autoriser tous les ports, car le point de terminaison peut avoir besoin de répondre à des requêtes provenant de différents ports sources.
Les **points de terminaison sortants** nécessitent des règles de sortie autorisant l'accès TCP et UDP aux ports que vous utilisez pour les requêtes DNS sur votre réseau. Le port 53 est illustré dans l'exemple ci-dessus car il s'agit du port DNS le plus courant, mais votre réseau peut utiliser des ports différents. Les règles d'entrée peuvent permettre à tous les ports de prendre en charge les réponses de vos serveurs DNS.
**Points de terminaison Resolver**
Pour les clients utilisant un point de terminaison de résolveur entrant, la capacité de l'elastic network interface sera affectée si vous avez plus de 40 000 combinaisons d'adresses IP et de ports uniques générant le trafic DNS.
# Haute disponibilité pour les points de terminaison Resolver
Lorsque vous créez les points de terminaison entrants de votre résolveur VPC, Route 53 exige que vous créiez au moins deux adresses IP auxquelles les résolveurs DNS de votre réseau transmettront les requêtes. Vous devez également spécifier les adresses IP dans au moins deux zones de disponibilité pour la redondance.
Si vous avez besoin que plus d'un point de terminaison d'Interface réseau Elastic soit disponible à tout moment, nous vous recommandons de créer au moins une interface réseau de plus que nécessaire, afin de vous assurer que vous disposez d'une capacité supplémentaire pour gérer d'éventuelles surtensions de trafic. L'interface réseau supplémentaire assure également la disponibilité pendant les opérations de service, telles que la maintenance ou les mises à niveau.
Pour plus d'informations, consultez cet article de blog détaillé : [Comment atteindre la haute disponibilité du DNS avec les points de terminaison Resolver](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) et. [Valeurs à spécifier lors de la création ou de la modification de points de terminaison entrants](resolver-forwarding-inbound-queries-values.md)
# Parcours de zone DNS
Une attaque du parcours de zone DNS tente d’obtenir tout le contenu des zones DNS signées par DNSSEC. Si l'équipe VPC Resolver détecte un modèle de trafic correspondant à ceux générés lorsque des zones DNS sont parcourues sur votre terminal, l'équipe de service limitera le trafic sur votre point de terminaison. Par conséquent, vous pouvez observer un pourcentage élevé de vos requêtes DNS expirer.
Si vous constatez une réduction de la capacité de vos terminaux et que vous pensez que le terminal a été limité par erreur, rendez-vous https://console.aws.amazon.com/support/ sur home\$1/ pour créer un dossier d'assistance.
# Bonnes pratiques relatives aux vérifications de l'état d'Amazon Route 53
Une configuration efficace des bilans de santé est essentielle pour maintenir une infrastructure hautement disponible et résiliente. Voici quelques bonnes pratiques à prendre en compte lors de la configuration et de la gestion des bilans de santé d'Amazon Route 53 :
1. **Utilisez des adresses IP élastiques pour les points de terminaison de contrôle de l'état :**
+ Utilisez des adresses IP élastiques pour vos points de terminaison de contrôle de santé afin de garantir une surveillance cohérente.
+ Si vous n'utilisez plus d'instance Amazon EC2, pensez à supprimer tous les bilans de santé associés afin d'éviter tout risque de sécurité ou toute compromission des données.
Pour plus d'informations, voir[Valeurs que vous spécifiez lors de la création ou de la mise à jour de surveillances de l'état](health-checks-creating-values.md).
1. **Configurez les intervalles de contrôle de santé appropriés :**
+ Définissez des intervalles de contrôle de santé en fonction des exigences de votre application et de la criticité des ressources surveillées.
+ Des intervalles plus courts permettent de détecter plus rapidement les défaillances, mais peuvent augmenter les coûts de la Route 53 et alourdir vos ressources.
+ Des intervalles plus longs réduisent les coûts et la charge de ressources, mais peuvent retarder la détection des défaillances.
Pour plus d'informations, voir[Configuration avancée (option « Monitor an endpoint » uniquement)](health-checks-creating-values.md#health-checks-creating-values-advanced).
1. **Implémenter les notifications d'alarme :**
+ Configurez Amazon CloudWatchalarms pour recevoir des notifications lorsque les tests de santé échouent ou se rétablissent.
+ Définissez des seuils d'alarme appropriés en fonction des exigences de votre application et du comportement attendu de vos ressources.
+ Intégrez les notifications à vos processus de surveillance et de réponse aux incidents.
Pour plus d'informations, voir[Surveillance des bilans de santé à l'aide CloudWatch](monitoring-health-checks.md).
1. **Utilisez les régions de bilan de santé de manière stratégique :**
+ Choisissez les régions de contrôle de santé en fonction de la répartition géographique de vos utilisateurs et de vos ressources.
+ Envisagez d'utiliser plusieurs régions de contrôle de santé pour les ressources critiques afin d'améliorer la fiabilité et de réduire l'impact des pannes régionales.
1. **Surveillez les journaux et les indicateurs des bilans de santé :**
+ Consultez régulièrement les journaux et CloudWatch indicateurs des bilans de santé de Route 53 pour identifier les problèmes potentiels ou les goulots d'étranglement liés aux performances
+ Analysez les raisons de l'échec du bilan de santé et prenez les mesures appropriées pour résoudre les problèmes sous-jacents.
1. **Mettez en œuvre des stratégies de basculement et de retour en arrière :**
+ Tirez parti des politiques de routage en cas de basculement de Route 53 pour acheminer automatiquement le trafic vers des ressources saines en cas de panne.
+ Planifiez et testez les processus de basculement et de reprise afin de garantir une transition fluide en cas de panne et de reprise.
Pour plus d'informations, voir[Configuration du basculement DNS](dns-failover-configuring.md).
1. **Passez régulièrement en revue et mettez à jour les bilans de santé :**
+ Mettez à jour les points de terminaison, les intervalles et les seuils d'alarme du bilan de santé selon les besoins afin de maintenir une surveillance et des performances optimales.
En suivant ces bonnes pratiques, vous pouvez exploiter efficacement les bilans de santé d'Amazon Route 53 pour surveiller l'état et la disponibilité de vos ressources, garantissant ainsi une infrastructure fiable et performante pour vos applications et services.