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.

# Configuration d'Amazon Route 53 en tant que service DNS
<a name="dns-configuring"></a>

Vous pouvez utiliser Amazon Route 53 en tant que service DNS pour votre domaine, par exemple, example.com. Lorsque Route 53 est votre service DNS, il achemine le trafic Internet vers votre site web en traduisant les noms de domaine descriptifs, tels que www.example.com, en adresses IP numériques, telles que 192.0.2.1, qui sont utilisées par les ordinateurs pour se connecter les uns aux autres. Lorsque quelqu'un entre votre nom de domaine dans un navigateur ou vous envoie un e-mail, une requête DNS est envoyée à Route 53, qui répond avec la valeur appropriée. Par exemple, Route 53 peut répondre avec l'adresse IP du serveur web pour example.com.

**Hébergement DNS ou enregistrement de domaine**  
Ce chapitre traite de l'utilisation de Route 53 pour l'*hébergement DNS uniquement*. Cela signifie que l'enregistrement de votre domaine reste auprès de votre bureau d'enregistrement actuel et que vous continuerez à le payer pour les renouvellements de domaines. Route 53 gérera uniquement vos paramètres DNS et les requêtes DNS pour votre domaine.  
Si vous souhaitez également transférer l'enregistrement de votre domaine vers Route 53 (faisant de Route 53 à la fois votre bureau d'enregistrement et votre service DNS), consultez [Liste de contrôle préalable au transfert pour les transferts de domaines](domain-transfer-checklist.md) et[Transfert d'un enregistrement de domaine vers Amazon Route 53](domain-transfer-to-route-53.md).

Dans ce chapitre, nous expliquons comment configurer Route 53 pour acheminer le trafic Internet vers les emplacements appropriés. Nous expliquons également comment migrer le service DNS vers Route 53 si vous utilisez actuellement un autre service DNS, et comment utiliser Route 53 en tant que service DNS pour un nouveau domaine. 

**Topics**
+ [Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existant](MigratingDNS.md)
+ [Configuration du routage DNS pour un nouveau domaine](dns-configuring-new-domain.md)
+ [Acheminement du trafic vers vos ressources](dns-routing-traffic-to-resources.md)
+ [Utilisation de zones hébergées](hosted-zones-working-with.md)
+ [Utilisation des enregistrements](rrsets-working-with.md)
+ [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md)
+ [Utilisation AWS Cloud Map pour créer des dossiers et des bilans de santé](autonaming.md)
+ [Contraintes et comportements DNS](DNSBehavior.md)
+ [Rubriques en relation](dns-configuring-related-topics.md)

# Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existant
<a name="MigratingDNS"></a>

Si vous transférez un ou plusieurs enregistrements de domaine vers Route 53, et que vous utilisez actuellement un bureau d'enregistrement de domaine qui ne fournit pas de service DNS payant, vous devez migrer le service DNS avant de migrer le domaine. Dans le cas contraire, le serveur d'inscription arrête de fournir le service DNS lorsque vous transférez vos domaines et les sites Web et applications Web associés deviennent indisponibles sur Internet. (Vous pouvez également migrer le service DNS à partir du bureau d'enregistrement actuel vers un autre fournisseur de services DNS. Vous n'êtes pas obligé d'utiliser Route 53 comme fournisseur de services DNS pour les domaines enregistrés avec Route 53.)

Le processus varie selon que vous utilisez actuellement le domaine :
+ Si le domaine reçoit actuellement du trafic (par exemple, si vos utilisateurs utilisent le nom de domaine pour naviguer sur un site web ou accéder à une application web), consultez [Configuration de Route 53 en tant que service DNS pour un domaine en cours d'utilisation](migrate-dns-domain-in-use.md).
+ Si le domaine ne reçoit aucun trafic (ou un trafic très limité), consultez [Configuration de Route 53 en tant que service DNS d'un domaine inactif](migrate-dns-domain-inactive.md).

Dans les deux cas, votre domaine doit rester disponible pendant toute la durée du processus de migration. Cependant, dans le cas peu probable où il y aurait des problèmes, la première option vous permet d'annuler rapidement la migration. Avec la deuxième option, votre domaine peut rester indisponible pendant quelques jours.

Si vous souhaitez entrer en contact avec un expert AWS, rendez-vous sur le site d'[assistance aux ventes](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs).

# Configuration de Route 53 en tant que service DNS pour un domaine en cours d'utilisation
<a name="migrate-dns-domain-in-use"></a>

Si vous souhaitez migrer le service DNS vers Amazon Route 53 pour un domaine qui reçoit actuellement du trafic (par exemple, si vos utilisateurs utilisent le nom de domaine pour naviguer sur un site web ou accéder à une application web), suivez les procédures décrites dans cette section.

**Topics**
+ [Étape 1 : Récupérer votre configuration DNS actuelle à partir du fournisseur de services DNS actuel (facultatif, mais recommandé)](#migrate-dns-get-zone-file)
+ [Étape 2 : Créer une zone hébergée](#migrate-dns-create-hosted-zone)
+ [Étape 3 : Créer des enregistrements](#migrate-dns-create-records)
+ [Étape 4 : Diminuer les paramètres de durée de vie (TTL)](#migrate-dns-lower-ttl)
+ [Étape 5 : (si vous avez configuré DNSSEC) supprimer le registre DS de la zone parent](#migrate-remove-ds)
+ [Étape 6 : attendre l'expiration de l'ancienne TTL](#migrate-dns-wait-for-ttl)
+ [Étape 7 : mettre à jour les registres NS pour utiliser les serveurs de noms Route 53](#migrate-dns-change-name-servers-with-provider)
+ [Étape 8 : Surveiller le trafic pour le domaine](#migrate-dns-monitor-traffic)
+ [Étape 9 : Modifier la durée de vie de l'enregistrement NS pour la rétablir à une valeur supérieure](#migrate-dns-change-ttl-back)
+ [Étape 10 : transférer un enregistrement de domaine vers Amazon Route 53](#migrate-dns-transfer-domain-registration)
+ [Étape 11 : réactiver la signature DNSSEC (si nécessaire)](#migrate-dns-re-enable-dnssec)

## Étape 1 : Récupérer votre configuration DNS actuelle à partir du fournisseur de services DNS actuel (facultatif, mais recommandé)
<a name="migrate-dns-get-zone-file"></a>

Lorsque vous migrez le service DNS d'un autre fournisseur vers Route 53, reproduisez votre configuration DNS actuelle dans Route 53. Dans Route 53, créez une zone hébergée qui porte le même nom que votre domaine et créez des registres dans la zone hébergée. Chaque enregistrement indique la façon dont vous allez acheminer le trafic pour un nom de domaine ou de sous-domaine spécifié. Par exemple, lorsque quelqu'un saisit votre nom de domaine dans un navigateur Web, souhaitez-vous que le trafic soit acheminé vers un serveur Web de votre centre de données, vers une instance Amazon EC2, vers CloudFront une distribution ou vers un autre emplacement ?

La procédure à suivre dépend de la complexité de votre configuration DNS actuelle :
+ **Si votre configuration DNS actuelle est simple** – Si vous acheminez du trafic Internet pour seulement quelques sous-domaines vers un nombre restreint de ressources, comme des serveurs web ou des compartiments Amazon S3, vous pouvez créer manuellement quelques registres dans la console Route 53.
+ ** Si votre configuration DNS actuelle est plus complexe, et si vous souhaitez simplement reproduire votre configuration actuelle** – Vous pouvez simplifier la migration en récupérant un fichier de zone auprès de votre fournisseur de services DNS actuel, puis importer le fichier de zone dans Route 53. (Tous les fournisseurs de services DNS ne proposent pas de fichiers de zone.) Lorsque vous importez un fichier de zone, Route 53 reproduit automatiquement la configuration existante en créant les registres correspondants dans votre zone hébergée.

  Demandez au service client de votre fournisseur de services DNS actuel comment obtenir un *fichier de zone* ou une *liste d'enregistrements*. Pour plus d'informations sur le format requis du fichier de zone, consultez [Création d'enregistrements par importation d'un fichier de zone](resource-record-sets-creating-import.md).
+ **Si votre configuration DNS actuelle est plus complexe, et si les fonctions de routage Route 53 vous intéressent** – Consultez la documentation ci-dessous pour déterminer si vous allez utiliser des fonctions Route 53 qui ne sont pas disponibles auprès d'autres fournisseurs de services DNS. Si tel est le cas, vous pouvez créer des enregistrements manuellement ou importer un fichier de zone, puis créer ou mettre à jour des enregistrements ultérieurement :
  + [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md)explique les avantages des enregistrements d'alias Route 53, qui acheminent gratuitement le trafic vers certaines AWS ressources, telles que les CloudFront distributions et les compartiments Amazon S3.
  + [Sélection d'une stratégie de routage](routing-policy.md) décrit les options de routage Route 53, par exemple, le routage en fonction de l'emplacement de vos utilisateurs, le routage en fonction de la latence entre vos utilisateurs et vos ressources, le routage en fonction de l'état de vos ressources et le routage vers des ressources en fonction des pondérations que vous spécifiez.
**Note**  
Vous pouvez également importer un fichier de zone et modifier ultérieurement votre configuration afin de tirer parti des enregistrements d'alias et des politiques de routage complexes.

Si vous ne parvenez pas à obtenir un fichier de zone ou si vous souhaitez créer manuellement des registres dans Route 53, les registres que vous êtes susceptible de migrer sont les suivants :
+ **Enregistrements A (Adresse)** : associez un nom de domaine ou un nom de sous-domaine à l' IPv4 adresse (par exemple, 192.0.2.3) de la ressource correspondante
+ **Enregistrements AAAA (adresse)** : associez un nom de domaine ou un nom de sous-domaine à l' IPv6 adresse (par exemple, 2001:0 db 8:85 a 3:0000:0000:abcd : 0001:2345) de la ressource correspondante
+ **Registres de serveur de mail (MX)** – Acheminez le trafic vers des serveurs de mail
+ **Registres CNAME** – Réacheminez le trafic d'un nom de domaine (example.net) vers un autre nom de domaine (example.com)
+ **Registres pour d'autres types de registres DNS pris en charge** – Pour obtenir la liste des types de registres pris en charge, consultez [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

## Étape 2 : Créer une zone hébergée
<a name="migrate-dns-create-hosted-zone"></a>

Pour indiquer à Amazon Route 53 la façon dont vous souhaitez acheminer le trafic pour votre domaine, créez une zone hébergée qui porte le même nom que votre domaine, puis créez des registres dans la zone hébergée. 

**Important**  
Vous pouvez créer une zone hébergée uniquement pour un domaine pour lequel vous disposez d'une autorisation d'administration. Généralement, cela signifie que le domaine vous appartient, mais il est également possible que vous développiez une application pour l'inscrit du domaine.

Lorsque vous créez une zone hébergée, Route 53 crée automatiquement un registre de serveur de noms (NS) et un registre de source de noms (SOA) pour la zone. Le registre NS identifie les quatre serveurs de noms que Route 53 a associés à votre zone hébergée. Pour configurer Route 53 en tant que service DNS de votre domaine, mettez à jour l'enregistrement du domaine afin qu'il utilise ces quatre serveurs de noms. 

**Important**  
Ne créez pas d'autre enregistrement NS (name server) ou SOA (start of authority) et ne supprimez pas les enregistrements NS et SOA existants. <a name="migrate-dns-create-hosted-zone-procedure"></a>

**Pour créer une zone hébergée**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Si vous découvrez Route 53, choisissez **Get started** (Mise en route) sous **DNS management** (Gestion DNS), puis **Create hosted zones** (Créer des zones hébergées).

   Si vous utilisez déjà Route 53, choisissez **Hosted zones** (Zones hébergées) dans le panneau de navigation, puis **Create hosted zones** (Créer des zones hébergées).

1. Dans le volet **Create hosted zone** (Créer une zone hébergée), saisissez un nom de domaine et, éventuellement, un commentaire. Pour plus d'informations sur un paramètre, ouvrez le panneau d'aide à droite.

   Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

1. Pour **Type**, acceptez la valeur par défaut de **Public hosted zone** (Zone hébergée publique).

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

## Étape 3 : Créer des enregistrements
<a name="migrate-dns-create-records"></a>

Après avoir créé une zone hébergée, vous devez créer dans cette zone hébergée des enregistrements qui définissent l'emplacement où vous souhaitez acheminer le trafic pour un domaine (exemple.com) ou un sous-domaine (www.exemple.com). Par exemple, si vous souhaitez acheminer le trafic pour example.com et www.example.com vers un serveur web sur une instance Amazon EC2, créez deux registres : un premier nommé example.com et un second nommé www.example.com. Dans chaque enregistrement, vous devez indiquer l'adresse IP de votre instance EC2.

Vous pouvez créer des enregistrements de diverses manières :

**Importer un fichier de zone**  
Il s'agit de la méthode la plus simple si vous avez obtenu un fichier de zone de votre service DNS actuel dans [Étape 1 : Récupérer votre configuration DNS actuelle à partir du fournisseur de services DNS actuel (facultatif, mais recommandé)](#migrate-dns-get-zone-file). Amazon Route 53 ne peut pas prédire à quel moment il doit créer des registres d'alias ou utiliser des types de routage particuliers (pondérés ou de basculement, par exemple). Par conséquent, si vous importez un fichier de zone, Route 53 crée des registres DNS standard en utilisant la politique de routage simple.  
Pour de plus amples informations, veuillez consulter [Création d'enregistrements par importation d'un fichier de zone](resource-record-sets-creating-import.md).

**Créer individuellement des enregistrements dans la console**  
Si vous n'avez pas obtenu de fichier de zone et si vous voulez simplement créer quelques registres avec une politique de routage simple pour commencer, vous pouvez créer les registres dans la console Route 53. Vous pouvez créer à la fois des enregistrements d'alias et des enregistrements sans alias.  
Pour plus d’informations, consultez les rubriques suivantes :  
+ [Sélection d'une stratégie de routage](routing-policy.md)
+ [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md)
+ [Création d'enregistrements à l'aide de la console Amazon Route 53](resource-record-sets-creating.md)

**Créer des enregistrements par programmation**  
Vous pouvez créer des enregistrements à l'aide AWS SDKs de AWS CLI l'un des AWS Tools for Windows PowerShell Pour plus d'informations, consultez la [documentation AWS](https://docs.aws.amazon.com/).  
Si vous utilisez un langage de programmation qui AWS ne fournit pas de SDK pour, vous pouvez également utiliser l'API Route 53. Pour plus d'informations, consultez la [référence d'API Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).

## Étape 4 : Diminuer les paramètres de durée de vie (TTL)
<a name="migrate-dns-lower-ttl"></a>

Le paramètre de durée de vie d'un enregistrement spécifie la durée pendant laquelle vous voulez que les résolveurs DNS mettent en cache l'enregistrement et utilisent les informations mises en cache. À la date d'expiration, un résolveur envoie une autre requête au fournisseur de services DNS d'un domaine afin d'obtenir les informations les plus récentes.

Le paramètre de durée de vie d'un enregistrement NS est de 172 800 secondes, soit deux jours. L'enregistrement NS répertorie les serveurs de noms que le système de noms de domaine (DNS) peut utiliser pour obtenir des informations sur la manière d'acheminer le trafic pour votre domaine. Le fait de réduire la TTL du registre NS, à la fois auprès de votre fournisseur de services DNS actuel et auprès d'Amazon Route 53, permet de réduire les temps d'arrêt de votre domaine si vous rencontrez un problème pendant la migration du DNS vers Route 53. Si vous ne réduisez pas la durée de vie, votre domaine risque d'être indisponible sur Internet pendant deux jours en cas de problème.

**Note**  
Certains résolveurs complets peuvent mettre en cache le TTL de l'enregistrement NS du serveur d'autorité parent. Par conséquent, le TTL des enregistrements NS enregistrés sur le serveur DNS officiel parent doit également être réduit.

Nous vous recommandons de modifier la durée de vie sur les enregistrements NS suivants :
+ Sur l'enregistrement NS dans la zone hébergée du fournisseur de services DNS actuel. (Votre fournisseur actuel peut utiliser une terminologie différente.)
+ Sur l'enregistrement NS dans la zone hébergée que vous avez créée dans [Étape 2 : Créer une zone hébergée](#migrate-dns-create-hosted-zone).<a name="migrate-dns-lower-ttl-current-provider-procedure"></a>

**Pour réduire le paramètre de durée de vie sur l'enregistrement NS avec le fournisseur de services DNS actuel**
+ Utilisez la méthode indiquée par votre fournisseur de services DNS actuel du domaine afin de modifier la durée de vie de l'enregistrement NS dans la zone hébergée de votre domaine.<a name="migrate-dns-lower-ttl-route-53-procedure"></a>

**Pour réduire le paramètre TTL du registre NS dans une zone hébergée Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le volet de navigation, sélectionnez **Hosted Zones (Zones hébergées)**.

1. Choisissez le nom de la zone hébergée.

1. Choisissez le registre NS, puis **Edit** (Modifier).

1. Modifiez la valeur du champ **TTL (Seconds) (Durée de vie (secondes))**. Nous vous recommandons de spécifier une valeur comprise entre 60 secondes et 900 secondes (15 minutes).

1. Sélectionnez **Enregistrer les modifications**.

## Étape 5 : (si vous avez configuré DNSSEC) supprimer le registre DS de la zone parent
<a name="migrate-remove-ds"></a>

Si vous avez configuré DNSSEC pour votre domaine, supprimez le registre Delegation Signer (DS) de la zone parent avant de migrer votre domaine vers Route 53. 

Si la zone parent est hébergée via Route 53 ou un autre bureau d'enregistrement, contactez-les pour supprimer l'enregistrement DS.

 Comme il n'est actuellement pas possible d'activer la signature DNSSEC sur deux fournisseurs, vous devez supprimer tout DS ou DNSKEYs désactiver le DNSSEC. Cela indique temporairement aux résolveurs DNS de désactiver la validation DNSSEC. Lors de l'[étape 11](#migrate-dns-re-enable-dnssec), vous pouvez réactiver la validation DNSSEC si vous le souhaitez, une fois la transition vers Route 53 terminée.

Pour de plus amples informations, veuillez consulter [Suppression de clés publiques pour un domaine](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys).

## Étape 6 : attendre l'expiration de l'ancienne TTL
<a name="migrate-dns-wait-for-ttl"></a>

Si votre domaine est en cours d'utilisation (par exemple, si vos utilisateurs utilisent le nom de domaine pour naviguer sur un site web ou accéder à une application web), cela signifie que les résolveurs DNS ont mis en cache les noms des serveurs de noms qui ont été fournis par votre fournisseur de services DNS actuel. Un résolveur DNS qui a mis en cache ces informations il y a quelques minutes les conservera pendant près de deux jours.

Pour vous assurer que la migration du service DNS vers Route 53 s'exécute en une seule fois, attendez deux jours après avoir réduit la TTL. Une fois ce délai de deux jours passé et une fois que les résolveurs ont demandé les serveurs de noms pour votre domaine, les résolveurs obtiendront les serveurs de noms actuels ainsi que la nouvelle durée de vie que vous avez spécifiée dans [Étape 4 : Diminuer les paramètres de durée de vie (TTL)](#migrate-dns-lower-ttl).

## Étape 7 : mettre à jour les registres NS pour utiliser les serveurs de noms Route 53
<a name="migrate-dns-change-name-servers-with-provider"></a>

Pour commencer à utiliser Amazon Route 53 en tant que service DNS pour un domaine, utilisez la méthode fournie par le bureau d'enregistrement, ou la zone parent, pour remplacer les serveurs de noms actuels dans le registre NS par des serveurs de noms Route 53.

**Note**  
Lorsque vous mettez à jour le registre NS avec le fournisseur de services DNS actuel pour utiliser des serveurs de noms Route 53, vous mettez à jour la configuration DNS pour le domaine. (Cela revient à mettre à jour le registre NS de la zone hébergée Route 53 pour un domaine, sauf que vous mettez à jour le paramètre avec le service DNS depuis lequel vous effectuez la migration.) <a name="migrate-dns-change-name-servers-with-provider-procedure"></a>

**Pour mettre à jour le registre NS au niveau du bureau d'enregistrement, ou de la zone parent, afin d'utiliser les serveurs de noms Route 53**

1. Dans la console Route 53, récupérez les serveurs de noms pour votre zone hébergée :

   1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

   1. Dans le panneau de navigation, choisissez **Zones hébergées**.

   1. Sur la page **Hosted zones** (Zones hébergées), choisissez le nom de la zone hébergée concernée.

   1. Prenez note des quatre noms répertoriés dans **Name servers** (Serveurs de noms) dans la section **Hosted zone details** (Détails de la zone hébergée).

1. Utilisez la méthode indiquée par le service DNS actuel du domaine pour mettre à jour l'enregistrement NS pour la zone hébergée. Si le domaine est enregistré auprès de Route 53, consultez [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md). Le processus varie selon que le service DNS actuel vous permet ou non de supprimer des serveurs de noms :

   **Si vous pouvez supprimer des serveurs de noms**
   + Notez les noms des serveurs de noms actuels dans l'enregistrement NS pour la zone hébergée. Si vous avez besoin de rétablir la configuration DNS actuelle, il s'agit des serveurs que vous allez spécifier.
   + Supprimez les serveurs de noms actuels de l'enregistrement NS. 
   + Mettez à jour le registre NS avec les noms des quatre serveurs de noms Route 53 que vous avez obtenus lors de l'étape 1 de cette procédure.
**Note**  
Lorsque vous avez terminé, les seuls serveurs de noms du registre NS seront les quatre serveurs de noms Route 53.

   **Si vous ne pouvez pas supprimer les serveurs de noms**
   + Choisissez l'option permettant d'utiliser des serveurs de noms personnalisés.
   + Ajoutez les quatre serveurs de noms Route 53 que vous avez obtenus lors de l'étape 1 de cette procédure. 

## Étape 8 : Surveiller le trafic pour le domaine
<a name="migrate-dns-monitor-traffic"></a>

Surveillez le trafic pour le domaine, y compris le trafic du site Web ou de l'application et la messagerie :
+ **Si le trafic ralentit ou s'interrompt** – Utilisez la méthode indiquée par le précédent service DNS pour rétablir les serveurs de noms précédents du domaine. Il s'agit des serveurs de noms que vous avez notés à l'étape 7 de [Pour mettre à jour le registre NS au niveau du bureau d'enregistrement, ou de la zone parent, afin d'utiliser les serveurs de noms Route 53](#migrate-dns-change-name-servers-with-provider-procedure). Déterminez ce qui s'est mal passé.
+ **Si le trafic n'est pas affecté** – Passez à [Étape 9 : Modifier la durée de vie de l'enregistrement NS pour la rétablir à une valeur supérieure](#migrate-dns-change-ttl-back).

## Étape 9 : Modifier la durée de vie de l'enregistrement NS pour la rétablir à une valeur supérieure
<a name="migrate-dns-change-ttl-back"></a>

Dans la zone hébergée Amazon Route 53 du domaine, modifiez la TTL du registre NS en utilisant une valeur plus classique, par exemple 172 800 secondes (deux jours). Cette étape permet d'améliorer la latence pour vos utilisateurs car ils n'auront plus besoin d'attendre aussi souvent que les résolveurs DNS envoient une requête pour les serveurs de noms de votre domaine.<a name="migrate-dns-change-ttl-back-procedure"></a>

**Pour modifier la TTL du registre NS dans la zone hébergée Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le volet de navigation, sélectionnez **Hosted Zones (Zones hébergées)**.

1. Choisissez le nom de la zone hébergée.

1. Dans la liste des enregistrements de la zone hébergée, sélectionnez l'enregistrement NS.

1. Choisissez **Edit (Modifier)**.

1. Modifiez la valeur du champ **TTL (Seconds) (Durée de vie (secondes))** en indiquant le nombre de secondes pendant lequel vous voulez que les résolveurs DNS mettent en cache les noms des serveurs de noms de votre domaine. Nous vous recommandons une valeur de 172 800 secondes.

1. Sélectionnez **Enregistrer les modifications**.

## Étape 10 : transférer un enregistrement de domaine vers Amazon Route 53
<a name="migrate-dns-transfer-domain-registration"></a>

Maintenant que vous avez transféré le service DNS d'un domaine vers Amazon Route 53, vous pouvez éventuellement transférer l'enregistrement du domaine vers Route 53. Pour de plus amples informations, veuillez consulter [Transfert d'un enregistrement de domaine vers Amazon Route 53](domain-transfer-to-route-53.md).

## Étape 11 : réactiver la signature DNSSEC (si nécessaire)
<a name="migrate-dns-re-enable-dnssec"></a>

Maintenant que vous avez transféré le service DNS d'un domaine vers Amazon Route 53, vous pouvez réactiver la signature DNSSEC.

La signature DNSSEC s'active en deux étapes : 
+ Étape 1 : Activez la signature DNSSEC pour Route 53 et demandez à Route 53 de créer une clé de signature (KSK) basée sur une clé gérée par le client dans AWS Key Management Service ().AWS KMS
+ Étape 2 : créez une chaîne d'approbation pour la zone hébergée en ajoutant un registre Delegation Signer (DS) à la zone parent, afin que les réponses DNS puissent être authentifiées avec des signatures de chiffrement fiables.

  Pour obtenir des instructions, veuillez consulter [Activation de la signature DNSSEC et établissement d'une chaîne d'approbation](dns-configuring-dnssec-enable-signing.md).

# Configuration de Route 53 en tant que service DNS d'un domaine inactif
<a name="migrate-dns-domain-inactive"></a>

Si vous souhaitez migrer le service DNS vers Amazon Route 53 pour un domaine qui ne reçoit aucun trafic (ou très peu de trafic), suivez les procédures décrites dans cette section.

**Topics**
+ [Étape 1 : Récupérer votre configuration DNS actuelle à partir du fournisseur de services DNS actuel (domaines inactifs)](#migrate-dns-get-zone-file-domain-inactive)
+ [Étape 2 : Créer une zone hébergée (domaines inactifs)](#migrate-dns-create-hosted-zone-domain-inactive)
+ [Étape 3 : Créer des enregistrements (domaines inactifs)](#migrate-dns-create-records-domain-inactive)
+ [Étape 4 : mettre à jour l'enregistrement de domaine pour utiliser les serveurs de noms Amazon Route 53 (domaines inactifs)](#migrate-dns-update-domain-inactive)

## Étape 1 : Récupérer votre configuration DNS actuelle à partir du fournisseur de services DNS actuel (domaines inactifs)
<a name="migrate-dns-get-zone-file-domain-inactive"></a>

Lorsque vous migrez le service DNS d'un autre fournisseur vers Route 53, reproduisez votre configuration DNS actuelle dans Route 53. Dans Route 53, créez une zone hébergée qui porte le même nom que votre domaine et créez des registres dans la zone hébergée. Chaque enregistrement indique la façon dont vous allez acheminer le trafic pour un nom de domaine ou de sous-domaine spécifié. Par exemple, lorsque quelqu'un saisit votre nom de domaine dans un navigateur Web, souhaitez-vous que le trafic soit acheminé vers un serveur Web de votre centre de données, vers une instance Amazon EC2, vers CloudFront une distribution ou vers un autre emplacement ?

La procédure à suivre dépend de la complexité de votre configuration DNS actuelle :
+ **Si votre configuration DNS actuelle est simple** – Si vous acheminez du trafic Internet pour seulement quelques sous-domaines vers un nombre restreint de ressources, comme des serveurs web ou des compartiments Amazon S3, vous pouvez créer manuellement quelques registres dans la console Route 53.
+ ** Si votre configuration DNS actuelle est plus complexe, et si vous souhaitez simplement reproduire votre configuration actuelle** – Vous pouvez simplifier la migration en récupérant un fichier de zone auprès de votre fournisseur de services DNS actuel, puis importer le fichier de zone dans Route 53. (Tous les fournisseurs de services DNS ne proposent pas de fichiers de zone.) Lorsque vous importez un fichier de zone, Route 53 reproduit automatiquement la configuration existante en créant les registres correspondants dans votre zone hébergée.

  Demandez au service client de votre fournisseur de services DNS actuel comment obtenir un *fichier de zone* ou une *liste d'enregistrements*. Pour plus d'informations sur le format requis du fichier de zone, consultez [Création d'enregistrements par importation d'un fichier de zone](resource-record-sets-creating-import.md).
+ **Si votre configuration DNS actuelle est plus complexe, et si les fonctions de routage Route 53 vous intéressent** – Consultez la documentation ci-dessous pour déterminer si vous allez utiliser des fonctions Route 53 qui ne sont pas disponibles auprès d'autres fournisseurs de services DNS. Si tel est le cas, vous pouvez créer des enregistrements manuellement ou importer un fichier de zone, puis créer ou mettre à jour des enregistrements ultérieurement :
  + [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md)explique les avantages des enregistrements d'alias Route 53, qui acheminent gratuitement le trafic vers certaines AWS ressources, telles que les CloudFront distributions et les compartiments Amazon S3.
  + [Sélection d'une stratégie de routage](routing-policy.md) décrit les options de routage Route 53, par exemple, le routage en fonction de l'emplacement de vos utilisateurs, le routage en fonction de la latence entre vos utilisateurs et vos ressources, le routage en fonction de l'état de vos ressources et le routage vers des ressources en fonction des pondérations que vous spécifiez.
**Note**  
Vous pouvez également importer un fichier de zone et modifier ultérieurement votre configuration afin de tirer parti des enregistrements d'alias et des politiques de routage complexes.

Si vous ne parvenez pas à obtenir un fichier de zone ou si vous souhaitez créer manuellement des registres dans Route 53, les registres que vous êtes susceptible de migrer sont les suivants :
+ **Enregistrements A (Adresse)** : associez un nom de domaine ou un nom de sous-domaine à l' IPv4 adresse (par exemple, 192.0.2.3) de la ressource correspondante
+ **Enregistrements AAAA (adresse)** : associez un nom de domaine ou un nom de sous-domaine à l' IPv6 adresse (par exemple, 2001:0 db 8:85 a 3:0000:0000:abcd : 0001:2345) de la ressource correspondante
+ **Registres de serveur de mail (MX)** – Acheminez le trafic vers des serveurs de mail
+ **Registres CNAME** – Réacheminez le trafic d'un nom de domaine (example.net) vers un autre nom de domaine (example.com)
+ **Registres pour d'autres types de registres DNS pris en charge** – Pour obtenir la liste des types de registres pris en charge, consultez [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

## Étape 2 : Créer une zone hébergée (domaines inactifs)
<a name="migrate-dns-create-hosted-zone-domain-inactive"></a>

Pour indiquer à Amazon Route 53 la façon dont vous souhaitez acheminer le trafic pour votre domaine, créez une zone hébergée qui porte le même nom que votre domaine, puis créez des registres dans la zone hébergée. 

**Important**  
Vous pouvez créer une zone hébergée uniquement pour un domaine pour lequel vous disposez d'une autorisation d'administration. Généralement, cela signifie que le domaine vous appartient, mais il est également possible que vous développiez une application pour l'inscrit du domaine.

Lorsque vous créez une zone hébergée, Route 53 crée automatiquement un registre de serveur de noms (NS) et un registre de source de noms (SOA) pour la zone. Le registre NS identifie les quatre serveurs de noms que Route 53 a associés à votre zone hébergée. Pour configurer Route 53 en tant que service DNS de votre domaine, mettez à jour l'enregistrement du domaine afin qu'il utilise ces quatre serveurs de noms. 

**Important**  
Ne créez pas d'autre enregistrement NS (name server) ou SOA (start of authority) et ne supprimez pas les enregistrements NS et SOA existants. <a name="migrate-dns-create-hosted-zone-procedure"></a>

**Pour créer une zone hébergée**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Si vous débutez avec Route 53, choisissez **Get started** (Mise en route).

   Si vous utilisez déjà Route 53, choisissez **Hosted Zones** (Zones hébergées) dans le panneau de navigation.

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

1. Dans le volet **Create hosted zone** (Créer une zone hébergée), saisissez un nom de domaine et, éventuellement, un commentaire. Pour plus d'informations sur un paramètre, arrêtez le pointeur de la souris sur son étiquette pour afficher une info-bulle.

   Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

1. Pour **Record type** (Type de registre), acceptez la valeur par défaut de **Public hosted zone** (Zone hébergée publique).

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

## Étape 3 : Créer des enregistrements (domaines inactifs)
<a name="migrate-dns-create-records-domain-inactive"></a>

Après avoir créé une zone hébergée, vous devez créer dans cette zone des enregistrements qui définissent l'emplacement où vous souhaitez acheminer le trafic pour un domaine (exemple.com) ou un sous-domaine (www.exemple.com). Par exemple, si vous souhaitez acheminer le trafic pour example.com et www.example.com vers un serveur web sur une instance Amazon EC2, créez deux registres : un premier nommé example.com et un second nommé www.example.com. Dans chaque enregistrement, vous devez indiquer l'adresse IP de votre instance EC2.

Vous pouvez créer des enregistrements de diverses manières :

**Importer un fichier de zone**  
Il s'agit de la méthode la plus simple si vous avez obtenu un fichier de zone de votre service DNS actuel dans [Étape 1 : Récupérer votre configuration DNS actuelle à partir du fournisseur de services DNS actuel (domaines inactifs)](#migrate-dns-get-zone-file-domain-inactive). Amazon Route 53 ne peut pas prédire à quel moment il doit créer des registres d'alias ou utiliser des types de routage particuliers (pondérés ou de basculement, par exemple). Par conséquent, si vous importez un fichier de zone, Route 53 crée des registres DNS standard en utilisant la politique de routage simple.  
Pour de plus amples informations, veuillez consulter [Création d'enregistrements par importation d'un fichier de zone](resource-record-sets-creating-import.md).

**Créer individuellement des enregistrements dans la console**  
Si vous n'avez pas obtenu de fichier de zone et si vous voulez simplement créer quelques registres avec une politique de routage simple pour commencer, vous pouvez créer les registres dans la console Route 53. Vous pouvez créer à la fois des enregistrements d'alias et des enregistrements sans alias.  
Pour plus d’informations, consultez les rubriques suivantes :  
+ [Sélection d'une stratégie de routage](routing-policy.md)
+ [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md)
+ [Création d'enregistrements à l'aide de la console Amazon Route 53](resource-record-sets-creating.md)

**Créer des enregistrements par programmation**  
Vous pouvez créer des enregistrements à l'aide AWS SDKs de AWS CLI l'un des AWS Tools for Windows PowerShell Pour plus d'informations, consultez la [documentation AWS](https://docs.aws.amazon.com/).  
Si vous utilisez un langage de programmation qui AWS ne fournit pas de SDK pour, vous pouvez également utiliser l'API Route 53. Pour plus d'informations, consultez la [référence d'API Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).

## Étape 4 : mettre à jour l'enregistrement de domaine pour utiliser les serveurs de noms Amazon Route 53 (domaines inactifs)
<a name="migrate-dns-update-domain-inactive"></a>

Lorsque vous avez terminé de créer des registres pour le domaine, vous pouvez modifier le service DNS de votre domaine pour le configurer sur Amazon Route 53. Exécutez la procédure suivante pour mettre à jour les paramètres auprès du serveur d'inscriptions de domaine.<a name="migrate-dns-update-domain-inactive-procedure"></a>

**Pour mettre à jour les serveurs de noms du domaine**

1. Dans la console Route 53, récupérez les serveurs de noms pour votre zone hébergée Route 53 :

   1. Ouvrez la console Route 53 à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

   1. Dans le panneau de navigation, choisissez **Zones hébergées**.

   1. Sur la page **Hosted zones** (Zones hébergées), choisissez la case d'option (pas le nom) de la zone hébergée, puis **View details** (Afficher les détails).

   1. Sur la page des détails de la zone hébergée, choisissez **Hosted zone details** (Détails de la zone hébergée).

   1. Notez les quatre serveurs répertoriés dans **Name servers** (Serveurs de noms).

1. Utilisez la méthode indiquée par le bureau d'enregistrement du domaine pour remplacer les serveurs de noms du domaine afin d'utiliser les quatre serveurs de noms Route 53 obtenus lors de l'étape 2 de cette procédure.

   Si le domaine est enregistré auprès de Route 53, consultez [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md).

# Configuration du routage DNS pour un nouveau domaine
<a name="dns-configuring-new-domain"></a>

**Un nouveau domaine que vous avez acheté auprès de Route 53**  
Lorsque vous enregistrez un domaine avec Route 53, ce dernier est automatiquement configuré en tant que service DNS pour le domaine. Route 53 crée une zone hébergée portant le même nom que le domaine, affecte quatre serveurs de noms à la zone hébergée, et met à jour le domaine pour utiliser les serveurs de noms.

**Un nouveau domaine que vous avez acheté auprès d'un autre bureau d'enregistrement**  
Lorsque vous achetez un domaine auprès d'un autre bureau d'enregistrement, par exemple, parce que le domaine de premier niveau (TLD) n'est pas proposé par Route 53, vous avez deux options :
+ **Utilisez Route 53 pour l'hébergement DNS uniquement :** conservez votre bureau d'enregistrement actuel mais déléguez la gestion du DNS à Route 53. Suivez la procédure ci-dessous pour créer une zone hébergée et mettre à jour les serveurs de noms de votre bureau d'enregistrement.
+ **Transférez l'enregistrement du domaine vers Route 53 :** faites de Route 53 votre bureau d'enregistrement et votre service DNS. Consultez [Liste de contrôle préalable au transfert pour les transferts de domaines](domain-transfer-checklist.md) les conditions préalables et le processus [Transfert d'un enregistrement de domaine vers Amazon Route 53](domain-transfer-to-route-53.md) de transfert.

Pour plus d'informations sur la TLDs prise en charge par Route 53, consultez[Domaines que vous pouvez vous enregistrer avec Amazon Route 53](registrar-tld-list.md).

Suivez ces instructions pour créer une zone hébergée publique, puis utilisez les serveurs de noms créés avec le bureau d'enregistrement :<a name="dns-configuring-create-hosted-zone-for-different-registrar"></a>

**Pour créer une zone hébergée pour un domaine autre que Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**, puis choisissez **Créer une zone hébergée**.

1. Pour le **nom**, entrez le nom du domaine pour lequel vous souhaitez créer une zone hébergée, par exemple`example.com`, une description facultative, choisissez **Zone hébergée publique** puis **Créer une zone hébergée**.

1. Après avoir créé la zone hébergée, notez les quatre enregistrements de serveur de noms (NS) qui ont été créés. Chacune d'entre elles commencera par « ns- ».

   Dans votre bureau d'enregistrement de domaines, entrez les serveurs de noms ci-dessus pour déléguer la gestion des domaines à votre zone hébergée Route 53.

**Acheminer le trafic DNS**  
Pour spécifier la façon dont vous voulez que Route 53 achemine le trafic Internet pour le domaine, créez des registres dans la zone hébergée. Par exemple, si vous souhaitez acheminer des demandes pour exemple.com vers un serveur Web exécuté sur une EC2 instance Amazon, vous créez un enregistrement dans la zone hébergée exemple.com et vous spécifiez l'adresse IP élastique de l' EC2 instance. Pour plus d’informations, consultez les rubriques suivantes :
+ Pour plus d'informations sur la création de registres dans votre zone hébergée, consultez [Utilisation des enregistrements](rrsets-working-with.md).
+ Pour plus d'informations sur la manière d'acheminer le trafic vers AWS des ressources sélectionnées, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).
+ Pour en savoir plus sur le fonctionnement de DNS, consultez [Acheminement du trafic Internet vers votre site web ou votre application web](welcome-dns-service.md).
+ Pour vérifier le repos du DNS, voir[Vérification des réponses DNS à partir de Route 53](dns-test.md).

# Acheminement du trafic vers vos ressources
<a name="dns-routing-traffic-to-resources"></a>

Lorsque les utilisateurs font une demande à votre site web ou application web, par exemple, en saisissant le nom de votre domaine dans un navigateur web, Amazon Route 53 achemine les utilisateurs vers vos ressources, telles qu'un compartiment Amazon S3 ou un serveur web dans votre centre de données. Pour configurer Route 53 pour qu'il achemine le trafic vers vos ressources, procédez comme suit :

1. Créez une zone hébergée. Vous pouvez créer une zone hébergée publique ou une zone hébergée privée :  
**Zone hébergée publique**  
Créez une zone hébergée publique si vous souhaitez acheminer le trafic Internet vers vos ressources, par exemple pour permettre à vos clients d'afficher le site Web de l'entreprise que vous hébergez sur des instances EC2. Pour de plus amples informations, veuillez consulter [Utilisation des zones hébergées publiques](AboutHZWorkingWith.md).  
**Zone hébergée privée**  
Créez une zone hébergée privée si vous souhaitez acheminer le trafic au sein d'un VPC Amazon. Pour de plus amples informations, veuillez consulter [Utilisation des zones hébergées privées](hosted-zones-private.md).

1. Créez des enregistrements dans la zone hébergée. Les enregistrements définissent l'endroit où vous souhaitez acheminer le trafic pour chaque nom de domaine ou sous-domaine. Par exemple, pour acheminer le trafic de www.exemple.com vers un serveur web de votre centre de données, vous devez généralement créer un enregistrement www.exemple.com dans la zone hébergée exemple.com. 

   Pour plus d’informations, consultez les rubriques suivantes :
   + [Utilisation des enregistrements](rrsets-working-with.md)
   + [Acheminement du trafic pour les sous-domaines](dns-routing-traffic-for-subdomains.md)
   + [Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md)

# Acheminement du trafic pour les sous-domaines
<a name="dns-routing-traffic-for-subdomains"></a>

Si vous souhaitez acheminer le trafic vers vos ressources pour un sous-domaine, par exemple acme.exemple.com ou zenith.exemple.com, deux options s'offrent à vous :

**Création d'enregistrements dans la zone hébergée du domaine**  
En règle générale, pour acheminer le trafic pour un sous-domaine, vous devez créer un enregistrement dans la zone hébergée qui porte le même nom que le domaine. Par exemple, pour acheminer le trafic Internet pour acme.exemple.com vers un serveur Web de votre centre de données, vous devez créer un enregistrement nommé acme.exemple.com dans la zone hébergée www.exemple.com. Pour de plus amples informations, veuillez consulter la rubrique [Utilisation des enregistrements](rrsets-working-with.md) et ses sous-rubriques.

**Création d'une zone hébergée pour le sous-domaine et création d'enregistrements dans la nouvelle zone hébergée**  
Vous pouvez également créer une zone hébergée pour le sous-domaine. L'utilisation d'une zone hébergée distincte pour acheminer le trafic Internet pour un sous-domaine est appelée parfois « déléguer la responsabilité d'un sous-domaine à une zone hébergée » ou « déléguer la responsabilité d'un sous-domaine à d'autres serveurs de noms », ou une combinaison de termes similaires. Voici comment cela fonctionne :  

1. Vous créez une zone hébergée portant le même nom que le sous-domaine pour lequel vous souhaitez acheminer le trafic, par exemple acme.exemple.com.

1. Vous créez des enregistrements dans la nouvelle zone hébergée qui définissent la façon dont vous souhaitez acheminer le trafic pour le sous-domaine (acme.exemple.com) et ses sous-domaines, par exemple backend.acme.exemple.com. 

1. Vous obtenez les serveurs de noms affectés par Route 53 à la nouvelle zone hébergée lors de sa création.

1. Vous créez un nouvel enregistrement NS dans la zone hébergée du domaine (exemple.com). Le nom de l'enregistrement NS doit être le nom du sous-domaine (acme.example.com), et vous spécifiez les quatre serveurs de noms que vous avez obtenus à l'étape 3 comme valeurs d'enregistrement.
Lorsque vous utilisez une zone hébergée distincte dans le but d'acheminer le trafic pour un sous-domaine, vous pouvez utiliser des autorisations IAM pour limiter l'accès à la zone hébergée du sous-domaine. Si vous disposez de plusieurs sous-domaines et qu'ils sont gérés par différents groupes, le fait de créer une zone hébergée pour chaque sous-domaine peut réduire considérablement le nombre de personnes devant avoir accès aux enregistrements dans la zone hébergée du domaine.  
Pour implémenter ce processus de délégation, vous devez disposer des autorisations IAM suivantes. Pour plus d'informations sur les politiques IAM de Route 53, consultez [Identity and Access Management dans Amazon Route 53](security-iam.md) :    
**Compte parent (propriétaire de example.com)**  
L'utilisateur ou le rôle a besoin d'autorisations pour modifier les enregistrements dans la zone hébergée du domaine parent :  
**Compte enfant (crée acme.example.com)**  
L'utilisateur ou le rôle a besoin d'autorisations pour créer et gérer la zone hébergée du sous-domaine :
L'utilisation d'une zone hébergée distincte pour un sous-domaine vous permet également d'utiliser des services DNS différents pour le domaine et le sous-domaine. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 comme service DNS pour des sous-domaines sans migration du domaine parent](creating-migrating.md).  
Cette configuration a un léger impact sur les performances de la première requête DNS de chaque résolveur DNS. Le résolveur doit obtenir des informations auprès de la zone hébergée du domaine racine, puis auprès de la zone hébergée du sous-domaine. À l'issue de la première requête DNS pour un sous-domaine, le résolveur met les informations en cache et n'a plus pas besoin de les obtenir tant que la durée de vie (TTL) n'a pas expiré et qu'un autre client n'a pas demandé le sous-domaine à ce résolveur. Pour plus d'informations, veuillez consulter [TTL (secondes)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) dans la section [Valeurs à spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53](resource-record-sets-values.md).

**Topics**
+ [Création d'une autre zone hébergée pour acheminer le trafic pour un sous-domaine](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [Acheminement du trafic pour d'autres niveaux de sous-domaines](#dns-routing-traffic-for-sub-subdomains)

## Création d'une autre zone hébergée pour acheminer le trafic pour un sous-domaine
<a name="dns-routing-traffic-for-subdomains-new-hosted-zone"></a>

Un moyen d'acheminer le trafic pour un sous-domaine est de créer une zone hébergée pour celui-ci et de créer dans la zone hébergée des enregistrements pour le sous-domaine. (La solution la plus courante consiste à créer des enregistrements pour le sous-domaine dans la zone hébergée du domaine.)

**Note**  
Cette procédure montre comment déléguer un sous-domaine à Route 53. Vous pouvez également déléguer un sous-domaine à d'autres services DNS en créant des enregistrements NS qui pointent plutôt vers les serveurs de noms de ces services.

Voici la procédure générale :

1. Créez une zone hébergée pour le sous-domaine. Pour de plus amples informations, veuillez consulter [Création d'une zone hébergée pour un sous-domaine](#dns-routing-traffic-for-subdomains-creating-hosted-zone). 

1. Ajoutez des enregistrements à la zone hébergée du sous-domaine. Si la zone hébergée du domaine contient des enregistrements qui appartiennent à la zone hébergée du sous-domaine, dupliquez ces enregistrements dans la zone hébergée pour le sous-domaine. Pour de plus amples informations, veuillez consulter [Création d'enregistrements dans la zone hébergée du sous-domaine](#dns-routing-traffic-for-subdomains-creating-records). 

1. Créez un enregistrement NS pour le sous-domaine dans la zone hébergée du domaine, ce qui délègue la responsabilité du sous-domaine aux serveurs de noms de la nouvelle zone hébergée. Si la zone hébergée du domaine contient des enregistrements qui appartiennent à la zone hébergée du sous-domaine, supprimez ces enregistrements de la zone hébergée du domaine. (Vous avez créé des copies dans la zone hébergée du sous-domaine à l'étape 2.) Pour de plus amples informations, veuillez consulter [Mise à jour de la zone hébergée du domaine](#dns-routing-traffic-for-subdomains-delegating-responsibility).

### Création d'une zone hébergée pour un sous-domaine
<a name="dns-routing-traffic-for-subdomains-creating-hosted-zone"></a>

Pour créer une zone hébergée pour un sous-domaine à l'aide de la console Route 53, exécutez la procédure suivante.

**Pour créer une zone hébergée pour un sous-domaine (console)**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Si vous débutez avec Route 53, choisissez **Get started** (Mise en route). 

   Si vous utilisez déjà Route 53, choisissez **Hosted Zones** (Zones hébergées) dans le panneau de navigation. 

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

1. Dans le volet droit, entrez le nom du sous-domaine, par exemple acme.example.com. Vous pouvez également entrer un commentaire facultatif.

   Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

1. Pour **Type**, acceptez la valeur par défaut de **Public hosted zone** (Zone hébergée publique).

1. En bas du volet droit, choisissez **Create hosted zone** (Créer une zone hébergée).

### Création d'enregistrements dans la zone hébergée du sous-domaine
<a name="dns-routing-traffic-for-subdomains-creating-records"></a>

Pour définir la façon dont Route 53 doit acheminer le trafic pour le sous-domaine (acme.example.com) et ses sous-domaines (backend.acme.example.com), créez des registres dans la zone hébergée du sous-domaine.

Notez les points suivants à propos de la création d'enregistrements dans la zone hébergée du sous-domaine :
+ Ne créez pas d'enregistrements de serveur de noms (NS) ou de source de noms (SOA) supplémentaires dans la zone hébergée du sous-domaine et ne supprimez pas les enregistrements NS et SOA existants.
+ Créez tous les enregistrements pour le sous-domaine dans la zone hébergée du sous-domaine. Par exemple, si vous disposez de zones hébergées pour example.com et pour le domaine acme.example.com, créez tous les enregistrements pour le sous-domaine acme.example.com dans la zone hébergée acme.example.com. Cela inclut les enregistrements tels que backend.acme.example.com et beta.backend.acme.example.com.
+ Si la zone hébergée du domaine (example.com) contient déjà des enregistrements qui appartiennent à la zone hébergée du sous-domaine (acme.example.com), dupliquez ces enregistrements dans la zone hébergée du sous-domaine. Dans la dernière étape du processus, vous supprimerez les enregistrements en double de la zone hébergée du domaine ultérieurement.
**Important**  
Si certains enregistrements pour le sous-domaine figurent à la fois dans la zone hébergée du domaine et la zone hébergée du sous-domaine, le comportement DNS sera incohérent. Le comportement dépendra des serveurs de noms qu'un résolveur DNS a mis en cache, des serveurs de noms pour la zone hébergée du domaine (example.com) ou des serveurs de noms pour la zone hébergée du sous-domaine (acme.example.com). Dans certains cas, Route 53 renvoie une réponse NXDOMAIN (domaine inexistant) lorsque l'enregistrement existe, mais pas dans la zone hébergée à laquelle les résolveurs DNS envoient la demande.

Pour de plus amples informations, veuillez consulter [Utilisation des enregistrements](rrsets-working-with.md).

### Mise à jour de la zone hébergée du domaine
<a name="dns-routing-traffic-for-subdomains-delegating-responsibility"></a>

Lorsque vous créez une zone hébergée, Route 53 lui affecte automatiquement quatre serveurs de noms. L'enregistrement NS pour la zone hébergée identifie les serveurs de noms qui répondent aux requêtes DNS pour le domaine ou le sous-domaine. Pour commencer à utiliser les enregistrements de la zone hébergée du sous-domaine pour acheminer le trafic Internet, vous devez créer un enregistrement NS dans la zone hébergée du domaine (example.com) et lui attribuer le nom du sous-domaine (acme.example.com). Pour la valeur de l'enregistrement NS, vous spécifiez les noms des serveurs de noms de la zone hébergée du sous-domaine. 

Voici ce qu'il se passe lorsque Route 53 reçoit une requête DNS d'un résolveur DNS pour le sous-domaine acme.example.com ou l'un de ses sous-domaines :

1. Route 53 recherche, dans la zone hébergée du domaine (example.com), le registre NS du sous-domaine (acme.example.com).

1. Route 53 obtient les serveurs de noms du registre NS acme.example.com dans la zone hébergée du domaine example.com, et renvoie ces serveurs de noms au résolveur DNS. 

1. Le résolveur envoie à nouveau la requête pour acme.example.com aux serveurs de noms pour la zone hébergée acme.example.com.

1. Route 53 répond à la requête en utilisant un enregistrement contenu dans la zone hébergée acme.example.com.

Pour configurer Route 53 pour qu'il achemine le trafic pour le sous-domaine à l'aide de la zone hébergée du sous-domaine et supprime les registres en double de la zone hébergée du domaine, exécutez la procédure suivante :

**Pour configurer Route 53 afin d'utiliser la zone hébergée du sous-domaine (console)**

1. Dans la console Route 53, obtenez les serveurs de noms de la zone hébergée du sous-domaine :

   1. Dans le panneau de navigation, choisissez **Zones hébergées**. 

   1. Sur la page **Hosted zones** (Zones hébergées), choisissez le nom de la zone hébergée du sous-domaine.

   1. Dans le volet droit, copiez les noms des quatre serveurs répertoriés dans **Name servers** (Serveurs de noms) dans la section **Hosted zones details** (Détails des zones hébergées).

1. Choisissez le nom de la zone hébergée du domaine (example.com), et non du sous-domaine.

1. Choisissez **Créer un registre**.

1. Choisissez **Simple routing** (Routage simple), puis **Next** (Suivant).

1. Choisissez **Define simple record (Définir un registre simple)**.

1. Indiquez l’une des valeurs suivantes :  
**Nom**  
Entrez le nom du sous-domaine (par exemple,`acme.example.com`). Ce nom doit correspondre exactement au nom de la zone hébergée du sous-domaine que vous avez créée.  
**Valeur/routage du trafic vers**  
Choisissez **IP address or another value depending on the record type** (Adresse IP ou autre valeur selon le type de registre) et collez les noms des serveurs de noms que vous avez copiés lors de l'étape 1.  
**Type de registre**  
Choisissez **NS – Name servers for a hosted zone** (NS – Serveurs de noms pour une zone hébergée).  
**TTL (secondes)**  
Indiquez une valeur plus courante pour un enregistrement NS, par exemple 172 800 secondes.

1. Choisissez **Define simple record** (Définir un registre simple), puis **Create records** (Créer des registres).

1. Si la zone hébergée du domaine contient des enregistrements que vous avez recréés dans la zone hébergée du sous-domaine, supprimez ces enregistrements de la zone hébergée du domaine. Pour de plus amples informations, veuillez consulter [Suppression d'enregistrements](resource-record-sets-deleting.md).

   Lorsque vous avez terminé, tous les enregistrements pour le sous-domaine doivent se trouver dans la zone hébergée du sous-domaine.

## Acheminement du trafic pour d'autres niveaux de sous-domaines
<a name="dns-routing-traffic-for-sub-subdomains"></a>

Acheminer le trafic vers un sous-domaine d'un sous-domaine, par exemple backend.acme.example.com, revient au même que d'acheminer le trafic vers un sous-domaine, par exemple acme.example.com. Soit vous créez des enregistrements dans la zone hébergée du domaine, soit vous créez une zone hébergée pour le sous-domaine de niveau inférieur, puis créez des enregistrements dans cette nouvelle zone hébergée.

Si vous choisissez de créer une zone hébergée distincte pour le sous-domaine de niveau inférieur, créez l'enregistrement NS pour ce sous-domaine dans la zone hébergée du sous-domaine qui est plus proche d'un niveau du nom de domaine. Cela permet de garantir que le trafic est correctement acheminé vers vos ressources. Par exemple, supposons que vous voulez acheminer le trafic pour les sous-domaines suivants :
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com

Pour utiliser une autre zone hébergée afin d'acheminer le trafic pour subdomain2.subdomain1.example.com, procédez comme suit :

1. Créez une zone hébergée nommée subdomain2.subdomain1.example.com. 

1. Créez des enregistrements dans la zone hébergée subdomain2.subdomain1.example.com. Pour de plus amples informations, veuillez consulter [Création d'enregistrements dans la zone hébergée du sous-domaine](#dns-routing-traffic-for-subdomains-creating-records).

1. Copiez les noms des serveurs de noms de la zone hébergée subdomain2.subdomain1.example.com. 

1. Dans la zone hébergée subdomain1.example.com, créez un enregistrement NS nommé subdomain2.subdomain1.example.com, puis collez-y les noms des serveurs de noms de la zone hébergée subdomain2.subdomain1.example.com. 

   En outre, supprimez les enregistrements en double de subdomain1.exemple.com. Pour de plus amples informations, veuillez consulter [Mise à jour de la zone hébergée du domaine](#dns-routing-traffic-for-subdomains-delegating-responsibility). 

   Une fois que vous avez créé ce registre NS, Route 53 commence à utiliser la zone hébergée subdomain2.subdomain1.example.com pour acheminer le trafic pour le sous-domaine subdomain2.subdomain1.example.com.

# Utilisation de zones hébergées
<a name="hosted-zones-working-with"></a>

Une zone hébergée est un conteneur d'enregistrements, lesquels comportent des informations sur la façon dont vous souhaitez acheminer le trafic d'un domaine spécifique (par exemple, example.com) et de ses sous-domaines (acme.example.com, zenith.example.com). Une zone hébergée et le domaine correspondant portent le même nom. Il existe deux types de zones hébergées :
+ Les *zones hébergées publiques* contiennent les enregistrements qui spécifient la façon dont vous souhaitez acheminer le trafic sur le réseau Internet. Pour de plus amples informations, veuillez consulter [Utilisation des zones hébergées publiques](AboutHZWorkingWith.md).
+ Les *zones hébergées privées* contiennent les enregistrements qui spécifient la façon dont vous souhaitez acheminer le trafic dans un VPC Amazon. Pour de plus amples informations, veuillez consulter [Utilisation des zones hébergées privées](hosted-zones-private.md).

# Utilisation des zones hébergées publiques
<a name="AboutHZWorkingWith"></a>

Une zone hébergée publique est un conteneur qui comporte des informations sur la façon dont vous souhaitez acheminer le trafic sur le réseau Internet pour un domaine spécifique (par exemple, example.com) et ses sous-domaines (acme.example.com, zenith.example.com). Vous obtenez une zone hébergée publique de la manière suivante :
+ Lorsque vous enregistrez un domaine avec Route 53, nous créons automatiquement une zone hébergée pour vous.
+ Lorsque vous transférez le service DNS pour un domaine existant vers Route 53, commencez par créer une zone hébergée pour le domaine. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existantFaire de Route 53 le service DNS d'un domaine existant](MigratingDNS.md).

Dans les deux cas, vous créez ensuite des enregistrements dans la zone hébergée pour spécifier la façon dont vous voulez acheminer le trafic du domaine et de ses sous-domaines. Par exemple, vous pouvez créer un enregistrement pour acheminer le trafic de www.example.com vers une CloudFront distribution ou vers un serveur Web de votre centre de données. Pour plus d'informations sur les enregistrements , consultez la section [Utilisation des enregistrements](rrsets-working-with.md).

Cette rubrique explique comment utiliser la console Amazon Route 53 pour créer, répertorier et supprimer des zones hébergées publiques. 

**Note**  
Vous pouvez également utiliser une zone hébergée *privée* Route 53 pour acheminer le trafic au sein d'une ou de plusieurs zones VPCs que vous créez avec le service Amazon VPC. Pour de plus amples informations, veuillez consulter [Utilisation des zones hébergées privées](hosted-zones-private.md).

**Topics**
+ [Remarques sur l'utilisation des zones hébergées publiques](hosted-zone-public-considerations.md)
+ [Création d'une zone hébergée publique](CreatingHostedZone.md)
+ [Obtention de la liste des serveurs de noms d'une zone hébergée publique](GetInfoAboutHostedZone.md)
+ [Liste des zones hébergées publiques](ListInfoOnHostedZone.md)
+ [Affichage des métriques de requête DNS pour une zone hébergée publique](hosted-zone-public-viewing-query-metrics.md)
+ [Suppression d'une zone hébergée publique](DeleteHostedZone.md)
+ [Vérification des réponses DNS à partir de Route 53](dns-test.md)
+ [Configuration de serveurs de noms en marque blanche](white-label-name-servers.md)
+ [Registres NS et SOA créés par Amazon Route 53 pour une zone hébergée publique](SOA-NSrecords.md)
+ [Permettre une restauration accélérée pour gérer les enregistrements DNS publics](accelerated-recovery.md)

# Remarques sur l'utilisation des zones hébergées publiques
<a name="hosted-zone-public-considerations"></a>

Notez les remarques suivantes sur l'utilisation des zones hébergées publiques :

**Enregistrements NS et SOA**  
Lorsque vous créez une zone hébergée, Amazon Route 53 crée automatiquement un registre de serveur de noms (NS) et un registre de source de noms (SOA) pour la zone. Le registre NS identifie les quatre serveurs de noms que vous attribuez à votre bureau d'enregistrement ou à votre service DNS afin que les requêtes DNS soient acheminées vers les serveurs de noms Route 53. Pour plus d'informations sur les enregistrements NS et SOA, consultez [Registres NS et SOA créés par Amazon Route 53 pour une zone hébergée publique](SOA-NSrecords.md).

**Plusieurs zones hébergées ayant le même nom**  
Vous pouvez créer plusieurs zones hébergées avec le même nom et ajouter différents registres à chaque zone hébergée. Route 53 affecte quatre serveurs de noms à chaque zone hébergée, et les serveurs de noms sont différents pour chacune d'elles. Lorsque vous mettez à jour les registres de serveur de noms de votre bureau d'enregistrement, veillez à utiliser les serveurs de noms Route 53 correspondant à la zone hébergée appropriée, c'est-à-dire celle qui contient les registres que Route 53 doit utiliser pour répondre aux requêtes concernant votre domaine. Route 53 ne renvoie jamais les valeurs des registres d'autres zones hébergées ayant le même nom.

**Ensembles de délégations réutilisables**  
Par défaut, Route 53 affecte un ensemble unique de quatre serveurs de noms (appelés collectivement « ensemble de délégations ») pour chaque zone hébergée que vous créez. Si vous souhaitez créer un grand nombre de zones hébergées, vous pouvez créer un ensemble de délégations réutilisables par programme. (Les ensembles de délégations réutilisables ne sont pas disponibles dans la console Route 53.) Ensuite, vous pouvez créer des zones hébergées par programme et affecter le même ensemble de délégations réutilisables (les quatre mêmes serveurs de noms) à chaque zone hébergée.   
Les ensembles de délégations réutilisables simplifient la migration du service DNS vers Route 53, car vous pouvez demander à votre bureau d'enregistrement de nom de domaine d'utiliser les quatre mêmes serveurs de noms pour tous les domaines pour lesquels vous souhaitez utiliser Route 53 en tant que service DNS. Pour plus d'informations, consultez [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)le manuel *Amazon Route 53 API Reference*.

# Création d'une zone hébergée publique
<a name="CreatingHostedZone"></a>

Une zone hébergée publique est un conteneur qui comporte des informations sur la façon dont vous souhaitez acheminer le trafic sur le réseau Internet pour un domaine spécifique (par exemple, example.com) et ses sous-domaines (acme.example.com, zenith.example.com). Une fois que vous avez créé une zone hébergée, vous créez des enregistrements qui spécifient la façon dont vous voulez acheminer le trafic du domaine et de ses sous-domaines.

**Restrictions**  
Notez les restrictions suivantes pour créer des zones hébergées avec Route 53.  
Vous pouvez créer une zone hébergée uniquement pour un domaine pour lequel vous disposez d'une autorisation d'administration. Généralement, cela signifie que le domaine vous appartient, mais il est également possible que vous développiez une application pour l'inscrit du domaine. 
Vous pouvez créer des zones hébergées uniquement pour les domaines et les sous-domaines. Route 53 ne prend pas en charge l'hébergement de domaines de premier niveau (TLD) tels que. `.com`

**Pour créer une zone hébergée publique à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Si vous découvrez Route 53, choisissez **Get started** (Pour démarrer) sous **DNS management** (Gestion DNS). 

   Si vous utilisez déjà Route 53, choisissez **Hosted Zones** (Zones hébergées) dans le panneau de navigation.

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

1. Dans le volet **Create Hosted Zone (Créer une zone hébergée)**, entrez le nom du domaine pour lequel vous souhaitez acheminer le trafic. Vous pouvez également entrer un commentaire facultatif.

   Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

1. Pour **Type**, acceptez la valeur par défaut de **Zone hébergée publique**.

1. Choisissez **Créer**.

1. Créez les enregistrements qui indiquent la façon dont vous souhaitez acheminer le trafic pour le domaine et les sous-domaines. Pour de plus amples informations, veuillez consulter [Utilisation des enregistrements](rrsets-working-with.md).

1. Pour utiliser des enregistrements de la nouvelle zone hébergée pour acheminer le trafic pour votre domaine, consultez la rubrique applicable :
   + Si vous configurez Route 53 en tant que service DNS d'un domaine enregistré auprès d'un autre bureau d'enregistrement, consultez [Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existantFaire de Route 53 le service DNS d'un domaine existant](MigratingDNS.md).
   + Si le domaine est enregistré auprès de Route 53, consultez [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md).

# Obtention de la liste des serveurs de noms d'une zone hébergée publique
<a name="GetInfoAboutHostedZone"></a>

Vous obtenez les serveurs de noms pour une zone hébergée publique si vous souhaitez modifier le service DNS pour votre enregistrement de domaine. Pour plus d'informations sur la modification de votre service DNS, veuillez consulter [Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existantFaire de Route 53 le service DNS d'un domaine existant](MigratingDNS.md).

**Note**  
Certains bureaux d'enregistrement vous permettent uniquement de spécifier des serveurs de noms à l'aide d'adresses IP. Ils ne vous permettent pas de spécifier des noms de domaine complets. Si votre bureau d'enregistrement nécessite l'utilisation d'adresses IP, vous pouvez obtenir les adresses IP de vos serveurs de noms à l'aide de l'utilitaire dig (pour Mac, Unix ou Linux) ou de l'utilitaire nslookup (pour Windows). La modification des adresses IP de serveurs de noms est rare. Si nous avons besoin de modifier des adresses IP, vous serez averti à l'avance. 

**Pour obtenir les serveurs de noms pour une zone hébergée à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones** (Zones hébergées).

1. Sur la page **Hosted zones** (Zones hébergées), choisissez la case d'option (pas le nom) de la zone hébergée, puis **View details** (Afficher les détails).

1. Sur la page des détails de la zone hébergée, choisissez **Hosted zone details** (Détails de la zone hébergée).

1. Notez les quatre serveurs répertoriés dans **Name servers** (Serveurs de noms).

# Liste des zones hébergées publiques
<a name="ListInfoOnHostedZone"></a>

Vous pouvez utiliser la console Amazon Route 53 pour répertorier toutes les zones hébergées que vous avez créées avec le AWS compte actuel. Pour plus d'informations sur la façon de répertorier les zones hébergées à l'aide de l'API Route 53, consultez [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)le *manuel Amazon Route 53 API Reference*. 

**Pour répertorier les zones hébergées publiques associées à un AWS compte à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**. La page affiche la liste des zones hébergées associées au AWS compte avec lequel vous êtes actuellement connecté.

1.  Pour filtrer les zones hébergées, utilisez la barre de recherche située en haut de la table. 

   Le comportement de recherche varie selon que la zone hébergée contient jusqu'à 2 000 enregistrements ou plus de 2 000 enregistrements :

   **Up to 2,000 hosted zones** (Jusqu'à 2 000 zones hébergées)
   + Pour afficher les registres comportant des valeurs spécifiques, cliquez sur la barre de recherche, choisissez une propriété dans la liste déroulante, puis saisissez une valeur. Vous pouvez également saisir une valeur directement dans la barre de recherche et appuyez sur Entrée. Par exemple, pour afficher les zones hébergées dont le nom commence par **abc**, saisissez cette valeur dans la barre de recherche et appuyez sur Entrée.
   + Pour afficher uniquement les zones hébergées ayant le même type de zone hébergée, sélectionnez le type dans la liste déroulante, puis saisissez le type.

   **More than 2,000 hosted zones** (Plus de 2 000 zones hébergées)
   + Vous pouvez rechercher des propriétés en fonction du nom de domaine exact, de toutes les propriétés et du type.
   + Faites une recherche à l'aide du nom de domaine exact pour obtenir des résultats de recherche plus rapides.

# Affichage des métriques de requête DNS pour une zone hébergée publique
<a name="hosted-zone-public-viewing-query-metrics"></a>

Vous pouvez afficher le nombre total de requêtes DNS auxquelles Route 53 répond pour une zone hébergée publique spécifiée ou une combinaison de zones hébergées publiques. Les statistiques apparaissent dans CloudWatch, ce qui vous permet de visualiser un graphique, de choisir la période que vous souhaitez consulter et de personnaliser les mesures de différentes manières. Vous pouvez également créer des alarmes et configurer des notifications, afin d'être averti lorsque le nombre de requêtes DNS au cours d'une période donnée est supérieur ou inférieur à un niveau spécifié.

**Note**  
Route 53 envoie automatiquement le nombre de requêtes CloudWatch DNS à toutes les zones hébergées publiques. Vous n'avez donc rien à configurer avant de pouvoir consulter les métriques des requêtes. Les métriques de requête DNS n'impliquent aucun frais.

**Quelles requêtes DNS sont comptabilisées ?**  
Les métriques incluent uniquement les requêtes que les résolveurs DNS transmettent à Route 53. Si un résolveur DNS a déjà mis en cache la réponse à une requête (par exemple, l'adresse IP d'un équilibreur de charge pour example.com), le résolveur continuera à renvoyer la réponse en cache sans transférer la requête à Route 53 jusqu'à ce que la TTL du registre correspondant arrive à expiration.  
Selon le nombre de requêtes DNS qui sont soumises pour un nom de domaine (example.com) ou nom de sous-domaine (www.example.com), les résolveurs auxquels vos utilisateurs ont recours et la durée de vie (TTL) de l'enregistrement, les métriques de requêtes DNS peuvent contenir des informations concernant une seule requête sur les plusieurs milliers de requêtes qui sont soumises aux résolveurs DNS. Pour en savoir plus sur la façon dont les requêtes DNS fonctionnent, consultez [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). 

**À partir de quand les mesures de requête pour une zone hébergée commencent-elles à apparaître dans CloudWatch ?**  
Une fois que vous avez créé une zone hébergée, un délai de plusieurs heures est nécessaire avant que la zone hébergée puisse apparaître dans CloudWatch. En outre, vous devez soumettre une requête DNS pour un enregistrement dans la zone hébergée afin que les données apparaissent. 

**Les métriques sont disponibles uniquement dans la région USA Est (Virginie du Nord).**  
Pour obtenir les métriques sur la console, vous devez choisir la région USA Est (Virginie du Nord). Pour obtenir des métriques à l'aide de la AWS CLI, vous devez soit laisser la AWS région non spécifiée, soit la spécifier `us-east-1` comme région. Les métriques Route 53 ne sont pas disponibles si vous choisissez une autre région.

**CloudWatch métrique et dimension pour les requêtes DNS**  
Pour plus d'informations sur la CloudWatch métrique et la dimension des requêtes DNS, consultez[Surveillance des zones hébergées à l'aide d'Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). Pour plus d'informations sur CloudWatch les métriques, consultez la section [Utilisation CloudWatch des métriques Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) dans le *guide de CloudWatch l'utilisateur Amazon*.

**Obtenir des données plus détaillées sur les requêtes DNS**  
Pour obtenir des informations plus détaillées sur chaque requête DNS à laquelle Route 53 répond, notamment les valeurs suivantes, vous pouvez configurer la journalisation des requêtes :  
+ Domaine ou sous-domaine demandé
+ Date et heure de la requête
+ Type de registre DNS (comme A ou AAAA)
+ Emplacement périphérique Route 53 qui a répondu à la requête DNS
+ Code de réponse DNS, tel que `NoError` ou `ServFail`
Pour de plus amples informations, veuillez consulter [Journalisation des requêtes DNS publiques](query-logs.md).

**Comment obtenir des métriques de requête DNS**  
Peu de temps après avoir créé une zone hébergée, Amazon Route 53 commence à envoyer des métriques et des dimensions une fois par minute à CloudWatch. Vous pouvez utiliser les procédures suivantes pour afficher les métriques sur la CloudWatch console ou les afficher à l'aide du AWS Command Line Interface (AWS CLI).

**Topics**
+ [Afficher les métriques des requêtes DNS pour une zone hébergée publique dans la CloudWatch console](#hosted-zone-public-viewing-query-metrics-console)
+ [Obtenir des métriques de requêtes DNS à l'aide du AWS CLI](#hosted-zone-public-viewing-query-metrics-cli)

## Afficher les métriques des requêtes DNS pour une zone hébergée publique dans la CloudWatch console
<a name="hosted-zone-public-viewing-query-metrics-console"></a>

Pour consulter les métriques des requêtes DNS pour les zones hébergées publiques dans la CloudWatch console, effectuez la procédure suivante.<a name="hosted-zone-public-viewing-query-metrics-console-procedure"></a>

**Pour consulter les métriques des requêtes DNS pour une zone hébergée publique sur la CloudWatch console**

1. Connectez-vous à la CloudWatch console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Dans le panneau de navigation, sélectionnez ‎**Métriques**.

1. Dans la liste des AWS régions située dans le coin supérieur droit de la console, choisissez **USA Est (Virginie du Nord)**. Les statistiques de Route 53 ne sont pas disponibles si vous choisissez une autre AWS région.

1. Sous l'onglet **Toutes les métriques**, choisissez **Route 53**.

1. Choisissez **Hosted Zone Metrics (Métriques de la zone hébergée)**.

1. Cochez la case correspondant à une ou plusieurs zones hébergées portant le nom de la métrique **DNSQueries**.

1. Dans l'onglet **Graphed metrics (Métriques représentées graphiquement)**, modifiez les valeurs applicables pour afficher les métriques au format de votre choix.

   Dans le **champ Statistiques**, sélectionnez **Somme** ou **SampleCount**; ces statistiques affichent toutes deux la même valeur.

## Obtenir des métriques de requêtes DNS à l'aide du AWS CLI
<a name="hosted-zone-public-viewing-query-metrics-cli"></a>

Pour obtenir les métriques des requêtes DNS à l'aide de AWS CLI, vous devez utiliser la [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)commande. Notez ce qui suit :
+ Vous spécifiez la plupart des valeurs pour la commande dans un fichier JSON distinct. Pour de plus amples informations, veuillez consulter [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html).
+ La commande renvoie une valeur pour chaque intervalle que vous spécifiez pour `Period` dans le fichier JSON. `Period` est en secondes. Par conséquent, si vous spécifiez une période de cinq minutes et que vous indiquez `60` pour `Period`, vous obtenez cinq valeurs. Si vous spécifiez une période de cinq minutes et que vous indiquez `300` pour `Period`, vous obtenez une valeur. 
+ Dans le fichier JSON, vous pouvez spécifier n'importe quelle valeur pour `Id`.
+ Laissez la AWS région non spécifiée ou spécifiez-la `us-east-1` comme région. Les métriques Route 53 ne sont pas disponibles si vous choisissez une autre région. Pour plus d'informations, consultez [la section Configuration de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) dans le *guide de AWS Command Line Interface l'utilisateur*.

Voici la AWS CLI commande que vous utilisez pour obtenir les métriques des requêtes DNS pour la période de cinq minutes comprise entre 4 h 01 et 4 h 07 le 1er mai 2019. Le paramètre `metric-data-queries` fait référence à l'exemple de fichier JSON qui suit la commande.

```
aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z
```

Voici l'exemple de fichier JSON :

```
[
    {
        "Id": "my_dns_queries_id",
        "MetricStat": {
            "Metric": {
                "Namespace": "AWS/Route53",
                "MetricName": "DNSQueries",
                "Dimensions": [
                    {
                        "Name": "HostedZoneId",
                        "Value": "Z1D633PJN98FT9"
                    }
                ]
            },
            "Period": 60,
            "Stat": "Sum"
        },
        "ReturnData": true
    }
]
```

Voici le résultat de cette commande. Notez ce qui suit :
+ L'heure de début et l'heure de fin de la commande couvrent une période de sept minutes, de `2019-05-01T04:01:00Z` à `2019-05-01T04:07:00Z`.
+ Il n'y a que six valeurs renvoyées. Il n'y a pas de valeur pour `2019-05-01T04:05:00Z`, car il n'y a eu aucune requête DNS pendant cette minute.
+ La valeur de `Period` spécifiée dans le fichier JSON est `60` (secondes). Les valeurs sont donc présentées par intervalles d'une minute.

```
{
    "MetricDataResults": [
        {
            "Id": "my_dns_queries_id",
            "StatusCode": "Complete",
            "Label": "DNSQueries",
            "Values": [
                101.0,
                115.0,
                103.0,
                127.0,
                111.0,
                120.0
            ],
            "Timestamps": [
                "2019-05-01T04:07:00Z",
                "2019-05-01T04:06:00Z",
                "2019-05-01T04:04:00Z",
                "2019-05-01T04:03:00Z",
                "2019-05-01T04:02:00Z",
                "2019-05-01T04:01:00Z"
            ]
        }
    ]
}
```

# Suppression d'une zone hébergée publique
<a name="DeleteHostedZone"></a>

Cette section explique comment supprimer une zone hébergée publique à l'aide de la console Amazon Route 53.

Vous pouvez supprimer une zone hébergée uniquement s'il n'existe aucun autre enregistrement que les enregistrements SOA et NS par défaut. Si votre zone hébergée contient d'autres enregistrements, vous devez les supprimer avant de pouvoir supprimer votre zone hébergée. Cela vous empêche de supprimer accidentellement une zone hébergée qui contient encore des enregistrements.

**Topics**
+ [Empêcher le routage du trafic vers votre domaine](#delete-public-hosted-zone-stop-routing)
+ [Suppression des zones hébergées publiques qui étaient créées par un autre service](#delete-public-hosted-zone-created-by-another-service)
+ [Utilisation de la console Route 53 pour supprimer une zone hébergée publique](#delete-public-hosted-zone-procedure)

## Empêcher le routage du trafic vers votre domaine
<a name="delete-public-hosted-zone-stop-routing"></a>

Si vous souhaitez conserver l'enregistrement de votre domaine, mais que vous souhaitez arrêter d'acheminer le trafic Internet vers votre site web ou votre application web, nous vous recommandons de supprimer les *enregistrements* dans la zone hébergée au lieu de supprimer la zone hébergée.

**Important**  
Si vous supprimez une zone hébergée, vous ne pourrez pas annuler cette suppression. Vous devez créer une nouvelle zone hébergée et mettre à jour les serveurs de noms pour l'enregistrement de votre domaine, ce qui peut nécessiter jusqu'à 48 heures pour prendre effet. En outre, si vous supprimez une zone hébergée, quelqu'un peut pirater le domaine et acheminer le trafic vers ses propres ressources à l'aide de votre nom de domaine.  
Si vous avez délégué la responsabilité d'un sous-domaine à une zone hébergée et que vous souhaitez supprimer la zone hébergée enfant, vous devez également mettre à jour la zone hébergée parent en supprimant l'enregistrement NS portant le même nom que la zone hébergée enfant. Par exemple, si vous souhaitez supprimer la zone hébergée acme.example.com, vous devez également supprimer l'enregistrement NS acme.example.com dans la zone hébergée example.com. Nous vous recommandons de supprimer d'abord l'enregistrement NS et d'attendre pendant la durée de vie (TTL) sur l'enregistrement NS avant de supprimer la zone hébergée enfant. Vous êtes ainsi assuré que personne ne peut pirater la zone hébergée enfant lors de la période pendant laquelle les résolveurs DNS ont encore les serveurs de noms pour la zone hébergée enfant mis en cache.

Si vous souhaitez éviter les frais mensuels pour la zone hébergée, vous pouvez transférer le service DNS pour le domaine vers un service DNS gratuit. Lorsque vous transférez le service DNS, vous devez mettre à jour les serveurs de noms pour l'enregistrement du domaine. Si le domain est enregistré auprès de Route 53, consultez [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md) pour savoir comment remplacer des serveurs de noms Route 53 par des serveurs de noms pour le nouveau service DNS. Si le domaine est enregistré auprès d'un autre bureau d'enregistrement, utilisez la méthode fournie par le bureau d'enregistrement pour mettre à jour les serveurs de noms pour l'enregistrement du domaine. Pour en savoir plus, effectuez une recherche Internet sur « service DNS gratuit. »

## Suppression des zones hébergées publiques qui étaient créées par un autre service
<a name="delete-public-hosted-zone-created-by-another-service"></a>

Si une zone hébergée a été créée par un autre service, vous ne pouvez pas la supprimer à l'aide de la console Route 53. Au lieu de cela, vous devez utiliser le processus de l'autre service :
+ **AWS Cloud Map**— Pour supprimer une zone hébergée AWS Cloud Map créée lorsque vous avez créé un espace de noms DNS public, supprimez l'espace de noms. AWS Cloud Map supprime automatiquement la zone hébergée. Pour plus d'informations, consultez [Suppression des espaces de noms](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) dans le *Guide du développeur AWS Cloud Map *.
+ **Découverte du service Amazon Elastic Container Service (Amazon ECS)** – Pour supprimer une zone hébergée publique créée par Amazon ECS lorsque vous avez créé un service à l'aide de la découverte de service, supprimez les services Amazon ECS qui utilisent l'espace de noms et supprimez l'espace de noms. Pour plus d'informations, consultez [Suppression d'un service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) dans le *Guide du développeur Amazon Elastic Container Service*.

## Utilisation de la console Route 53 pour supprimer une zone hébergée publique
<a name="delete-public-hosted-zone-procedure"></a>

Pour utiliser la console Route 53 afin de supprimer une zone hébergée publique, exécutez la procédure suivante.

**Pour supprimer une zone hébergée publique à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones** (Zones hébergées), et choisissez le lien surligné de la zone hébergée que vous souhaitez supprimer.

1. Vérifiez que la zone hébergée que vous souhaitez supprimer contient uniquement un enregistrement NS et un enregistrement SOA. Si elle contient d'autres registres, supprimez-les : Vous devrez également désactiver la signature DNSSEC :
**Note**  
Si vous tentez de supprimer la zone hébergée sans remplir ces conditions, Route 53 renverra un message d'erreur :  
Si la signature DNSSEC est activée : la zone hébergée spécifiée contient des clés de signature par clé DNSSEC et ne peut donc pas être supprimée
S'il existe d'autres ensembles d'enregistrements de ressources (autres que les enregistrements SOA et NS par défaut) : la zone hébergée spécifiée contient des ensembles d'enregistrements de ressources non obligatoires et ne peut donc pas être supprimée

   1. Sur la page de détails de la zone hébergée, dans la liste des **Records** (Enregistrements), si la liste des enregistrements inclut des enregistrements pour lesquels la valeur de la colonne **Type** n'est ni NS ni SOA, choisissez la ligne, et choisissez **Delete** (Supprimer).

     Pour sélectionner plusieurs enregistrements consécutifs, appuyez sur la touche **MAJ** et maintenez-la enfoncée, puis sélectionnez la dernière ligne. Pour sélectionner plusieurs enregistrements non consécutifs, appuyez sur la touche **Ctrl** et maintenez-la enfoncée, puis sélectionnez les autres lignes. 
**Note**  
Si vous avez créé des enregistrements NS pour des sous-domaines dans la zone hébergée, supprimez également ces enregistrements.

1. Retournez à la page **Hosted Zones** (Zones hébergées), et choisissez la ligne de la zone hébergée que vous souhaitez supprimer.

1. Sélectionnez **Delete (Supprimer)**.

1. Saisissez la clé de confirmation et choisissez **Delete** (Supprimer).

1. Si vous ne voulez pas que le domaine soit disponible sur Internet, nous vous recommandons de transférer le service DNS vers un service DNS gratuit, puis de supprimer la zone hébergée Route 53. Cela évitera les requêtes DNS futures d’être mal acheminées. 

   Si le domain est enregistré auprès de Route 53, consultez [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md) pour savoir comment remplacer des serveurs de noms Route 53 par des serveurs de noms pour le nouveau service DNS. Si le domaine est enregistré auprès d’un autre bureau d’enregistrement, utilisez la méthode fournie par le bureau d’enregistrement pour changer les serveurs de noms du domaine.
**Note**  
Si vous supprimez une zone hébergée pour un sous-domaine (acme.example.com), vous n'avez pas besoin de changer les serveurs de noms du domaine (example.com).

# Vérification des réponses DNS à partir de Route 53
<a name="dns-test"></a>

Si vous avez créé une zone hébergée Amazon Route 53 pour votre domaine, vous pouvez utiliser l'outil de vérification DNS dans la console pour voir de quelle manière Route 53 répond aux requêtes DNS si vous configurez votre domaine pour qu'il utilise Route 53 en tant que service DNS. Pour les enregistrements de géolocalisation, de géoproximité et de latence, vous pouvez également simuler des requêtes à partir de l'adresse IP d'un and/or client de résolution DNS spécifique pour savoir quelle réponse renverrait Route 53.

**Important**  
L'outil ne soumet pas de requêtes au système de noms de domaine. Il répond uniquement en fonction des paramètres des enregistrements de la zone hébergée. L’outil renvoie les mêmes informations, même si la zone hébergée est actuellement utilisée pour acheminer le trafic pour le domaine.

L'outil de vérification DNS fonctionne pour les zones hébergées publiques uniquement.

**Note**  
L'outil de vérification DNS renvoie des informations similaires à celles que vous attendez de la section de réponse de la commande `dig`. Par conséquent, si vous recherchez les serveurs de noms d'un sous-domaine qui pointent vers les serveurs de noms parents, ceux-ci ne seront pas renvoyés.

**Topics**
+ [Utilisation de l'outil de vérification pour voir comment Amazon Route 53 répond aux requêtes DNS](#dns-test-how-route-53-responds)
+ [Utilisation de l'outil de vérification pour simuler des requêtes d'adresses IP spécifiques (enregistrements de géolocalisation et de latence uniquement)](#dns-test-simulate-requests)

## Utilisation de l'outil de vérification pour voir comment Amazon Route 53 répond aux requêtes DNS
<a name="dns-test-how-route-53-responds"></a>

Vous pouvez utiliser l'outil pour voir quelle réponse Amazon Route 53 renvoie en réponse à une requête DNS pour un registre.<a name="dns-test-how-route-53-responds-procedure"></a>

**Pour utiliser l'outil de vérification pour voir comment Route 53 répond aux requêtes DNS**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le volet de navigation, choisissez **Hosted Zones (Zones hébergées)**.

1. Sur la page **Hosted Zones (Zones hébergées)**, choisissez le nom d'une zone hébergée. La console affiche la liste des enregistrements pour cette zone hébergée.

1. Pour accéder directement à la page **Check response from Route 53** (Vérifier la réponse depuis Route 53), choisissez **Test record** (Tester le registre).

1. Indiquez l'une des valeurs suivantes :
   + Nom de l'enregistrement, à l'exclusion du nom de la zone hébergée. Par exemple, pour vérifier **www.example.com**, entrez **www**. Pour vérifier **example.com**, laissez le champ **Record name (Nom de l'enregistrement)** vide.
   + Type de l'enregistrement à vérifier, comme **A** ou **CNAME**.

1. Choisissez **Get Response**.

1. La section **Response returned by Route 53** inclut les valeurs suivantes :  
**DNS response code**  
Code qui indique si la requête était valide ou non. Le code de réponse le plus courant est **NOERROR**, ce qui signifie que la requête était valide. Si la réponse n'est pas valide, Route 53 renvoie un code de réponse qui en explique la raison. Pour une liste des codes de réponse possibles, consultez [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) sur le site web IANA.  
** Protocole**  
Protocole utilisé par Amazon Route 53 pour répondre à la requête, **UDP** ou **TCP**.  
**Response returned by Route 53**  
La valeur que Route 53 renverrait à une application web. La valeur est l’une des suivantes :  
   + Pour les enregistrements sans alias, la réponse contient la ou les valeurs dans l'enregistrement.
   + Pour plusieurs enregistrements qui ont les mêmes nom et type, qui inclut pondéré, latence, géolocalisation et basculement, la réponse contient la valeur de l'enregistrement approprié, basée sur la demande. 
   + Pour les enregistrements d'alias qui font référence à AWS des ressources autres qu'un autre enregistrement, la réponse contient une adresse IP ou un nom de domaine pour la AWS ressource, selon le type de ressource.
   + Pour les enregistrements d'alias qui font référence à d'autres enregistrements, la réponse contient la ou les valeurs de l'enregistrement référencé.

## Utilisation de l'outil de vérification pour simuler des requêtes d'adresses IP spécifiques (enregistrements de géolocalisation et de latence uniquement)
<a name="dns-test-simulate-requests"></a>

Si vous avez créé des enregistrements de latence ou géolocalisation, vous pouvez utiliser l'outil de vérification pour simuler des requêtes à partir de l'adresse IP pour un résolveur DNS et un client.<a name="dns-test-simulate-requests-procedure"></a>

**Pour utiliser l'outil de vérification afin de simuler des requêtes à partir des adresses IP spécifiées**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le volet de navigation, choisissez **Hosted Zones (Zones hébergées)**.

1. Sur la page **Hosted Zones (Zones hébergées)**, choisissez le nom d'une zone hébergée. La console affiche la liste des enregistrements pour cette zone hébergée.

1. Pour accéder directement à la page **Check response from Route 53**, choisissez **Test record set**.

   Pour accéder à la page **Check response from Route 53** relative à un enregistrement spécifique, cochez la case correspondant à cet enregistrement et choisissez **Test record set**.

1. Si vous avez choisi **Test record set (Tester le jeu d'enregistrements)** sans avoir choisi un enregistrement au préalable, spécifiez les valeurs suivantes :
   + Nom de l'enregistrement, à l'exclusion du nom de la zone hébergée. Par exemple, pour vérifier **www.example.com**, entrez **www**. Pour vérifier **example.com**, laissez le champ **Record name (Nom de l'enregistrement)** vide.
   + Type de l'enregistrement à vérifier, comme **A** ou **CNAME**.

1. Spécifiez les valeurs applicables :  
**Resolver IP address (Adresse IP du résolveur)**  
Spécifiez une IPv6 adresse IPv4 OR pour simuler l'emplacement du résolveur DNS utilisé par un client pour effectuer des demandes. C'est utile pour tester les enregistrements de latence et de géolocalisation. Si vous omettez cette valeur, l'outil utilise l'adresse IP d'un résolveur DNS dans la région AWS USA Est (Virginie du Nord) (us-east-1).   
**EDNS0 IP du sous-réseau du client**  
Si le résolveur le prend en charge EDNS0, entrez l'adresse IP du sous-réseau client pour une adresse IP dans l'emplacement géographique applicable, par exemple **192.0.2.0** ou **2001:db 8:85** a3 : :8a2e : 370:7334.   
**Masque de sous-réseau**  
Si vous spécifiez une adresse IP pour l'adresse **IP du sous-réseau EDNS0 client**, vous pouvez éventuellement spécifier le nombre de bits de l'adresse IP que l'outil de vérification doit inclure dans la requête DNS. **Par exemple, si vous spécifiez **192.0.2.44** pour l'adresse **IP du sous-réseau EDNS0 client** et **24** pour le **masque de sous-réseau**, l'outil de vérification simulera une requête provenant de 192.0.2.0/24.** La valeur par défaut est de 24 bits pour les IPv4 adresses et de 64 bits pour les IPv6 adresses. 

1. Choisissez **Get Response**.

1. La section **Response returned by Route 53** inclut les valeurs suivantes :  
**DNS query sent to Route 53**  
La requête, au [format BIND](https://en.wikipedia.org/wiki/Zone_file), que l'outil de vérification a envoyé à Route 53. C'est le même format que celui qu'une application web utilise pour envoyer une requête. Les trois valeurs sont généralement le nom de l'enregistrement, **IN** (pour Internet) et le type de l'enregistrement.  
**DNS response code**  
Code qui indique si la requête était valide ou non. Le code de réponse le plus courant est **NOERROR**, ce qui signifie que la requête était valide. Si la réponse n'est pas valide, Route 53 renvoie un code de réponse qui en explique la raison. Pour une liste des codes de réponse possibles, consultez [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) sur le site web IANA.  
** Protocole**  
Protocole utilisé par Amazon Route 53 pour répondre à la requête, **UDP** ou **TCP**.  
**Response returned by Route 53**  
La valeur que Route 53 renverrait à une application web. La valeur est l’une des suivantes :  
   + Pour les enregistrements sans alias, la réponse contient la ou les valeurs dans l'enregistrement.
   + Pour plusieurs enregistrements qui ont les mêmes nom et type, qui inclut pondéré, latence, géolocalisation et basculement, la réponse contient la valeur de l'enregistrement approprié, basée sur la demande. 
   + Pour les enregistrements d'alias qui font référence à AWS des ressources autres qu'un autre enregistrement, la réponse contient une adresse IP ou un nom de domaine pour la AWS ressource, selon le type de ressource.
   + Pour les enregistrements d'alias qui font référence à d'autres enregistrements, la réponse contient la ou les valeurs de l'enregistrement référencé.

# Configuration de serveurs de noms en marque blanche
<a name="white-label-name-servers"></a>

Chaque zone hébergée Amazon Route 53 est associée à quatre serveurs de noms, appelés collectivement « ensemble de délégations ». Par défaut, les noms des serveurs de noms ressemblent à ns-2048.awsdns-64.com. Si vous souhaitez que le nom de domaine de vos serveurs de noms soit le même que celui de votre zone hébergée, par exemple, ns1.example.com, vous pouvez configurer des serveurs de noms en marque blanche, également appelés « serveurs de noms personnels » ou « serveurs de noms privés ».

Les étapes suivantes expliquent comment configurer un ensemble de quatre serveurs de noms en marque blanche réutilisables pour plusieurs domaines. Supposons par exemple que vous possédez les domaines example.com, example.org et example.net. Avec ces étapes, vous pouvez configurer des serveurs de noms en marque blanche pour example.com et les réutiliser pour example.org et example.net.

**Topics**
+ [Étape 1 : créer un ensemble de délégations réutilisables Route 53](#white-label-name-servers-create-reusable-delegation-set)
+ [Étape 2 : créer ou recréer des zones hébergées Amazon Route 53 et modifier la TTL des registres NS et SOA](#white-label-name-servers-create-hosted-zones)
+ [Étape 3 : Recréer des enregistrements pour vos zones hébergées](#white-label-name-servers-create-resource-record-sets)
+ [Étape 4 : Obtenir des adresses IP](#white-label-name-servers-get-ip-addresses)
+ [Étape 5 : Créer des enregistrements pour les serveurs de noms en marque blanche](#white-label-name-servers-create-white-label-resource-record-sets)
+ [Étape 6 : Mettre à jour les enregistrements NS et SOA](#white-label-name-servers-update-ns-soa-records)
+ [Étape 7 : Créer des enregistrements de type glue et changer les serveurs de noms du bureau d'enregistrement](#white-label-name-servers-create-glue-records)
+ [Étape 8 : Surveiller le trafic du site web ou de l'application](#white-label-name-servers-monitor-traffic)
+ [Étape 9 : TTLs Revenez à leurs valeurs d'origine](#white-label-name-servers-change-ttls-back)
+ [Étape 10 : (Facultatif) Contacter les services DNS récursifs](#white-label-name-servers-contact-recursive-dns-services)

## Étape 1 : créer un ensemble de délégations réutilisables Route 53
<a name="white-label-name-servers-create-reusable-delegation-set"></a>

Les serveurs de noms en marque blanche sont associés à un ensemble de délégations réutilisables Route 53. Vous pouvez utiliser des serveurs de noms en marque blanche pour une zone hébergée uniquement si la zone hébergée et le jeu de délégation réutilisable ont été créés par le même AWS compte.

Pour créer un ensemble de délégation réutilisable, vous pouvez utiliser l'API Route 53, la AWS CLI ou l'une des AWS SDKs. Pour plus d’informations, consultez la documentation suivante : 
+ **API Route 53** — Voir [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)la *référence de l'API Amazon Route 53* 
+ **AWS CLI** — Voir [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html)dans la *référence des AWS CLI commandes*
+ **AWS SDKs**Consultez la documentation du SDK applicable sur la page de [AWS documentation](https://docs.aws.amazon.com/)

## Étape 2 : créer ou recréer des zones hébergées Amazon Route 53 et modifier la TTL des registres NS et SOA
<a name="white-label-name-servers-create-hosted-zones"></a>

Créez ou recréez des zones hébergées Amazon Route 53 :
+ **Si vous n'utilisez pas actuellement Route 53 en tant que service DNS pour les domaines pour lesquels vous souhaitez utiliser des serveurs de noms en marque blanche** – Créez les zones hébergées et spécifiez l'ensemble de délégations réutilisables que vous avez créé lors de l'étape précédente avec chaque zone hébergée. Pour plus d'informations, consultez [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)le manuel *Amazon Route 53 API Reference*. 
+ **Si vous utilisez Route 53 en tant que service DNS pour les domaines pour lesquels vous souhaitez utiliser des serveurs de noms en marque blanche** – Vous devez recréer les zones hébergées pour lesquelles vous souhaitez utiliser des serveurs de noms en marque blanche et spécifier l'ensemble de délégations réutilisables que vous avez créé lors de l'étape précédente pour chaque zone hébergée.
**Important**  
Vous ne pouvez pas modifier les serveurs de noms qui sont associés à une zone hébergée existante. Vous pouvez associer un ensemble de délégations réutilisables à une zone hébergée uniquement lorsque vous créez la zone hébergée.

Lorsque vous créez les zones hébergées, et avant d'essayer d'accéder aux ressources pour les domaines correspondants, modifiez les valeurs suivantes relatives à la durée de vie pour chaque zone hébergée :
+ Définissez la durée de vie pour l'enregistrement NS pour la zone hébergée sur 60 secondes maximum. 
+ Définissez la durée de vie minimale pour l'enregistrement SOA pour la zone hébergée sur 60 secondes maximum. Il s'agit de la dernière valeur de l'enregistrement SOA.

Si vous attribuez accidentellement à votre bureau d'enregistrement des adresses IP incorrectes pour vos serveurs de noms en marque blanche, votre site web devient indisponible et reste indisponible pendant la durée de vie après la résolution du problème. En définissant une durée de vie courte, vous réduisez le temps d'indisponibilité de votre site web.

Pour plus d'informations sur la création de zones hébergées et la spécification d'un ensemble de délégation réutilisable pour les serveurs de noms des zones hébergées, consultez [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)le *manuel Amazon Route 53 API Reference*.

## Étape 3 : Recréer des enregistrements pour vos zones hébergées
<a name="white-label-name-servers-create-resource-record-sets"></a>

Créez des enregistrements dans les zones hébergées que vous avez créées à l'étape 2 :
+ **Si vous migrez un service DNS pour vos domaines vers Amazon Route 53** – Vous pouvez créer des registres en important des informations concernant vos registres existants. Pour de plus amples informations, veuillez consulter [Création d'enregistrements par importation d'un fichier de zone](resource-record-sets-creating-import.md).
+ **Si vous remplacez des zones hébergées existantes pour pouvoir utiliser des serveurs de noms en marque blanche** – Dans les nouvelles zones hébergées, recréez les registres qui apparaissent dans vos zones hébergées actuelles. Route 53 ne permet pas d'exporter des registres depuis une zone hébergée, mais certains fournisseurs tiers le permettent. Vous pouvez ensuite utiliser la fonction d'importation Route 53 pour importer des registres sans alias, pour lesquels la politique de routage est simple. Il n'existe aucun moyen d'exporter et de réimporter des enregistrements d'alias ou des enregistrements pour lesquels la stratégie de routage n'est pas simple.

  Pour plus d'informations sur la création d'enregistrements à l'aide de l'API Route 53, consultez [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)le *manuel Amazon Route 53 API Reference*. Pour plus d'informations sur la création de registres à l'aide de la console Route 53, consultez [Utilisation des enregistrements](rrsets-working-with.md).

## Étape 4 : Obtenir des adresses IP
<a name="white-label-name-servers-get-ip-addresses"></a>

Obtenez les IPv6 adresses IPv4 et des serveurs de noms du jeu de délégation réutilisable, puis complétez le tableau suivant. 


****  

| Nom d'un serveur de noms dans votre ensemble de délégations réutilisables (exemple : Ns-2048.awsdns-64.com) | IPv4 et IPv6 adresses                                             | Le nom que vous souhaitez attribuer au serveur de noms en marque blanche (exemple : ns1.example.com) | 
| --- | --- | --- | 
|   | IPv4: IPv6:   |   | 
|   | IPv4: IPv6:   |   | 
|   | IPv4: IPv6:   |   | 
|   | IPv4: IPv6:   |   | 

Supposons par exemple que les quatre serveurs de noms de votre ensemble de délégations réutilisables sont :
+ ns-2048.awsdns-64.com
+ ns-2049.awsdns-65.net
+ ns-2050.awsdns-66.org
+ ns-2051.awsdns-67.co.uk

Voici les commandes Linux et Windows à exécuter pour obtenir les adresses IP pour le premier de vos quatre serveurs de noms :

**Commandes dig pour Linux**

```
% dig A ns-2048.awsdns-64.com +short
192.0.2.117
```

```
% dig AAAA ns-2048.awsdns-64.com +short
2001:db8:85a3::8a2e:370:7334
```

**commande nslookup pour Windows**

```
c:\> nslookup ns-2048.awsdns-64.com
Non-authoritative answer:
Name:    ns-2048.awsdns-64.com
Addresses:  2001:db8:85a3::8a2e:370:7334
          192.0.2.117
```

## Étape 5 : Créer des enregistrements pour les serveurs de noms en marque blanche
<a name="white-label-name-servers-create-white-label-resource-record-sets"></a>

Dans la zone hébergée portant le même nom (par exemple, example.com) que le nom de domaine des serveurs de noms en marque blanche (par exemple, ns1.example.com), créez huit enregistrements : 
+ Un enregistrement A pour chaque serveur de noms en marque blanche
+ Un enregistrement AAAA pour chaque serveur de noms en marque blanche

**Important**  
Si vous utilisez les mêmes serveurs de noms en marque blanche pour plusieurs zones hébergées, n'effectuez pas cette opération pour les autres zones hébergées.

Pour chaque enregistrement, spécifiez les valeurs suivantes. Reportez-vous au tableau que vous avez rempli à l'étape précédente :

**Stratégie de routage**  
Spécifiez **Simple routing** (Routage simple).

**Nom de l’enregistrement**  
Le nom que vous souhaitez attribuer à l'un de vos serveurs de noms en marque blanche, par exemple, ns1.example.com. Pour le préfixe (ns1 dans cet exemple), vous pouvez utiliser n'importe quelle valeur valide dans un nom de domaine.

**Valeur/acheminer le trafic vers**  
 IPv6 Adresse IPv4 ou de l'un des serveurs de noms Route 53 de votre ensemble de délégations réutilisable.  
Si vous spécifiez des adresses IP incorrectes lors de la création d'enregistrements pour vos serveurs de noms en marque blanche, votre site web ou votre application web devient indisponible sur Internet lorsque vous effectuez les étapes suivantes. Même si vous corrigez immédiatement les adresses IP, votre site web ou votre application web reste inaccessible pendant la durée de vie définie.

**Type de registre**  
Spécifiez **A** lorsque vous créez des enregistrements pour les IPv4 adresses.  
Spécifiez **AAAA** lorsque vous créez des enregistrements pour les IPv6 adresses.

**TTL (secondes)**  
Cette valeur correspond à la durée pendant laquelle les résolveurs DNS mettent en cache les informations contenues dans ce registre avant de transférer une autre requête DNS à Route 53. Nous vous recommandons de spécifier une valeur initiale de 60 secondes maximum, afin de pouvoir procéder à une récupération rapide si vous spécifiez accidentellement des valeurs incorrectes dans ces enregistrements.

## Étape 6 : Mettre à jour les enregistrements NS et SOA
<a name="white-label-name-servers-update-ns-soa-records"></a>

Mettez à jour les enregistrements SOA et NS dans les zones hébergées pour lesquelles vous souhaitez utiliser des serveurs de noms en marque blanche. Effectuez les étapes 6 à 8 pour une zone hébergée et le domaine correspondant en même temps, puis répétez l'opération pour une autre zone hébergée et le domaine correspondant.

**Important**  
Commencez par la zone hébergée Amazon Route 53 portant le même nom de domaine (par exemple, example.com) que les serveurs de noms en marque blanche (par exemple, ns1.example.com).

1. Mettez à jour le registre SOA en remplaçant le nom du serveur de noms Route 53 par le nom de l'un de vos serveurs de noms en marque blanche.

   **Exemple**

   Remplacez le nom du serveur de noms Route 53 :

   `ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60`

   par le nom de l'un de vos serveurs de noms en marque blanche :

   `ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60`
**Note**  
Vous avez modifié la dernière valeur, la durée de vie (TTL), dans [Étape 2 : créer ou recréer des zones hébergées Amazon Route 53 et modifier la TTL des registres NS et SOA](#white-label-name-servers-create-hosted-zones).

   Pour plus d'informations sur la mise à jour de registres à l'aide de la console Route 53, consultez [Modification des enregistrements](resource-record-sets-editing.md).

1. Dans l'enregistrement NS, notez les noms des serveurs de noms actuels pour le domaine, afin de pouvoir les rétablir si nécessaire.

1. Mettez à jour l'enregistrement NS. Remplacez les noms des serveurs de noms Route 53 par les noms de vos quatre serveurs de noms en marque blanche, par exemple, `ns1.example.com`, `ns2.example.com`, `ns3.example.com` et `ns4.example.com`. 

## Étape 7 : Créer des enregistrements de type glue et changer les serveurs de noms du bureau d'enregistrement
<a name="white-label-name-servers-create-glue-records"></a>

Utilisez la méthode fournie par le bureau d'enregistrement pour créer des enregistrements de type glue et changer les serveurs de noms du bureau d'enregistrement :

1. Ajoutez des enregistrements de type glue :
   + **Si vous mettez à jour le domaine portant le même nom de domaine que les serveurs de noms en marque blanche** – Créez quatre registres Glue pour lesquels les noms et les adresses IP correspondent aux valeurs obtenues à l'étape 4. Incluez à la fois l' IPv6 adresse IPv4 et l'adresse d'un serveur de noms en marque blanche dans l'enregistrement Glue correspondant, par exemple :

     **ns1.example.com** – Adresses IP = 192.0.2.117 et 2001:db8:85a3::8a2e:370:7334

     Les bureaux d'enregistrement utilisent une terminologie riche pour les enregistrements de type glue. Cette opération est également qualifiée d'enregistrement de nouveaux serveurs de noms.
   + **Si vous mettez à jour un autre domaine** – Si Route 53 est votre service DNS, vous devez d'abord terminer l'étape de la puce précédente et créer les glue records correspondants au nom de domaine. Ensuite, passez directement à l'étape 2 de cette procédure.

1. Modifiez les serveurs de noms du domaine par les noms de vos serveurs de noms en marque blanche.

Si vous utilisez Amazon Route 53 en tant que service DNS, consultez [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md).

## Étape 8 : Surveiller le trafic du site web ou de l'application
<a name="white-label-name-servers-monitor-traffic"></a>

Surveillez le trafic du site web ou de l'application pour lequel vous avez créé des enregistrements de type glue et modifié les serveurs de noms à l'étape 7 :
+ **Si le trafic s'interrompt** – Utilisez la méthode fournie par le bureau d'enregistrement pour modifier les serveurs de noms pour le domaine pour rétablir les serveurs de noms Route 53 précédents. Il s'agit des serveurs de noms que vous avez notés à l'étape 6b. Déterminez ce qui s'est mal passé.
+ **Si le trafic n'est pas affecté** – Répétez les étapes 6 à 8 pour les autres zones hébergées pour lesquelles vous souhaitez utiliser les mêmes serveurs de noms en marque blanche. 

## Étape 9 : TTLs Revenez à leurs valeurs d'origine
<a name="white-label-name-servers-change-ttls-back"></a>

Pour toutes les zones hébergées qui utilisent désormais des serveurs de noms en marque blanche, modifiez les valeurs suivantes :
+ Modifiez la durée de vie de l'enregistrement NS pour la zone hébergée par une valeur plus courante, par exemple, 172 800 secondes (deux jours).
+ Remplacez la durée de vie minimale pour l'enregistrement SOA de la zone hébergée par une valeur plus courante, par exemple 900 secondes. Il s'agit de la dernière valeur de l'enregistrement SOA.

## Étape 10 : (Facultatif) Contacter les services DNS récursifs
<a name="white-label-name-servers-contact-recursive-dns-services"></a>

*Facultatif* Si vous utilisez le routage de géolocalisation Amazon Route 53, contactez les services DNS récursifs qui prennent en charge l' edns-client-subnetextension de EDNS0 et donnez-leur les noms de vos serveurs de noms en marque blanche. Cela permet de garantir que ces services DNS continueront à acheminer les requêtes DNS vers l'emplacement Route 53 optimal en fonction de l'emplacement géographique approximatif duquel provient la requête.

# Registres NS et SOA créés par Amazon Route 53 pour une zone hébergée publique
<a name="SOA-NSrecords"></a>

Pour chaque zone hébergée publique que vous créez, Amazon Route 53 crée automatiquement un registre de serveur de noms (NS) et un registre de source de noms (SOA). Vous avez rarement besoin de modifier ces enregistrements. 

**Topics**
+ [Enregistrement de serveur de noms (NS)](#NSrecords)
+ [Enregistrement de source de noms (SOA)](#SOArecords)

## Enregistrement de serveur de noms (NS)
<a name="NSrecords"></a>

Amazon Route 53 crée automatiquement un registre de serveur de noms (NS) portant le même nom que votre zone hébergée. Il répertorie les quatre serveurs de noms qui sont les serveurs de noms faisant autorité pour votre zone hébergée. Sauf dans de rares cas, nous vous recommandons de ne pas ajouter, modifier ou supprimer des serveurs de noms dans cet enregistrement.

Les exemples suivants illustrent le format des noms des serveurs de noms Route 53 (il s'agit d'exemples ; ne les utilisez pas lorsque vous mettez à jour les registres des serveurs de noms de votre bureau d'enregistrement) :
+ *ns-2048.awsdns-64.com*
+ *ns-2049.awsdns-65.net*
+ *ns-2050.awsdns-66.org*
+ *ns-2051.awsdns-67.co.uk*

Pour obtenir la liste des serveurs de noms pour votre zone hébergée :

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones** (Zones hébergées).

1. Sur la page **Hosted zones** (Zones hébergées), choisissez la case d'option (pas le nom) de la zone hébergée, puis **View details** (Afficher les détails).

1. Sur la page des détails de la zone hébergée, choisissez **Hosted zone details** (Détails de la zone hébergée).

1. Notez les quatre serveurs répertoriés dans **Name servers** (Serveurs de noms).

Pour plus d'informations sur la migration d'un service DNS d'un autre fournisseur de services DNS vers Route 53, consultez [Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existantFaire de Route 53 le service DNS d'un domaine existant](MigratingDNS.md).

## Enregistrement de source de noms (SOA)
<a name="SOArecords"></a>

L'enregistrement de source de noms (SOA) identifie les informations DNS de base relatives au domaine, par exemple :

```
1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400
```

Un enregistrement SOA inclut les éléments suivants :
+ Le serveur de noms Route 53 ayant créé le registre SOA, par exemple, `ns-2048.awsdns-64.net`.
+ L'adresse e-mail de l'administrateur. Le symbole `@` est remplacé par une période, par exemple, `hostmaster.example.com`. La valeur par défaut est une adresse e-mail amazon.com qui n'est pas contrôlée.
+ Un numéro de série que vous pouvez facultativement augmenter chaque fois que vous mettez à jour un registre dans la zone hébergée. Route 53 n'augmente pas automatiquement le numéro. (Le numéro de série est utilisé par les services DNS prenant en charge les serveurs DNS secondaires.) Dans l'exemple, cette valeur est `1`.
+ Un temps d'actualisation, en secondes, pendant lequel les serveurs DNS secondaires patientent avant d'interroger l'enregistrement SOA du serveur DNS principal pour vérifier les modifications. Dans l'exemple, cette valeur est `7200`.
+ L'intervalle de nouvelle tentative, en secondes, pendant lequel un serveur secondaire patiente avant de réessayer le transfert d'une zone ayant échoué. En général, l'intervalle de nouvelle tentative est inférieur au temps d'actualisation. Dans l'exemple, cette valeur est `900` (15 minutes). 
+ Le délai, en secondes, pendant lequel un serveur secondaire continue d'essayer de finaliser un transfert de zone. Si ce délai expire avant la réussite d'un transfert de zone, le serveur secondaire ne répondra plus aux requêtes, car il considère que les données sont trop anciennes pour être fiables. Dans l'exemple, cette valeur est `1209600` (deux semaines).
+ La durée de vie minimale (TTL). Cette valeur permet de définir la durée pendant laquelle les résolveurs récursifs doivent mettre en cache les réponses suivantes provenant de Route 53 :  
**NXDOMAIN**  
Il n'existe aucun enregistrement de quelque type que ce soit avec le nom spécifié dans la requête DNS, comme example.com. Il n'existe pas non plus d'enregistrements qui sont des enfants du nom spécifié dans la requête DNS, comme zenith.example.com.  
**NODATA**  
Il existe au moins un enregistrement portant le nom spécifié dans la requête DNS, mais aucun de ces enregistrements n'a le type (A par exemple) spécifié dans la requête DNS.

  Lorsqu'un résolveur DNS met en cache une réponse NXDOMAIN ou NODATA, ce résultat est appelé *mise en cache négative*. 

  La durée de mise en cache négative est la plus courte des valeurs suivantes :
  + Cette valeur est la TTL minimale dans le registre SOA. Dans cet exemple, la valeur est `86400` (un jour)
  + Valeur de la durée de vie (TTL) pour l'enregistrement SOA. La valeur par défaut est de 900 secondes. Pour plus d'informations sur la modification de cette valeur, consultez [Modification des enregistrements](resource-record-sets-editing.md).

  Lorsque Route 53 répond à des requêtes DNS avec une réponse NXDOMAIN ou NODATA (réponse négative), le tarif pour les requêtes standard vous est facturé. (Consultez « Requêtes » dans [Tarifications Amazon Route 53](https://aws.amazon.com/route53/pricing/)). Si vous vous inquiétez du coût des réponses négatives, vous pouvez modifier la TTL du registre SOA, la TTL minimale dans le registre SOA (cette valeur), ou les deux. Notez que leur augmentation TTLs, qui s'applique aux réponses négatives pour l'ensemble de la zone hébergée, peut avoir des effets à la fois positifs et négatifs :
  + Les résolveurs DNS sur Internet mettent en cache l'inexistence de registres pendant des périodes plus longues, ce qui réduit le nombre de requêtes transférées vers Route 53. Cela réduit les frais Route 53 des requêtes DNS.
  + Toutefois, si vous supprimez par erreur un enregistrement valide et que vous le recréez ultérieurement, les résolveurs DNS mettront en cache la réponse négative (cet enregistrement n'existe pas) pendant une période plus longue. Cela allonge le temps pendant lequel vos clients ou utilisateurs ne peuvent pas accéder à la ressource correspondante, comme un serveur web pour acme.example.com. <a name="get-soa-records-in-route-53-procedure"></a>

**Pour trouver vos enregistrements SOA dans Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Sélectionnez le nom lié du domaine pour lequel vous souhaitez afficher les enregistrements.

1. Sur la page **Records** (Enregistrements), vous pouvez voir tous les enregistrements répertoriés et filtrer les enregistrements pour trouver votre valeur SOA.

# Permettre une restauration accélérée pour gérer les enregistrements DNS publics
<a name="accelerated-recovery"></a>

La restauration accélérée Route 53 pour la gestion des enregistrements DNS publics est conçue pour atteindre un objectif de temps de restauration (RTO) de 60 minutes en cas d'indisponibilité du service dans la région de l'est des États-Unis (Virginie du Nord). Lorsque cette option est activée sur une zone hébergée publique Route 53, vous pourrez recommencer à apporter des modifications aux enregistrements DNS de la zone hébergée publique dans les 60 minutes environ après avoir AWS détecté que les opérations dans la région USA Est (Virginie du Nord) étaient perturbées.

**Important**  
La restauration accélérée n'est disponible que pour les zones hébergées publiques. Les zones hébergées privées ne sont pas prises en charge.

**Note**  
La résolution des requêtes DNS à partir du plan de données Route 53 continue de fonctionner normalement en cas de panne du service régional. Consultez [Resilience in Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) pour mieux comprendre les opérations du plan de données par rapport au plan de contrôle.

**Topics**
+ [Comment fonctionne la restauration accélérée des enregistrements DNS publics](#accelerated-recovery-how-it-works)
+ [Soumission à nouveau des modifications DNS après un basculement](#accelerated-recovery-resubmit)
+ [Retour vers la région de l'est des États-Unis (Virginie du Nord)](#accelerated-recovery-failback)
+ [Considérations supplémentaires](#accelerated-recovery-considerations)
+ [Comment activer une restauration accélérée pour gérer les enregistrements DNS publics](#accelerated-recovery-enable)

## Comment fonctionne la restauration accélérée des enregistrements DNS publics
<a name="accelerated-recovery-how-it-works"></a>

Lorsque la restauration accélérée est activée, Route 53 conserve une copie de votre zone hébergée publique dans la région USA Ouest (Oregon). Si les services de la région de l'est des États-Unis (Virginie du Nord) deviennent indisponibles pendant une période prolongée, Route 53 effectuera le basculement dans les 60 minutes, redirigeant automatiquement les opérations du plan de contrôle pour vos zones hébergées publiques activées pour la restauration accélérée vers la région de l'ouest des États-Unis (Oregon). Vous pouvez ensuite continuer à apporter des modifications au DNS par programmation via la CLI, le SDK et l'API. Notez qu'un ensemble limité de méthodes d'API sera disponible lors du basculement. Consultez la section « Considérations supplémentaires » pour plus de détails. Lorsque la région se rétablit, Route 53 exécute la procédure de retour en arrière, redirigeant automatiquement les opérations du plan de contrôle vers la région de l'est des États-Unis (Virginie du Nord).

**Note**  
Avant toute atteinte à la région de l'est des États-Unis (Virginie du Nord), vous devez d'abord activer la restauration accélérée pour gérer les enregistrements DNS publics sur votre zone hébergée publique. Cela peut être effectué via la console, la CLI, le SDK ou l'API (voir la section intitulée *Comment activer la restauration accélérée pour la gestion des enregistrements DNS publics* sur cette page ci-dessous). Vous ne pouvez pas activer la restauration accélérée pour gérer les enregistrements DNS publics après un basculement.

## Soumission à nouveau des modifications DNS après un basculement
<a name="accelerated-recovery-resubmit"></a>

Dans des conditions normales, les modifications apportées aux zones hébergées publiques pour lesquelles la restauration accélérée est activée seront acceptées par la région USA Est (Virginie du Nord) et seront ensuite répliquées avec succès dans la région USA Ouest (Oregon). Toutefois, en cas d'interruption de service dans la région USA Est (Virginie du Nord), certaines modifications peuvent être acceptées par la région USA Est (Virginie du Nord), mais ne pas être reproduites dans la région USA Ouest (Oregon). Ces modifications en vol sont appelées « modifications bloquées ». Une fois le basculement terminé, Route 53 vous recommande de soumettre à nouveau les modifications bloquées avant de reprendre vos flux de travail DNS. Vous pouvez y parvenir soit en utilisant l'API, soit en utilisant AWS CloudFormation les méthodes décrites ci-dessous.

### Utilisation de l'API pour suivre et soumettre les modifications du DNS
<a name="accelerated-recovery-api"></a>

Si vous utilisez l'API Route 53, la AWS CLI ou AWS SDKs pour gérer les enregistrements DNS, vous devrez utiliser l'[ChangeResourceRecordSets API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) et l'[GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) pour soumettre et suivre les modifications DNS, respectivement.

Lorsque vous utilisez l' ChangeResourceRecordSets API pour apporter des modifications au DNS, Route 53 renvoie un identifiant (ID) pour la modification que vous avez apportée (voir [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)pour les détails de l'objet de réponse aux modifications). Vous pouvez fournir cet ID dans une demande ultérieure à l' GetChange API et observer l'état de la modification. Les modifications DNS avec le statut INSYNC ont été répliquées dans la région ouest des États-Unis (Oregon) et propagées à tous les serveurs DNS Route 53. Vous n'avez aucune autre action à effectuer sur ces modifications avant ou après un basculement. Toutefois, en cas de déficience dans la région de l'est des États-Unis (Virginie du Nord), la valeur GetChange peut être renvoyée en attente, ce qui indique que votre modification n'a peut-être pas été reproduite dans la région de l'ouest des États-Unis (Oregon). Si tel est le cas, une fois le basculement terminé, il GetChange reviendra NoSuchChange, indiquant que Route 53 n'a pas pu répliquer cette modification DNS. Par conséquent, après le basculement, vous pouvez ignorer ces modifications DNS bloquées en toute sécurité et les soumettre à nouveau en tant que nouvelles modifications DNS. Vous saurez que le processus de basculement est terminé lorsque Route 53 publiera un message sur le AWS Health Dashboard.

### Utilisation AWS CloudFormation pour suivre et soumettre les modifications
<a name="accelerated-recovery-cloudformation"></a>

AWS CloudFormation suit automatiquement l'état de réplication de vos modifications DNS à l'aide de l' GetChange API, et effectue une mise à jour uniquement une fois que les modifications DNS ont été confirmées comme INSYNC. Si vous utilisez CloudFormation pour gérer les enregistrements DNS et que la région USA Est (Virginie du Nord) devient indisponible, les actions que vous effectuez ne CloudFormation seront pas effectuées correctement pendant la période d'indisponibilité. Cependant, vous pouvez simplement réessayer les mêmes actions pour permettre de soumettre à nouveau CloudFormation les modifications DNS, une fois le processus de basculement de Route 53 terminé.

## Retour vers la région de l'est des États-Unis (Virginie du Nord)
<a name="accelerated-recovery-failback"></a>

La route 53 fera échouer les opérations de l'avion de contrôle de votre zone hébergée publique vers la région de l'est des États-Unis (Virginie du Nord) une fois que la région se sera rétablie. Pendant le repli, vous n'aurez pas besoin de soumettre à nouveau vos modifications DNS, car aucune modification bloquée ne sera introduite au cours de ce processus.

## Considérations supplémentaires
<a name="accelerated-recovery-considerations"></a>

Il y a quelques considérations supplémentaires à prendre en compte concernant la fonction de restauration accélérée :

1. Vous ne pourrez pas créer de nouvelles zones hébergées, supprimer des zones hébergées existantes, activer la signature DNSSEC ou désactiver la signature DNSSEC pendant le basculement.

1. AWS PrivateLink les connexions ne fonctionneront pas après le basculement, mais fonctionneront à nouveau après un retour en arrière vers la région USA Est (Virginie du Nord).

1. [CloudFront les forfaits ne](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) sont pas pris en charge pour le moment.

1. Les zones hébergées pour lesquelles la restauration accélérée est activée ne peuvent pas être supprimées. Vous devez désactiver la restauration accélérée avant de tenter de supprimer la zone hébergée.

1. Pendant le basculement, les méthodes d'API suivantes continueront d'être prises en charge pour les zones hébergées publiques pour lesquelles la restauration accélérée est activée. Cependant, toutes les autres méthodes de l'API Route 53 ne seront pas fonctionnelles tant qu'un retour en arrière ne se produira pas.
   + `ChangeResourceRecordSets`
   + `GetChange`
   + `GetGeoLocation`
   + `GetHostedZone`
   + `GetHostedZoneCount`
   + `GetHostedZoneLimit`
   + `GetReusableDelegationSet`
   + `GetReusableDelegationSetLimit`
   + `ListGeoLocations`
   + `ListHostedZones`
   + `ListHostedZonesByName`
   + `ListResourceRecordSets`
   + `ListReusableDelegationSets`

## Comment activer une restauration accélérée pour gérer les enregistrements DNS publics
<a name="accelerated-recovery-enable"></a>

Vous pouvez activer la restauration accélérée pour gérer les enregistrements DNS publics à l'aide de la console Route 53, de l'API, de la CLI ou du SDK. Le temps nécessaire pour activer la restauration accélérée dépend de la taille de votre zone hébergée publique et d'autres facteurs. Vous devez prévoir que le processus d'activation de la restauration accélérée prendra plusieurs heures. Vous pouvez vérifier l'état du processus d'activation dans l'onglet Restauration accélérée de votre zone hébergée publique ou via l'`GetHostedZone`API. Au fur et à mesure que le processus sera finalisé, il y aura une brève période pouvant aller jusqu'à plusieurs minutes pendant laquelle les modifications du DNS ne seront pas acceptées. Une fois terminées, les modifications du DNS peuvent se poursuivre normalement.

**Pour activer et désactiver la restauration accélérée à l'aide de la console Route 53**

1. Ouvrez la console Route 53 à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Choisissez la zone hébergée publique pour laquelle vous souhaitez activer la restauration accélérée.

1. Dans l'onglet **Récupération accélérée**, choisissez **Activer**.

1. Sélectionnez **Enregistrer les modifications**.

1. Surveillez l'état de la zone hébergée. L'état indique **Activer la restauration accélérée lors de** l'installation et passe à **Activé** une fois l'opération terminée.

Vous pouvez désactiver la restauration accélérée en suivant les mêmes étapes que ci-dessus, mais en choisissant plutôt **Désactiver**.

Exemple de CLI pour activer

```
aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789
```

Exemple de CLI à désactiver

```
aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789
```

# Utilisation des zones hébergées privées
<a name="hosted-zones-private"></a>

Une *zone hébergée privée* est un conteneur qui contient des informations sur la manière dont vous souhaitez qu'Amazon Route 53 réponde aux requêtes DNS pour un domaine et ses sous-domaines au sein d'un ou de plusieurs domaines VPCs que vous créez avec le service Amazon VPC. Voici comment fonctionnent les zones hébergées privées :

1. Vous créez une zone hébergée privée, comme exemple.com, et spécifiez le VPC que vous souhaitez associer à la zone hébergée. Après avoir créé la zone hébergée, vous pouvez en VPCs associer d'autres.

1. Vous créez des registres dans la zone hébergée qui déterminent la façon dont Route 53 répond aux requêtes DNS pour votre domaine et ses sous-domaines au sein de vos VPC. Par exemple, supposons que vous ayez un serveur de base de données qui s'exécute sur une instance EC2 dans le VPC que vous avez associé à votre zone hébergée privée. Vous créez un enregistrement A ou AAAA, par exemple db.exemple.com, et vous indiquez l'adresse IP du serveur de base de données. 

   Pour plus d'informations sur les enregistrements , consultez la section [Utilisation des enregistrements](rrsets-working-with.md). Pour plus d'informations sur les exigences Amazon VPC inhérentes à l'utilisation de zones hébergées privées, consultez [Utilisation des zones hébergées privées](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) dans le *Guide de l'utilisateur Amazon VPC*.

1. Lorsqu'une application envoie une requête DNS pour db.exemple.com, Route 53 renvoie l'adresse IP correspondante. Pour obtenir une réponse depuis une zone hébergée privée, vous devez également exécuter une instance EC2 dans l'une des zones associées VPCs (ou disposer d'un point de terminaison entrant issu d'une configuration hybride). Si vous essayez d'interroger une zone hébergée privée en dehors de votre configuration hybride VPCs ou de votre configuration hybride, la requête sera résolue de manière récursive sur Internet.

1. L'application utilise l'adresse IP obtenue depuis Route 53 pour établir une connexion avec le serveur de base de données.

Lorsque vous créez une zone hébergée privée, les serveurs de noms suivants sont utilisés :
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk

Ces serveurs de noms sont utilisés parce que le protocole DNS exige que chaque zone hébergée possède un ensemble d'enregistrements NS. Ces serveurs de noms sont réservés et ne sont jamais utilisés par les zones hébergées publiques Route 53. Vous pouvez uniquement interroger ces zones via le résolveur VPC dans un VPC associé à la zone hébergée en utilisant un point de terminaison entrant connecté au point VPCs spécifié dans la zone hébergée privée.

 Lorsque les serveurs de noms sont visibles sur Internet, VPC Resolver ne se connecte pas aux adresses des serveurs de noms. De plus, les informations relatives à la zone hébergée privée ne sont pas renvoyées si vous interrogez directement les serveurs de noms sur Internet. Au lieu de cela, le résolveur VPC détecte que les requêtes se trouvent dans un espace de noms privé basé sur les associations VPC à zones hébergées et utilise une connectivité privée directe pour atteindre les serveurs DNS privés.

**Note**  
Vous pouvez modifier l'enregistrement NS défini dans une zone hébergée privée si vous le souhaitez et la résolution DNS privée fonctionnera toujours. Nous vous déconseillons de le faire, mais si vous le souhaitez, vous devez utiliser des noms de domaine réservés qui ne sont pas utilisés par les serveurs DNS publics.

Vous pouvez utiliser une zone hébergée *publique* Route 53 pour acheminer le trafic de votre domaine sur Internet. Pour de plus amples informations, veuillez consulter [Utilisation des zones hébergées publiques](AboutHZWorkingWith.md).

**Topics**
+ [Remarques sur l'utilisation des zones hébergées privées](hosted-zone-private-considerations.md)
+ [Création d'une zone hébergée privée](hosted-zone-private-creating.md)
+ [Affichage des zones hébergées privées](hosted-zone-private-listing.md)
+ [Associer davantage VPCs à une zone hébergée privée](hosted-zone-private-associate-vpcs.md)
+ [Associer un Amazon VPC et une zone hébergée privée que vous avez créée avec différents comptes AWS](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [Dissociation VPCs d'une zone hébergée privée](hosted-zone-private-disassociate-vpcs.md)
+ [Suppression d'une zone hébergée privée](hosted-zone-private-deleting.md)
+ [Autorisations VPC](hosted-zone-private-vpc-permissions.md)

# Remarques sur l'utilisation des zones hébergées privées
<a name="hosted-zone-private-considerations"></a>

Lorsque vous utilisez des zones hébergées privées, notez les informations suivantes.
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)

**Paramètres Amazon VPC**  
Pour utiliser les zones hébergées privées, vous devez définir les paramètres Amazon VPC suivants sur `true` :  
+ `enableDnsHostnames`
+ `enableDnsSupport`
Pour plus d'informations, consultez [Afficher et mettre à jour les attributs DNS de votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) dans le guide de l'utilisateur Amazon *VPC*.

**Surveillances d'états Route 53**  
Dans une zone hébergée privée, vous pouvez associer les vérifications de santé de Route 53 uniquement aux enregistrements relatifs au basculement, aux réponses à valeurs multiples, à la pondération, à la latence, à la géolocalisation et aux enregistrements de géoproximité. Pour plus d'informations sur l'association de vérifications de l'état à des enregistrements de basculement, consultez [Configuration du basculement dans une zone hébergée privée](dns-failover-private-hosted-zones.md).

** Politiques de routage des registres dans une zone hébergée privée prises en charge**  
Vous pouvez utiliser les stratégies de routage suivantes lors de la création d'enregistrements dans une zone hébergée privée :  
+ [Routage simple](routing-policy-simple.md)
+ [Routage par basculement](routing-policy-failover.md)
+ [Multivalue answer routing (Routage de réponse multivaleur)](routing-policy-multivalue.md)
+ [Weighted routing (Routage pondéré)](routing-policy-weighted.md)
+ [Routage basé sur la latence](routing-policy-latency.md)
+ [Routage de géolocalisation](routing-policy-geo.md)
+ [Routage par géoproximité](routing-policy-geoproximity.md)
La création d'enregistrements dans une zone hébergée privée à l'aide d'autres stratégies de routage de géolocalisation ou de latence n'est pas prise en charge.

** DNS vue divisée**  
Vous pouvez utiliser Route 53 pour configurer un DNS en mode d'affichage fractionné, également connu sous le nom « DNS à horizon fractionné ». Dans le DNS en vue divisée, vous utilisez le même nom de domaine (example.com) pour des utilisations internes (accounting.example.com) et externes, notamment votre site web public (www.example.com). Vous pouvez également vouloir utiliser le même nom de sous-domaine en interne et en externe, mais proposer un contenu différent ou exiger une authentification différente pour les utilisateurs internes et externes.  
Pour configurer le DNS en vue divisée, effectuez les opérations suivantes :  

1. Créez des zones hébergées publiques et privées ayant le même nom (Le DNS en vue divisée continue à fonctionner si vous utilisez un autre service DNS pour la zone hébergée publique.)

1. Associez un ou plusieurs Amazon VPCs à la zone hébergée privée. Route 53 VPC Resolver utilise la zone hébergée privée pour acheminer les requêtes DNS dans la zone spécifiée. VPCs

1. Créez des enregistrements dans chaque zone hébergée. Les enregistrements de la zone hébergée publique contrôlent la manière dont le trafic Internet est acheminé, tandis que les enregistrements de la zone hébergée privée contrôlent la manière dont le trafic est acheminé sur votre Amazon. VPCs
Si vous devez résoudre les noms de votre VPC et de vos charges de travail sur site, vous pouvez utiliser Route 53 VPC Resolver. Pour de plus amples informations, veuillez consulter [Qu'est-ce que Route 53 VPC Resolver ?](resolver.md).

** Zones hébergées publiques et privées dont les espaces de noms se chevauchent**  
Si vous avez des zones hébergées privées et publiques dont les espaces de noms se chevauchent, tels que example.com et accounting.example.com, VPC Resolver achemine le trafic en fonction de la correspondance la plus spécifique. Lorsque les utilisateurs sont connectés à une instance EC2 d'un Amazon VPC que vous avez associé à la zone hébergée privée, voici comment Route 53 VPC Resolver gère les requêtes DNS :  

1. VPC Resolver évalue si le nom de la zone hébergée privée correspond au nom de domaine indiqué dans la demande, par exemple accounting.example.com. Une correspondance se définit de l'une des façons suivantes :
   + Une correspondance identique
   + Le nom de la zone hébergée privée est un parent du nom de domaine de la demande. Supposons par exemple que le nom de domaine de la demande soit :

     **seattle.accounting.example.com**

     Les zones hébergées suivantes correspondent, car elles sont parents de seattle.accounting.example.com :
     + **accounting.example.com**
     + **example.com**

   S'il n'existe aucune zone hébergée privée correspondante, VPC Resolver transmet la demande à un résolveur DNS public, et votre demande est résolue en tant que requête DNS normale.

1. Si le nom d'une zone hébergée privée correspond au nom de domaine de la demande, une recherche est lancée dans la zone hébergée afin de trouver un enregistrement correspondant au nom de domaine et au type DNS de la demande, par exemple un enregistrement A pour accounting.example.com.
**Note**  
S'il existe une zone hébergée privée correspondante mais qu'aucun enregistrement ne correspond au nom de domaine et au type de demande, VPC Resolver ne transmet pas la demande à un résolveur DNS public. Au lieu de cela, elle renvoie une réponse NXDOMAIN (domaine non existant) au client.

**Zones hébergées privées dont les espaces de noms se chevauchent**  
Si vous avez au moins deux zones hébergées privées dont les espaces de noms se chevauchent, tels que example.com et accounting.example.com, VPC Resolver achemine le trafic en fonction de la correspondance la plus spécifique.   
Si vous disposez d'une zone hébergée privée (exemple.com) et d'une règle de résolution VPC Route 53 qui achemine le trafic vers votre réseau pour le même nom de domaine, la règle de résolution VPC a priorité. Consultez [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules).
Lorsque les utilisateurs sont connectés à une instance EC2 d'un Amazon VPC que vous avez associé à toutes les zones hébergées privées, voici comment VPC Resolver gère les requêtes DNS :  

1. VPC Resolver évalue si le nom de domaine indiqué dans la demande, tel que accounting.example.com, correspond au nom de l'une des zones hébergées privées.

1. Si aucune zone hébergée ne correspond exactement au nom de domaine indiqué dans la demande, VPC Resolver recherche une zone hébergée dont le nom est le parent du nom de domaine indiqué dans la demande. Supposons par exemple que le nom de domaine de la demande soit :

   `seattle.accounting.example.com`

   Les zones hébergées suivantes correspondent, car elles sont parents de `seattle.accounting.example.com` :
   + `accounting.example.com`
   + `example.com`

   VPC Resolver choisit `accounting.example.com` parce qu'il est plus spécifique que. `example.com`

1. VPC Resolver recherche dans la zone `accounting.example.com` hébergée un enregistrement correspondant au nom de domaine et au type DNS de la demande, tel qu'un enregistrement A pour. `seattle.accounting.example.com`

   Si aucun enregistrement ne correspond au nom de domaine et au type de demande, VPC Resolver renvoie NXDOMAIN (domaine inexistant) au client.

**Zones hébergées privées et règles du résolveur VPC Route 53**  
Si vous disposez d'une zone hébergée privée (exemple.com) et d'une règle de résolution VPC qui achemine le trafic vers votre réseau pour le même nom de domaine, la règle de résolution VPC a priorité.   
Par exemple, supposons que vous ayez la configuration suivante :  
+ Vous disposez d'une zone hébergée privée appelée example.com et vous l'associez à un VPC.
+ Vous créez une règle de résolution VPC Route 53 qui transfère le trafic de example.com vers votre réseau, et vous associez la règle au même VPC.
Dans cette configuration, la règle VPC Resolver a priorité sur la zone hébergée privée. Les requêtes DNS sont transférées à votre réseau au lieu d'être résolues en fonction des enregistrements de la zone hébergée privée.

** Délégation de responsabilité pour un sous-domaine**  
Vous pouvez désormais créer des enregistrements NS dans une zone hébergée privée pour déléguer la responsabilité d'un sous-domaine. Pour de plus amples informations, veuillez consulter [Tutoriel sur les règles de délégation Resolver](outbound-delegation-tutorial.md).

** Serveurs DNS personnalisés**  
Si vous avez configuré des serveurs DNS personnalisés sur des instances Amazon EC2 dans votre VPC, vous devez configurer ces serveurs DNS pour qu'ils acheminent vos requêtes DNS privées vers l'adresse IP des serveurs DNS fournis par Amazon pour votre VPC. Cette adresse IP est l'adresse IP à la base de votre plage réseau VPC, plus le chiffre deux. Par exemple, si la plage d'adresses CIDR pour votre VPC est 10.0.0.0/16, l'adresse IP du serveur DNS est 10.0.0.2.  
Si vous souhaitez acheminer des requêtes DNS entre VPCs et votre réseau, vous pouvez utiliser VPC Resolver. Pour de plus amples informations, veuillez consulter [Qu'est-ce que Route 53 VPC Resolver ?](resolver.md).

** Autorisations IAM requises**  
Pour créer des zones hébergées privées, vous devez accorder des autorisations IAM pour les actions Amazon EC2 outre les autorisations pour les actions Route 53. Pour plus d'informations, consultez la rubrique [Actions, ressources et clés de condition pour Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) dans la section *Référence de l'autorisation de service*.

# Création d'une zone hébergée privée
<a name="hosted-zone-private-creating"></a>

Une zone hébergée privée est un conteneur pour les enregistrements d'un domaine que vous hébergez dans un ou plusieurs clouds privés virtuels Amazon (VPCs). Vous créez une zone hébergée pour un domaine (tel que exemple.com), puis vous créez des enregistrements pour indiquer à Amazon Route 53 comment vous souhaitez que le trafic soit acheminé pour ce domaine au sein de votre et entre vous. VPCs

**Important**  
Lorsque vous créez une zone hébergée privée, vous devez lui associer un VPC, et le VPC que vous spécifiez doit avoir été créé en utilisant le même compte que celui que vous utilisez pour créer la zone hébergée. Après avoir créé la zone hébergée, vous pouvez y associer d'autres VPCs zones, y compris celles VPCs que vous avez créées à l'aide d'un autre AWS compte.  
Pour associer VPCs ce que vous avez créé à l'aide d'un compte à une zone hébergée privée que vous avez créée à l'aide d'un autre compte, vous devez autoriser l'association, puis l'établir par programmation. Pour de plus amples informations, veuillez consulter [Associer un Amazon VPC et une zone hébergée privée que vous avez créée avec différents comptes AWS](hosted-zone-private-associate-vpcs-different-accounts.md).

Pour plus d'informations sur la création d'une zone hébergée privée à l'aide de l'API Route 53, consultez le document [Référence de l'API Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).

**Pour créer une zone hébergée privée à l'aide de la console Route 53**

1. Pour chaque VPC que vous souhaitez associer à la zone hébergée Route 53, définissez les paramètres VPC suivants sur `true` :
   + `enableDnsHostnames`
   + `enableDnsSupport`

   Pour plus d'informations, consultez [Mise à jour du support DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) dans le *Guide de l'utilisateur Amazon VPC*.

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Si vous débutez avec Route 53, choisissez **Get started** (Mise en route).

   Si vous utilisez déjà Route 53, choisissez **Hosted Zones** (Zones hébergées) dans le panneau de navigation.

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

1. Dans le volet **Create private hosted zone** (Créer une zone hébergée privée), saisissez un nom de domaine et, éventuellement, un commentaire.

   Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

1. Dans la liste **Type**, choisissez **Private hosted zone** (Zone hébergée privée).

1. Dans la liste **VPC ID**, sélectionnez le VPC que vous voulez associer à la zone hébergée.
**Note**  
Si la console affiche le message suivant, vous essayez d'associer une zone hébergée qui utilise le même espace de noms que celui d'une autre zone hébergée au sein du même VPC :  
« A conflicting domain is already associated with the given VPC or Delegation Set. »  
Par exemple, si la zone hébergée A et la zone hébergée B ont le même nom de domaine, comme `example.com`, vous ne pouvez pas associer les deux zones hébergées au même VPC.

1. Choisissez **Create hosted zone** (Créer une zone hébergée).

# Affichage des zones hébergées privées
<a name="hosted-zone-private-listing"></a>

Vous pouvez utiliser la console Amazon Route 53 pour répertorier toutes les zones hébergées que vous avez créées avec le AWS compte actuel. Pour plus d'informations sur la façon de répertorier les zones hébergées à l'aide de l'API Route 53, consultez [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)le *manuel Amazon Route 53 API Reference*. 

**Pour répertorier les zones hébergées associées à un AWS compte**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

   La page **Zones hébergées** affiche automatiquement la liste de toutes les zones hébergées créées à l'aide du AWS compte actuel. La colonne **Type** indique si une zone hébergée est privée ou publique. Sélectionnez l'en-tête de colonne pour regrouper toutes les zones hébergées privées et toutes les zones hébergées publiques.

# Associer davantage VPCs à une zone hébergée privée
<a name="hosted-zone-private-associate-vpcs"></a>

Vous pouvez utiliser la console Amazon Route 53 pour en VPCs associer davantage à une zone hébergée privée si vous avez créé la zone hébergée et en VPCs utilisant le même AWS compte.

**Important**  
Si vous souhaitez associer VPCs ce que vous avez créé en utilisant un compte à une zone hébergée privée que vous avez créée à l'aide d'un autre compte, vous devez d'abord autoriser l'association. En outre, vous ne pouvez pas utiliser la AWS console pour autoriser l'association ou pour l' VPCs associer à la zone hébergée. Pour de plus amples informations, veuillez consulter [Associer un Amazon VPC et une zone hébergée privée que vous avez créée avec différents comptes AWS](hosted-zone-private-associate-vpcs-different-accounts.md).

Pour plus d'informations sur la manière d' VPCs associer davantage à une zone hébergée privée à l'aide de l'API Route 53, consultez [Associer VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) dans le *manuel Amazon Route 53 API Reference*.

**Pour VPCs associer des zones supplémentaires à une zone hébergée privée à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Cliquez sur le bouton radio correspondant à la zone hébergée privée à laquelle vous souhaitez VPCs associer davantage.

1. Choisissez **Modifier**.

1. Choisissez **Add VPC** (Ajouter un VPC).

1. Choisissez la région et l'ID du VPC que vous souhaitez associer à cette zone hébergée.

1. Pour en VPCs associer davantage à cette zone hébergée, répétez les étapes 5 et 6.

1. Sélectionnez **Enregistrer les modifications**.

# Associer un Amazon VPC et une zone hébergée privée que vous avez créée avec différents comptes AWS
<a name="hosted-zone-private-associate-vpcs-different-accounts"></a>

Si vous souhaitez associer un VPC que vous avez créé avec un AWS compte à une zone hébergée privée que vous avez créée avec un autre compte, effectuez la procédure suivante : 

**Pour associer un Amazon VPC et une zone hébergée privée que vous avez créée à différents comptes AWS**

1. A l'aide du compte qui a créé la zone hébergée, autorisez l'association du VPC à la zone hébergée privée en utilisant l'une des méthodes suivantes :
   + **AWS CLI**— Voir [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)dans le manuel de *référence des AWS CLI commandes*
   + ** AWS SDK** ou **AWS Tools for Windows PowerShell**— Consultez la documentation applicable sur la page de [AWS documentation](https://docs.aws.amazon.com/) 
   + **API Amazon Route 53** — Voir [Créer une VPCAssociation autorisation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) dans le manuel de *référence de l'API Amazon Route 53*

   Notez ce qui suit :
   + Si vous souhaitez associer plusieurs sites VPCs que vous avez créés à un compte à une zone hébergée créée avec un compte différent, vous devez soumettre une demande d'autorisation pour chaque VPC.
   + Lorsque vous autorisez l'association, vous devez spécifier l'ID de la zone hébergée, par conséquent, la zone hébergée privée doit déjà exister.
   + Vous ne pouvez pas utiliser la console Route 53 pour autoriser l'association d'un VPC à une zone hébergée privée, ni pour effectuer l'association.

1. A l'aide du compte qui a créé le VPC, associez ce VPC à la zone hébergée. Comme pour autoriser l'association, vous pouvez utiliser le AWS SDK, Tools for Windows PowerShell AWS CLI, l'API Route 53 ou l'API Route 53. Si vous utilisez l'API, utilisez l'VPCWithHostedZoneaction [Associer](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html). 

1. *Recommandé* – Supprimez l'autorisation d'associer le VPC à la zone hébergée. La suppression de l'autorisation n'affecte pas l'association, elle vous empêche seulement de réassocier le VPC à la zone hébergée par la suite. Si vous souhaitez réassocier le VPC à la zone hébergée, vous devrez répéter les étapes 1 et 2 de cette procédure.
**Important**  
`ListHostedZonesByVPC`Renvoie les zones hébergées à partir d'un VPC et `GetHostedZone` l'API renvoie les zones VPCs associées à la zone hébergée. Ils APIs ne prennent en compte que l'association entre la zone hébergée et le VPC créée par l'`AssociateVPCWithHostedZone`API ou lors de la création de la zone hébergée privée. Si vous souhaitez obtenir la liste complète des associations de zones hébergées à un VPC, appelez également. [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html)
**Note**  
Pour connaître le nombre maximal d'autorisations que vous pouvez créer, consultez [Quotas applicables aux entités](DNSLimitations.md#limits-api-entities).

# Dissociation VPCs d'une zone hébergée privée
<a name="hosted-zone-private-disassociate-vpcs"></a>

Vous pouvez utiliser la console Amazon Route 53 pour vous VPCs dissocier d'une zone hébergée privée. Ce faisant, Route 53 cesse d'acheminer le trafic à l'aide de registres dans la zone hébergée pour les requêtes DNS qui proviennent du VPC. Par exemple, si la zone hébergée example.com est associée à un VPC et que vous dissociez la zone hébergée de ce VPC, Route 53 cesse de résoudre les requêtes DNS pour example.com ou tout autre registre de la zone hébergée example.com. 

**Note**  
Vous ne pouvez pas dissocier le dernier VPC d'une zone hébergée privée. Si vous souhaitez dissocier ce VPC, vous devez d'abord associer un autre VPC à la zone hébergée.

**Pour se dissocier VPCs d'une zone hébergée privée**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Cliquez sur le bouton radio correspondant à la zone hébergée privée dont vous souhaitez dissocier une ou plusieurs VPCs zones.

1. Choisissez **Modifier**.

1. Choisissez **Remove VPC** (Supprimer le VPC) en regard du VPC que vous souhaitez dissocier de cette zone hébergée.

1. Sélectionnez **Enregistrer les modifications**.

# Suppression d'une zone hébergée privée
<a name="hosted-zone-private-deleting"></a>

Cette section explique comment supprimer une zone hébergée privée à l'aide de la console Amazon Route 53.

Vous pouvez supprimer une zone hébergée privée uniquement s'il n'existe aucun autre enregistrement que les enregistrements SOA et NS par défaut. Si votre zone hébergée contient d'autres enregistrements, vous devez les supprimer avant de pouvoir supprimer votre zone hébergée. Cela vous empêche de supprimer accidentellement une zone hébergée qui contient encore des enregistrements.

**Topics**
+ [Suppression des zones hébergées privées qui étaient créées par un autre service](#delete-private-hosted-zone-created-by-another-service)
+ [Utilisation de la console Route 53 pour supprimer une zone hébergée privée](#delete-private-hosted-zone-procedure)

## Suppression des zones hébergées privées qui étaient créées par un autre service
<a name="delete-private-hosted-zone-created-by-another-service"></a>

Si une zone hébergée privée a été créée par un autre service, vous ne pouvez pas la supprimer à l'aide de la console Route 53. Au lieu de cela, vous devez utiliser le processus de l'autre service :
+ **AWS Cloud Map**— Pour supprimer une zone hébergée AWS Cloud Map créée lorsque vous avez créé un espace de noms DNS privé, supprimez l'espace de noms. AWS Cloud Map supprime automatiquement la zone hébergée. Pour plus d'informations, consultez [Suppression des espaces de noms](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) dans le *Guide du développeur AWS Cloud Map *.
+ **Découverte du service Amazon Elastic Container Service (Amazon ECS)** – Pour supprimer une zone hébergée privée créée par Amazon ECS lorsque vous avez créé un service à l'aide de la découverte de service, supprimez les services Amazon ECS qui utilisent l'espace de noms, et supprimez l'espace de noms. Pour plus d'informations, consultez [Suppression d'un service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) dans le *Guide du développeur Amazon Elastic Container Service*.

## Utilisation de la console Route 53 pour supprimer une zone hébergée privée
<a name="delete-private-hosted-zone-procedure"></a>

Pour utiliser la console Route 53 afin de supprimer une zone hébergée privée, exécutez la procédure suivante.

**Pour supprimer une zone hébergée privée à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Vérifiez que la zone hébergée que vous souhaitez supprimer contient uniquement un enregistrement NS et un enregistrement SOA. Si elle contient d'autres enregistrements, supprimez-les :

   1. Choisissez le nom de la zone hébergée que vous souhaitez supprimer.

   1. Sur la page **Record** (Registre), si la liste des registres inclut des registres pour lesquels la valeur de la colonne **Type** n'est ni **NS** ni **SOA**, choisissez la ligne et choisissez **Delete** (Supprimer).

      Pour sélectionner plusieurs enregistrements consécutifs, appuyez sur la touche **MAJ** et maintenez-la enfoncée, puis sélectionnez la dernière ligne. Pour sélectionner plusieurs enregistrements non consécutifs, appuyez sur la touche **Ctrl** et maintenez-la enfoncée, puis sélectionnez les autres lignes. 

1. Sur la page Hosted Zones, choisissez la ligne de la zone hébergée que vous souhaitez supprimer.

1. Sélectionnez **Delete (Supprimer)**.

1. Saisissez la clé de confirmation et choisissez **Delete** (Supprimer).

# Autorisations VPC
<a name="hosted-zone-private-vpc-permissions"></a>

[Les autorisations VPC utilisent les conditions de politique de gestion des identités et des accès (IAM) qui vous permettent de définir des autorisations granulaires VPCs lorsque vous utilisez [Associer VPCWithHostedZone, [Disassocier](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html), [Créer une VPCAssociation autorisation VPCFrom HostedZone [VPCAssociation, Supprimer](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html) une autorisation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) et VPC. [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)ListHostedZonesBy](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) APIs

Avec la condition de politique IAM`route53:VPCs`, vous pouvez accorder des droits administratifs granulaires à d'autres AWS utilisateurs. Cela vous permet d'accorder à quelqu'un l'autorisation d'associer une zone hébergée à, de dissocier une zone hébergée, de créer une autorisation d'association VPC pour, de supprimer l'autorisation d'association VPC pour, de créer une zone hébergée avec ou de répertorier des zones hébergées pour :
+ Un seul VPC.
+ N'importe VPCs lequel au sein de la même région.
+ Multiple VPCs.

Pour plus d'informations sur les autorisations VPC, consultez. [Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions-route53.md)

Pour savoir comment authentifier AWS les utilisateurs, consultez [Authentification par des identités](security-iam.md#security_iam_authentication) et pour savoir comment contrôler l'accès aux ressources Route 53, voir[Contrôle d’accès](security-iam.md#access-control).

# Migration d'une zone hébergée vers un autre compte AWS
<a name="hosted-zones-migrating"></a>

Lorsque vous migrez une zone hébergée vers une autre Compte AWS, suivez ces étapes recommandées.

Ces étapes sont particulièrement adaptées aux zones hébergées dont les enregistrements sont peu modifiés. Pour les zones hébergées avec des mises à jour fréquentes des enregistrements, tenez compte des points suivants : 
+ Ne mettez à jour aucun enregistrement de ressource pendant la migration.
+ Publiez les modifications des enregistrements de ressources dans les anciennes et les nouvelles zones hébergées après le transfert de la délégation.

**Conditions préalables**  
Installez ou mettez à niveau AWS CLI :

Pour plus d'informations sur le téléchargement, l'installation et la configuration du AWS CLI, consultez le [guide de AWS Command Line Interface l'utilisateur](https://docs.aws.amazon.com/cli/latest/userguide/).

**Note**  
Configurez l'interface de ligne de commande afin de pouvoir l'utiliser lorsque vous utilisez à la fois le compte qui a créé la zone hébergée et le compte vers lequel vous migrez la zone hébergée. Pour plus d'informations, consultez [Configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) (Configuration) dans le *Guide de l'utilisateur AWS Command Line Interface *.

Si vous utilisez déjà le AWS CLI, nous vous recommandons de passer à la dernière version de la CLI afin que les commandes de la CLI prennent en charge les dernières fonctionnalités de Route 53.

**Topics**
+ [Étape 1 : Préparation à la migration](#hosted-zones-migrating-prepare)
+ [Étape 2 : Créer la nouvelle zone hébergée](#hosted-zones-migrating-create-hosted-zone)
+ [Étape 3 : (Facultatif) Migrer les bilans de santé](#hosted-zones-migrating-health-checks)
+ [Étape 4 : Migrer les enregistrements de l'ancienne zone hébergée vers la nouvelle zone hébergée](#hosted-zones-migrating-old-to-new)
+ [Étape 5 : Comparez les enregistrements de l'ancienne et de la nouvelle zone hébergée](#hosted-zones-migrating-compare)
+ [Étape 6 : Mettre à jour l'enregistrement du domaine pour utiliser des serveurs de noms pour la nouvelle zone hébergée](#hosted-zones-migrating-update-domain)
+ [Étape 7 : Remettez le TTL de l'enregistrement NS à une valeur plus élevée](#hosted-zones-migrating-change-ttl)
+ [Étape 8 : réactivez la signature DNSSEC et établissez la chaîne de confiance (si nécessaire)](#hosted-zones-migrating-enable-dnssec)
+ [Étape 9 : (Facultatif) supprimer l'ancienne zone hébergée](#hosted-zones-migrating-delete-old-hosted-zone)

## Étape 1 : Préparation à la migration
<a name="hosted-zones-migrating-prepare"></a>

Les étapes de préparation vous aident à minimiser les risques associés à la migration d'une zone hébergée.

**1. Surveillez la disponibilité des zones**  
Vous pouvez contrôler la zone de disponibilité des noms de domaine. Cela peut vous aider à résoudre les problèmes susceptibles d'entraîner l'annulation de la migration. Vous pouvez surveiller les noms de domaine qui génèrent le plus de trafic en utilisant CloudWatch ou en enregistrant les requêtes. Pour plus d'informations sur la configuration de la journalisation des requêtes, consultez [Surveillance d'Amazon Route 53](monitoring-overview.md).

Vous pouvez effectuer la surveillance via un script shell ou via un service tiers. Cela ne devrait toutefois pas être le seul signal permettant de déterminer si une annulation est nécessaire, car vous pourriez également obtenir des commentaires de la part de vos clients si un domaine n'est pas disponible.

**2. Réduisez le paramètre TTL**  
Le paramètre de durée de vie d'un enregistrement spécifie la durée pendant laquelle vous voulez que les résolveurs DNS mettent en cache l'enregistrement et utilisent les informations mises en cache. À la date d'expiration, un résolveur envoie une autre requête au fournisseur de services DNS d'un domaine afin d'obtenir les informations les plus récentes.

Le paramètre de durée de vie d'un enregistrement NS est de 172 800 secondes, soit deux jours. L'enregistrement NS répertorie les serveurs de noms que le système de noms de domaine (DNS) peut utiliser pour obtenir des informations sur la manière d'acheminer le trafic pour votre domaine. La réduction du TTL pour l'enregistrement NS, à la fois avec votre fournisseur de services DNS actuel et avec Route 53, réduit le temps d'arrêt de votre domaine si vous découvrez un problème lors de la migration du DNS vers Route 53. Si vous ne réduisez pas la durée de vie, votre domaine risque d'être indisponible sur Internet pendant deux jours en cas de problème.

**Pour abaisser le TTL**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Choisissez **Zones hébergées** dans le volet de navigation.

1. Choisissez le nom de la zone hébergée.

1. Choisissez l'enregistrement NS, puis dans le volet **Détails de l'enregistrement**, sélectionnez **Modifier l'enregistrement**.

1. Modifiez la valeur du champ **TTL (Seconds) (Durée de vie (secondes))**. Nous vous recommandons de spécifier une valeur comprise entre 60 secondes et 900 secondes (15 minutes).

1. Choisissez **Enregistrer**.

**3. Supprimer l'enregistrement DS de la zone parent (si le protocole DNSSEC est configuré)**  
Si vous avez configuré DNSSEC pour votre domaine, supprimez le registre Delegation Signer (DS) de la zone parent avant de migrer votre domaine vers Route 53.

Si la zone parent est hébergée via Route 53, consultez [Suppression de clés publiques pour un domaine](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) pour plus d'informations. Si la zone parent est hébergée sur un autre bureau d'enregistrement, contactez-le pour supprimer l'enregistrement DS.

Route 53 ne prend actuellement pas en charge la migration du paramètre DNSSEC. Vous devez donc désactiver la validation DNSSEC effectuée sur votre domaine avant la migration en supprimant l'enregistrement DS de la zone parent. Après la migration, vous pouvez réactiver la validation DNSSEC en configurant le DNSSEC sur la nouvelle zone hébergée et en ajoutant l'enregistrement DS correspondant à la zone parent.

**4. Assurez-vous qu'aucune autre opération n'est en cours basée sur la zone hébergée en cours de migration**  
Certaines opérations s'appuieront sur la résolution DNS dans la zone hébergée en cours de migration. Par exemple, le processus de renouvellement du TLS/SSL certificat peut nécessiter des modifications d'enregistrement DNS et le fournisseur essaiera de résoudre l'enregistrement DNS comme méthode de validation. Avant la migration, vous devez vous assurer qu'aucune autre opération n'est en cours, afin d'éviter tout impact inattendu lié à la migration de la zone hébergée.

## Étape 2 : Créer la nouvelle zone hébergée
<a name="hosted-zones-migrating-create-hosted-zone"></a>

Créez la nouvelle zone hébergée dans le compte vers lequel vous souhaitez migrer la zone hébergée.

Choisissez l'onglet pour les instructions relatives à la console AWS CLI ou à la console.
+ [INTERFACE DE LIGNE DE COMMANDE (CLI)](#migrate-hz-cli)
+ [Console](#migrate-hz-console)

------
#### [ CLI ]

Entrez la commande suivante :

```
aws route53 create-hosted-zone \ 
            --name $hosted_zone_name \ 
            --caller-reference $unique_string
```

Pour de plus amples informations, veuillez consulter [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html).

------
#### [ Console ]<a name="hosted-zones-migrating-create-hosted-zone-procedure"></a>

**Pour créer une nouvelle zone hébergée à l'aide d'un autre compte**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

   Connectez-vous avec les informations d'identification du compte vers lequel vous souhaitez migrer la zone hébergée.

1. Créez une zone hébergée. Pour de plus amples informations, veuillez consulter [Création d'une zone hébergée publique](CreatingHostedZone.md).

1. Notez l'ID de la zone hébergée. Dans certains cas, vous en aurez besoin ultérieurement dans le processus.

1. Déconnectez-vous de la console Route 53.

Réduisez également le TTL NS dans la nouvelle zone, comme dans le cas du paramètre TTL inférieur lors de la préparation, étape 1, abaissez le paramètre TTL.

------

## Étape 3 : (Facultatif) Migrer les bilans de santé
<a name="hosted-zones-migrating-health-checks"></a>

Vous pouvez associer les enregistrements DNS du nouveau compte aux contrôles de santé de Route 53 effectués à partir du compte à partir duquel vous effectuez la migration. Pour migrer un bilan de santé Route 53, vous devez créer de nouveaux bilans de santé dans votre nouveau compte avec la même configuration que les bilans existants. Pour de plus amples informations, veuillez consulter [Création de bilans de santé pour Amazon Route 53](dns-failover.md).

## Étape 4 : Migrer les enregistrements de l'ancienne zone hébergée vers la nouvelle zone hébergée
<a name="hosted-zones-migrating-old-to-new"></a>

Vous pouvez migrer des enregistrements d'un document Compte AWS à un autre à l'aide de la console ou du AWS CLI.

------
#### [ Console ]

Si votre zone ne contient que quelques enregistrements, vous pouvez envisager d'utiliser la console Route 53 pour répertorier les enregistrements de votre ancienne zone, les noter et les créer dans la nouvelle zone. Si vous avez migré le bilan de santé[Étape 3 : (Facultatif) Migrer les bilans de santé](#hosted-zones-migrating-health-checks), lorsque vous créez les enregistrements dans la nouvelle zone hébergée, vous devez spécifier le nouvel identifiant du bilan de santé. Pour plus d’informations, consultez les rubriques suivantes :
+ [Liste des enregistrements](resource-record-sets-listing.md)
+ [Création d'enregistrements à l'aide de la console Amazon Route 53](resource-record-sets-creating.md)
+ [Configuration du basculement DNS](dns-failover-configuring.md)

Vous devez également baisser le TTL NS dans la nouvelle zone, de la même manière que le paramètre Lower TTL défini à l'étape 1.

------
#### [ CLI ]

Si votre zone contient un grand nombre d'enregistrements, vous pouvez exporter les enregistrements que vous souhaitez migrer vers un fichier, modifier le fichier, puis utiliser le fichier modifié pour créer des enregistrements dans la nouvelle zone hébergée. La procédure suivante utilise des commandes AWS CLI, bien que des outils tiers soient également disponibles à cette fin.<a name="hosted-zones-migrating-create-file-procedure"></a>

****

1. Exécutez la commande suivante : 

   ```
   aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
   ```

   Notez ce qui suit :
   + Pour*hosted-zone-id*, spécifiez l'ID de l'ancienne zone hébergée contenant les enregistrements que vous souhaitez migrer. 
   + Pour*path-to-output-file*, spécifiez le chemin du répertoire et le nom de fichier dans lesquels vous souhaitez enregistrer la sortie. 
   + Le caractère `>` envoie la sortie dans le fichier spécifié.
   + Gère AWS CLI automatiquement la pagination pour les zones hébergées contenant plus de 100 enregistrements. Pour plus d'informations, consultez la section [Utilisation des options de pagination de l'interface de ligne de AWS commande](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html) dans le *Guide de l'AWS Command Line Interface utilisateur*. 

     Si vous utilisez une autre méthode programmatique pour répertorier les enregistrements, comme l'un des AWS SDKs, vous pouvez obtenir un maximum de 100 enregistrements par page de résultats. Si la zone hébergée contient plus de 100 enregistrements, vous devez soumettre plusieurs demandes pour répertorier tous les enregistrements.

   Faites une copie de cette sortie. Après avoir créé des enregistrements dans la nouvelle zone hébergée, nous vous recommandons d'exécuter la AWS CLI `list-resource-record-sets` commande sur la nouvelle zone hébergée et de comparer les deux sorties pour vous assurer que tous les enregistrements ont été créés.

1. Modifiez les enregistrements que vous souhaitez migrer.

   Modifiez le fichier exporté avant de pouvoir l'utiliser avec la `change-resource-record-sets` commande. Vous pouvez effectuer ces modifications à l'aide de la fonction de recherche et de remplacement d'un éditeur de texte. 
**Note**  
Les étapes suivantes décrivent l'édition manuelle à l'aide d'un éditeur de texte. Les utilisateurs expérimentés peuvent automatiser ces transformations à l'aide d'outils de programmation tels que jq, Python ou d'autres langages de script.

   Ouvrez une copie du fichier que vous avez créé à l'étape 1 de cette procédure qui contient les enregistrements que vous souhaitez migrer, et apportez les modifications suivantes :
   + Remplacez l' ResourceRecordSets élément en haut du fichier par un `Changes` élément.
   + Facultatif : ajoutez un `Comment` élément.
   + Supprimez les lignes relatives aux enregistrements NS et SOA du nom de la zone hébergée. La nouvelle zone hébergée possède déjà ces enregistrements.
   + Pour chaque enregistrement, ajoutez un élément `Action` et un `ResourceRecordSets` élément, ajoutez des crochets ouvrants et fermants (`{ }`) selon les besoins pour que le code JSON soit valide.
**Note**  
Vous pouvez utiliser un validateur JSON pour vérifier que toutes les accolades et tous les crochets sont correctement placés. Pour trouver un validateur JSON en ligne, recherchez « validateur JSON » dans votre navigateur.
   + Si la zone hébergée contient tous les alias qui font référence à d'autres enregistrements dans la même zone hébergée, apportez les modifications suivantes :
     + Remplacez l'ID de la zone hébergée par l'ID de la nouvelle zone hébergée.
**Important**  
Si l'enregistrement d'alias pointe vers une autre ressource, par exemple un équilibreur de charge, ne remplacez pas l'ID de zone hébergée par l'ID de zone hébergée du domaine. Si vous modifiez accidentellement l'ID de zone hébergée, rétablissez l'ID de zone hébergée en identifiant de zone hébergée de la ressource elle-même, et non en identifiant de zone hébergée du domaine. L'ID de zone hébergée par la ressource se trouve dans la AWS console où la ressource a été créée.
     + Déplacez les registres d'alias au bas du fichier. Route 53 doit créer le registre auquel un registre d'alias fait référence avant de pouvoir créer le registre d'alias.
**Important**  
Si un ou plusieurs enregistrements d'alias font référence à d'autres enregistrements d'alias, les enregistrements qui sont la cible de l'alias doivent apparaître dans le fichier avant les enregistrements d'alias qui font référence. Par exemple, si `alias.example.com` est la cible de l'alias pour `alias.alias.example.com`, `alias.example.com` doit apparaître en premier dans le fichier.
     + Supprimez les enregistrements d'alias qui acheminent le trafic vers une instance de stratégie de trafic. Notez les enregistrements afin de pouvoir les recréer ultérieurement.
   + Si vous avez migré les bilans de santé[Étape 3 : (Facultatif) Migrer les bilans de santé](#hosted-zones-migrating-health-checks), modifiez les enregistrements pour les associer au nouveau bilan de santé. IDs

   L'exemple suivant montre la version modifiée d'enregistrements pour une zone hébergée pour example.com. Le texte en rouge et en italique est nouveau :

   ```
   {
       "Comment": "string",
       "Changes": [
           {
               "Action": "CREATE",
               "ResourceRecordSet":{
                   "ResourceRecords": [
                       {
                           "Value": "192.0.2.4"
                       }, 
                       {
                           "Value": "192.0.2.5"
                       }, 
                       {
                           "Value": "192.0.2.6"
                       }
                   ], 
                   "Type": "A", 
                   "Name": "route53documentation.com.", 
                   "TTL": 300
               }
           },
           {
               "Action": "CREATE",
               "ResourceRecordSet":{
                   "AliasTarget": {
                       "HostedZoneId": "Z3BJ6K6RIION7M",
                       "EvaluateTargetHealth": false,
                       "DNSName": "s3-website-us-west-2.amazonaws.com."
                   },
                   "Type": "A",
                   "Name": "www.route53documentation.com."
               }
           }
       ]
   }
   ```

1. Divisez les gros fichiers en fichiers plus petits

   Si vous avez un grand nombre d'enregistrements ou si vous avez des enregistrements comportant de nombreuses valeurs (par exemple, un grand nombre d'adresses IP), vous pouvez avoir besoin de fractionner le fichier en fichiers plus petits. Les valeurs maximales sont les suivantes :
   + Chaque fichier peut contenir 1 000 enregistrements maximum.
   + La longueur combinée maximale des valeurs de tous les éléments `Value` est de 32 000 octets.

1. Créez des enregistrements dans la nouvelle zone hébergée

   Entrez la CLI suivante :

   ```
   aws route53 change-resource-record-sets \
               --hosted-zone-id new-hosted-zone-id \
               --change-batch file://path-to-file-that-contains-records
   ```

   Indiquez l’une des valeurs suivantes :
   + Pour`new-hosted-zone-id`, spécifiez l'ID de la nouvelle zone hébergée.
   + Pour`path-to-file-that-contains-records`, spécifiez le chemin du répertoire et le nom de fichier que vous avez modifiés au cours des étapes précédentes.

   Si vous avez supprimé des registres d'alias qui acheminent le trafic vers une instance de politique de trafic, recréez-les à l'aide de la console Route 53. Pour de plus amples informations, veuillez consulter [Création d'enregistrements à l'aide de la console Amazon Route 53](resource-record-sets-creating.md).

------

## Étape 5 : Comparez les enregistrements de l'ancienne et de la nouvelle zone hébergée
<a name="hosted-zones-migrating-compare"></a>

Pour confirmer que vous avez bien créé tous vos enregistrements dans la nouvelle zone hébergée, entrez la commande CLI suivante pour répertorier les enregistrements de la nouvelle zone hébergée et comparez le résultat avec la liste des enregistrements de l'ancienne zone hébergée. 

```
aws route53 list-resource-record-sets \
            --hosted-zone-id new-hosted-zone-id \
            --output json > path-to-output-file
```

Indiquez l’une des valeurs suivantes :
+ Pour`new-hosted-zone-id`, spécifiez l'ID de la nouvelle zone hébergée.
+ Pour`path-to-output-file`, spécifiez le chemin du répertoire et le nom de fichier dans lesquels vous souhaitez enregistrer la sortie. Utilisez un nom de fichier différent de celui que vous avez utilisé à l'étape 4.

  Le caractère `>` envoie la sortie dans le fichier spécifié.

Comparez le résultat avec le résultat de l'étape 4. Hormis les valeurs des enregistrements NS et SOA et les modifications que vous avez apportées à l'étape 4 (telles que des zones hébergées IDs ou des noms de domaine différents), les deux sorties doivent être identiques.

Si les enregistrements de la nouvelle zone hébergée ne correspondent pas à ceux de l'ancienne zone hébergée, effectuez l'une des opérations suivantes :
+ Apportez des corrections mineures à l'aide de la console Route 53. Pour de plus amples informations, veuillez consulter [Modification des enregistrements](resource-record-sets-editing.md).
+ Supprimez tous les enregistrements sauf les enregistrements NS et SOA de la nouvelle zone hébergée et répétez la procédure de l'étape 4.

## Étape 6 : Mettre à jour l'enregistrement du domaine pour utiliser des serveurs de noms pour la nouvelle zone hébergée
<a name="hosted-zones-migrating-update-domain"></a>

Lorsque vous avez terminé de migrer les enregistrements vers la nouvelle zone hébergée, modifiez les serveurs de noms pour l'enregistrement du domaine afin qu'ils utilisent les serveurs de noms de la nouvelle zone hébergée. Pour plus d'informations, consultez Faire d'Amazon Route 53 le service DNS d'un domaine existant.

Si votre zone hébergée est utilisée, par exemple, si vos utilisateurs utilisent le nom de domaine pour accéder à un site Web ou à une application Web, vous devez continuer à surveiller le trafic et la disponibilité de la zone hébergée, y compris le trafic du site Web ou des applications, le courrier électronique, etc. 
+ **Si le trafic ralentit ou s'arrête**, remplacez le service de noms pour l'enregistrement du domaine par les anciens serveurs de noms de l'ancienne zone hébergée. Déterminez ce qui s'est mal passé.
+ **Si le trafic n'est pas affecté**, passez à l'étape suivante.

## Étape 7 : Remettez le TTL de l'enregistrement NS à une valeur plus élevée
<a name="hosted-zones-migrating-change-ttl"></a>

Dans la nouvelle zone hébergée, remplacez le TTL de l'enregistrement NS par une valeur plus classique, par exemple 172 800 secondes (deux jours). Cette étape permet d'améliorer la latence pour vos utilisateurs car ils n'auront plus besoin d'attendre aussi souvent que les résolveurs DNS envoient une requête pour les serveurs de noms de votre domaine.<a name="change-ttl-back-procedure"></a>

**Pour modifier le TTL**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Choisissez **Zones hébergées** dans le volet de navigation.

1. Choisissez le nom de la zone hébergée.

1. Choisissez l'enregistrement NS, puis dans le volet **Détails de l'enregistrement**, sélectionnez **Modifier l'enregistrement**.

1. Modifiez la valeur du **TTL (secondes)** par le nombre de secondes pendant lesquelles vous souhaitez que les résolveurs DNS mettent en cache les noms des serveurs de noms de votre domaine. Nous vous recommandons une valeur de 172 800 secondes. 

1. Choisissez **Enregistrer**.

## Étape 8 : réactivez la signature DNSSEC et établissez la chaîne de confiance (si nécessaire)
<a name="hosted-zones-migrating-enable-dnssec"></a>

Vous pouvez réactiver la signature DNSSEC en deux étapes : 

1.  Activez la signature DNSSEC pour Route 53 et demandez à Route 53 de créer une clé de signature (KSK) basée sur une clé d'entrée gérée par le client. AWS Key Management Service

1. Créez une chaîne de confiance pour la zone hébergée en ajoutant un enregistrement de signature de délégation (DS) à la zone parent, afin que les réponses DNS puissent être authentifiées à l'aide de signatures cryptographiques fiables.

Pour obtenir des instructions, veuillez consulter [Activation de la signature DNSSEC et établissement d'une chaîne d'approbation](dns-configuring-dnssec-enable-signing.md).

## Étape 9 : (Facultatif) supprimer l'ancienne zone hébergée
<a name="hosted-zones-migrating-delete-old-hosted-zone"></a>

Lorsque vous êtes sûr de ne plus avoir besoin de l'ancienne zone hébergée, vous pouvez éventuellement la supprimer. Pour obtenir des instructions, veuillez consulter [Suppression d'une zone hébergée publique](DeleteHostedZone.md).

**Important**  
Ne supprimez pas l'ancienne zone hébergée ou tous les enregistrements de cette zone hébergée pendant au moins 48 heures après avoir mis à jour l'enregistrement de domaine pour utiliser les serveurs de noms de la nouvelle zone hébergée. Si vous supprimez l'ancienne zone hébergée avant que les résolveurs DNS ne cessent d'utiliser les enregistrements dans cette zone hébergée, votre domaine peut être indisponible sur Internet jusqu'à ce que les résolveurs commencent à utiliser la nouvelle zone hébergée.

# Utilisation des enregistrements
<a name="rrsets-working-with"></a>

Une fois que vous avez créé une zone hébergée pour votre domaine, par exemple, example.com, vous créez des enregistrements pour indiquer au système de noms de domaine (DNS) la façon dont le trafic doit être acheminé pour ce domaine.

Par exemple, vous pouvez créer des enregistrements entraînant le comportement DNS suivant :
+ Achemine le trafic Internet d'example.com vers l'adresse IP d'un hôte de votre centre de données.
+ Achemine l'e-mail de ce domaine (ichiro@example.com) vers un serveur de messagerie (mail.example.com).
+ Achemine le trafic d'un sous-domaine appelé operations.tokyo.example.com vers l'adresse IP d'un autre hôte. 

Chaque enregistrement inclut le nom d'un domaine ou d'un sous-domaine, un type d'enregistrement (par exemple, un enregistrement avec un type d'e-mail de routage MX) et d'autres informations applicables au type de l'enregistrement (pour les enregistrements MX, le nom d'hôte d'un ou de plusieurs serveurs de messagerie et une priorité pour chaque serveur). Pour plus d'informations sur les différents types d'enregistrement, consultez [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Le nom de chaque enregistrement dans une zone hébergée doit se terminer par le nom de la zone hébergée. Par exemple, la zone hébergée example.com peut contenir des enregistrements pour les sous-domaines www.example.com et accounting.tokyo.example.com, mais ne peut pas contenir d'enregistrements pour un sous-domaine www.example.ca. 

**Note**  
Pour créer des enregistrements pour des configurations de routage complexes, vous pouvez également utiliser l'éditeur visuel Traffic Flow et enregistrer la configuration en tant que politique de trafic. Vous pouvez ensuite associer la stratégie de trafic à un ou plusieurs noms de domaine (par exemple, example.com) ou noms de sous-domaine (par exemple, www.example.com), dans la même zone hébergée ou dans plusieurs zones hébergées. En outre, vous pouvez restaurer les mises à jour si la nouvelle configuration ne fonctionne pas comme vous l'aviez prévu. Pour de plus amples informations, veuillez consulter [Utiliser Traffic Flow pour acheminer le trafic DNS](traffic-flow.md).

Amazon Route 53 ne facture pas les enregistrements que vous ajoutez à une zone hébergée. Pour plus d'informations sur le nombre maximum d'enregistrements que vous pouvez créer dans une zone hébergée, consultez [Quotas](DNSLimitations.md). 

**Topics**
+ [Sélection d'une stratégie de routage](routing-policy.md)
+ [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md)
+ [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md)
+ [Création d'enregistrements à l'aide de la console Amazon Route 53](resource-record-sets-creating.md)
+ [Autorisations relatives aux ensembles d'enregistrements](resource-record-sets-permissions.md)
+ [Valeurs à spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53](resource-record-sets-values.md)
+ [Création d'enregistrements par importation d'un fichier de zone](resource-record-sets-creating-import.md)
+ [Modification des enregistrements](resource-record-sets-editing.md)
+ [Suppression d'enregistrements](resource-record-sets-deleting.md)
+ [Liste des enregistrements](resource-record-sets-listing.md)

# Sélection d'une stratégie de routage
<a name="routing-policy"></a>

Lorsque vous créez un enregistrement, vous choisissez une stratégie de routage, qui détermine la façon dont Amazon Route 53 répond aux requêtes : 
+ **Simple routing policy (Stratégie de routage simple)** : utilisez une stratégie de routage simple quand vous disposez d'une seule ressource qui exécute une fonction donnée pour votre domaine, comme, par exemple, un serveur web qui diffuse le contenu du site web example.com. Vous pouvez utiliser le routage simple pour créer des enregistrements dans une zone hébergée privée.
+ **Failover routing policy (Stratégie de routage par basculement)** : utilisez une stratégie de routage par basculement pour configurer le basculement actif-passif. Vous pouvez utiliser le routage par basculement pour créer des enregistrements dans une zone hébergée privée.
+ **Stratégie de routage de géolocalisation** : utilisez la stratégie de routage de géolocalisation lorsque vous souhaitez acheminer le trafic en fonction de l'emplacement de vos utilisateurs. Vous pouvez utiliser le routage de géolocalisation pour créer des enregistrements dans une zone hébergée privée.
+ **Stratégie de routage par proximité géographique** : utilisez cette stratégie lorsque vous souhaitez acheminer du trafic en fonction de l'emplacement de vos ressources et, éventuellement, détourner le trafic de vos ressources à un emplacement donné vers les ressources d'un autre emplacement. Vous pouvez utiliser le routage de géoproximité pour créer des enregistrements dans une zone hébergée privée.
+ **Politique de routage par latence** : à utiliser lorsque vous disposez de plusieurs ressources Régions AWS et que vous souhaitez acheminer le trafic vers la région offrant la meilleure latence. Vous pouvez utiliser le routage avec latence pour créer des enregistrements dans une zone hébergée privée.
+ **IP-based routing policy** (Politique de routage basée sur IP) – utilisez la politique de routage basée sur IP lorsque vous voulez acheminer le trafic en fonction de l'emplacement de vos utilisateurs, et que vous disposez des adresses IP d'où provient le trafic.
+ **Multivalue answer routing policy (Stratégie de routage de réponse multivaleur)** : utilisez la stratégie de routage de réponse multivaleur lorsque vous souhaitez que Route 53 réponde aux requêtes DNS avec jusqu'à huit enregistrements sains sélectionnés de manière aléatoire. Vous pouvez utiliser le routage de réponses à plusieurs valeurs pour créer des enregistrements dans une zone hébergée privée.
+ **Weighted routing policy (Stratégie de routage pondéré)** : utilisez la stratégie de routage pondéré pour acheminer le trafic vers plusieurs ressources selon les proportions que vous spécifiez. Vous pouvez utiliser le routage pondéré pour créer des enregistrements dans une zone hébergée privée.

**Topics**
+ [Routage simple](routing-policy-simple.md)
+ [Routage par basculement](routing-policy-failover.md)
+ [Routage de géolocalisation](routing-policy-geo.md)
+ [Routage par géoproximité](routing-policy-geoproximity.md)
+ [Routage basé sur la latence](routing-policy-latency.md)
+ [Routage basé sur IP](routing-policy-ipbased.md)
+ [Multivalue answer routing (Routage de réponse multivaleur)](routing-policy-multivalue.md)
+ [Weighted routing (Routage pondéré)](routing-policy-weighted.md)
+ [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md)

# Routage simple
<a name="routing-policy-simple"></a>

Le routage simple vous permet de configurer des enregistrements DNS standard sans routage Route 53 spécial, comme un routage pondéré ou de latence. Avec le routage simple, vous acheminez généralement le trafic vers une seule ressource, par exemple, un serveur web pour votre site web. 

Vous pouvez utiliser la stratégie de routage simple pour créer des enregistrements dans une zone hébergée privée.

Si vous choisissez la stratégie de routage simple dans la console Route 53, vous ne pouvez pas créer plusieurs enregistrements ayant le même nom et le même type, mais vous pouvez spécifier plusieurs valeurs dans le même enregistrement, par exemple plusieurs adresses IP. (Si vous choisissez la politique de routage simple pour un enregistrement d'alias, vous ne pouvez spécifier qu'une seule AWS ressource ou un seul enregistrement dans la zone hébergée actuelle.) Si vous spécifiez plusieurs valeurs dans un enregistrement, Route 53 renvoie toutes les valeurs au résolveur récursif dans un ordre aléatoire, puis le résolveur renvoie les valeurs au client (comme un navigateur web) qui a envoyé la requête DNS. Le client sélectionne ensuite une valeur et renvoie la requête. Avec une politique de routage simple, même si vous pouvez spécifier plusieurs adresses IP, aucune surveillance de l'état n'a lieu pour ces adresses IP.

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage simple pour créer des enregistrements, consultez les rubriques suivantes :
+ [Valeurs spécifiques aux enregistrements simples](resource-record-sets-values-basic.md)
+ [Valeurs spécifiques aux enregistrements d'alias simples](resource-record-sets-values-alias.md)
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

# Routage par basculement
<a name="routing-policy-failover"></a>

Le routage par basculement vous permet d'acheminer le trafic vers une ressource lorsqu'elle est saine ou vers une autre ressource si la première ressource n'est pas saine. L'enregistrement principal et l'enregistrement secondaire peuvent acheminer le trafic de différents types d'éléments, d'un compartiment Amazon S3 configuré comme site web à une arborescence complexe d'enregistrements. Pour de plus amples informations, veuillez consulter [Basculement actif-passif](dns-failover-types.md#dns-failover-types-active-passive).

Vous pouvez utiliser la stratégie de routage de basculement pour créer des enregistrements dans une zone hébergée privée.

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage de basculement pour créer des enregistrements, consultez les rubriques suivantes :
+ [Valeurs spécifiques aux enregistrements de basculement](resource-record-sets-values-failover.md)
+ [Valeurs spécifiques aux enregistrements d'alias de basculement](resource-record-sets-values-failover-alias.md)
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

# Routage de géolocalisation
<a name="routing-policy-geo"></a>

Le routage de géolocalisation vous permet de choisir les ressources qui servent le trafic en fonction de la localisation géographique de vos utilisateurs, c'est-à-dire de l'emplacement d'où proviennent les requêtes DNS. Par exemple, vous souhaitez peut-être que toutes les requêtes d'Europe soient acheminées vers l'équilibreur de charge Elastic Load Balancing dans la région de Francfort. 

Quand vous utilisez le routage de géolocalisation, vous pouvez localiser votre contenu et présenter tout ou partie de votre site web dans la langue de vos utilisateurs. Vous pouvez aussi utiliser le routage de géolocalisation pour limiter la distribution de contenu aux seuls emplacements dans lesquels vous avez des droits de distribution. Une autre utilisation possible consiste à équilibrer la charge entre les points de terminaison de easy-to-manage manière prévisible, afin que chaque emplacement utilisateur soit systématiquement acheminé vers le même point de terminaison. 

Vous pouvez spécifier des emplacements géographiques par continent, par pays ou par état des États-Unis. Si vous créez des enregistrements distincts pour des régions géographiques qui se chevauchent (par exemple, un pour l'Amérique du Nord et un autre pour le Canada), la région géographique la plus petite est prioritaire. Cela vous permet d'acheminer des requêtes concernant un continent vers une ressource et celles concernant des pays sélectionnés sur ce continent vers une autre ressource. (Pour obtenir la liste des pays de chaque continent, consultez [Location](resource-record-sets-values-geo.md#rrsets-values-geo-location).)

La géolocalisation se base sur le mappage d'adresses IP à des emplacements. Cependant, certaines adresses IP ne sont pas mappées à des emplacements géographiques. Ainsi, même si vous créez des enregistrements de géolocalisation couvrant les sept continents, Amazon Route 53 recevra des requêtes DNS à partir d'emplacements qu'il n'est pas en mesure d'identifier. Vous pouvez créer un enregistrement par défaut pour gérer les requêtes provenant d'adresses IP qui ne sont mappées à aucun emplacement et les requêtes issues d'emplacements pour lesquels vous n'avez pas créé d'enregistrements de géolocalisation. Si vous ne créez pas d'enregistrement par défaut, Route 53 renvoie un message « aucune réponse » pour les requêtes provenant de ces emplacements.

Vous pouvez utiliser le routage de géolocalisation pour des enregistrements dans les zones hébergées publiques et privées.

Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md).

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage de géolocalisation pour créer des enregistrements, consultez les rubriques suivantes :
+ [Valeurs spécifiques aux enregistrements de géolocalisation](resource-record-sets-values-geo.md)
+ [Valeurs spécifiques aux enregistrements d'alias de géolocalisation](resource-record-sets-values-geo-alias.md)
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

# Routage de géolocalisation dans des zones hébergées privées
<a name="routing-policy-geo-phz"></a>

Pour les zones hébergées privées, Route 53 répond aux requêtes DNS en fonction Région AWS du VPC d'où provient la requête. Pour en obtenir la liste Régions AWS, consultez [Régions et zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) dans le guide de l'*utilisateur Amazon EC2*.

Si la requête DNS provient d'une partie sur site d'un réseau hybride, elle sera considérée comme provenant de la Région AWS dans laquelle se trouve le VPC.

Si vous incluez des surveillances de l'état, vous pouvez créer des enregistrements par défaut pour :
+ Les adresses IP qui ne sont pas mappées à des emplacements géographiques.
+ Les requêtes DNS qui proviennent d'emplacements pour lesquels vous n'avez pas créé d'enregistrement de géolocalisation.

Si l'enregistrement de géolocalisation pour la région de la requête DNS est défectueux, l'enregistrement par défaut sera renvoyé (s'il est sain).

Dans l'exemple de configuration illustré dans la figure suivante, les requêtes DNS provenant d'un Région AWS us-east-1 (Virginie) seront acheminées vers le point de terminaison 1.1.1.1.

![\[Une capture d'écran qui montre un enregistrement de géolocalisation pour une zone hébergée privée.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/geolocation-phz.png)


# Routage par géoproximité
<a name="routing-policy-geoproximity"></a>

Avec le routage par proximité géographique, Amazon Route 53 achemine le trafic vers vos ressources en fonction de l'emplacement géographique de vos utilisateurs et ressources. Il achemine le trafic vers la ressource disponible la plus proche. Vous pouvez également, si vous le souhaitez, choisir d'acheminer davantage ou moins de trafic vers une ressource donnée en spécifiant une valeur, appelée *écart*. Un écart augmente ou réduit la taille de la région géographique à partir de laquelle le trafic est acheminé vers une ressource.

Vous créez des règles de proximité géographique pour vos ressources et spécifiez l'une des valeurs suivantes pour chaque règle :
+ Si vous utilisez AWS des ressources, spécifiez le Région AWS ou le groupe de zones local dans lequel vous avez créé la ressource.
+ Si vous n'utilisez pas de AWS ressources, spécifiez la latitude et la longitude de la ressource.

Pour utiliser AWS les Zones Locales, vous devez d'abord les activer. Pour plus d'informations, consultez [Premiers pas avec les zones locales](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) dans le *Guide de l'utilisateur des zones locales AWS *.

Pour en savoir plus sur la différence entre les zones Régions AWS et les zones locales, consultez [Régions et zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) dans le guide de l'*utilisateur Amazon EC2*.

(Facultatif) Pour modifier la taille de la région géographique à partir de laquelle Route 53 achemine le trafic vers une ressource, spécifiez la valeur d'écart applicable :
+ Pour étendre la taille de la région géographique à partir de laquelle Route 53 achemine le trafic vers une ressource, spécifiez un nombre entier positif compris entre 1 et 99 en tant que valeur d'écart. Route 53 diminue la taille des régions adjacentes. 
+ Pour réduire la taille de la région géographique à partir de laquelle Route 53 achemine le trafic vers une ressource, spécifiez une valeur d'écart négative comprise entre -1 et -99. La route 53 augmente la taille des régions adjacentes. 

**Note**  
Nous mettons à jour la console Traffic Flow pour Route 53. Pendant la période de transition, vous pouvez continuer à utiliser l'ancienne console.

Choisissez l'onglet correspondant à la console que vous utilisez.
+ [Nouvelle console](#traffic-flow-geoprox-routing-map-new)
+ [Ancienne console](#traffic-flow-geoprox-routing-map-old)

------
#### [ New console ]

La carte suivante en montre quatre Régions AWS (numérotées de 1 à 5) :

1. USA Ouest (Oregon)

1. Europe (Francfort)

1. Asie-Pacifique (Tokyo)

1. Afrique (Le Cap)

1. Middle East (Bahrain)

**Note**  
Les cartes ne sont disponibles qu'avec Traffic Flow.

![\[Une carte du monde qui montre comment le trafic est acheminé lorsque vous disposez d'enregistrements de géoproximité pour des ressources situées Régions AWS dans l'ouest des États-Unis (Oregon), en Europe (Francfort), en Asie-Pacifique (Tokyo), en Afrique (Le Cap) et au Moyen-Orient (Bahreïn).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)


La carte suivante montre ce qui se passe si vous ajoutez un biais de \$125 pour la région USA Ouest (Oregon) (numéro **1** sur la carte). Le trafic est acheminé vers la ressource dans cette région à partir d'une plus grande partie de l'Amérique du Nord et de toute l'Amérique du Sud qu'auparavant.

![\[Une carte du monde qui illustre la façon dont le trafic est acheminé lorsque vous ajoutez un écart de +25 dans la région USA Est (Virginie du Nord).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)


La carte suivante montre ce qui se passe si vous modifiez le biais à -25 pour la région de l'ouest des États-Unis (Oregon). **Le trafic est acheminé vers la ressource de cette région depuis de plus petites parties de l'Amérique du Nord et du Sud qu'auparavant, et une plus grande partie du trafic est acheminée vers les ressources des régions adjacentes **2**, **3** et 4.** 

![\[Une carte du monde qui montre comment le trafic est acheminé lorsque vous ajoutez un biais de -25 dans la région USA Ouest (Oregon).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)


------
#### [ Old console ]

La carte suivante en montre quatre Régions AWS (numérotées de 1 à 4) et un emplacement à Johannesburg, en Afrique du Sud, indiqué par la latitude et la longitude (5).

**Note**  
Les cartes ne sont disponibles qu'avec Traffic Flow.

![\[Une carte du monde qui montre comment le trafic est acheminé lorsque vous avez des enregistrements de géoproximité pour des ressources situées Régions AWS dans l'ouest des États-Unis (Oregon), dans l'est des États-Unis (Virginie du Nord), en Europe (Paris) et dans l'Asie-Pacifique (Tokyo), et que vous avez un enregistrement pour une ressource non liée à une AWS ressource à Johannesburg, en Afrique du Sud.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)


La carte suivante montre ce qui se produit si vous ajoutez un écart de \$125 pour la région USA Est (Virginie du Nord) (numéro **2** sur la carte). Le trafic est acheminé vers la ressource dans cette région à partir d'une plus grande partie de l'Amérique du Nord que précédemment, et à partir de l'ensemble de l'Amérique du Sud.

![\[Une carte du monde qui illustre la façon dont le trafic est acheminé lorsque vous ajoutez un écart de +25 dans la région USA Est (Virginie du Nord).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)


La carte suivante montre ce qui se produit si vous modifiez l'écart à -25 pour la région USA Est (Virginie du Nord). Le trafic est acheminé vers la ressource dans cette région à partir de plus petites parties d'Amérique du Nord et du Sud que précédemment, et davantage de trafic est acheminé vers les ressources dans les régions adjacentes **1**, **3** et **5**. 

![\[Une carte du monde qui illustre la façon dont le trafic est acheminé lorsque vous ajoutez un écart de -25 dans la région USA Est (Virginie du Nord).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)


------

L'impact de la valeur d'écart de vos ressources dépend d'un certain nombre de facteurs, dont les éléments suivants :
+ Le nombre de ressources dont vous disposez.
+ La proximité des ressources les unes par rapport aux autres.
+ Le nombre de vos utilisateurs se trouvant à proximité de la zone frontalière entre les régions géographiques. Supposons, par exemple, que vous disposiez de ressources dans l'est des Régions AWS États-Unis (Virginie du Nord) et dans l'ouest des États-Unis (Oregon), et que vous ayez de nombreux utilisateurs à Dallas, Austin et San Antonio, au Texas, aux États-Unis. Ces villes étant approximativement à égale distance entre vos ressources, un léger changement de biais pourrait entraîner une importante variation du trafic entre les ressources. Région AWS 

Nous vous recommandons de modifier la valeur d'écart par petits incréments afin d'éviter de surcharger vos ressources en raison d'un basculement inattendu du trafic.

Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md).

## Comment Amazon Route 53 utilise une valeur d'écart pour acheminer le trafic
<a name="routing-policy-geoproximity-bias"></a>

Voici la formule utilisée par Amazon Route 53 pour déterminer la manière d'acheminer le trafic :

**Écart**  
`Biased distance = actual distance * [1 - (bias/100)]`

Lorsque la valeur du biais est positive, Route 53 traite la source d'une requête DNS et la ressource que vous spécifiez dans un enregistrement de géoproximité (telle qu'une instance EC2 dans un Région AWS) comme si elles étaient plus proches l'une de l'autre qu'elles ne le sont réellement. Supposons par exemple que vous disposez des enregistrements de proximité géographique suivants :
+ Un enregistrement pour un serveur Web A, qui possède une valeur d'écart positive de 50
+ Un enregistrement pour un serveur Web B qui ne possède aucune valeur d'écart

Lorsqu'un enregistrement de proximité géographique possède une valeur d'écart positive de 50, Route 53 divise par deux la distance entre la source d'une requête et la ressource correspondant à cet enregistrement. Route 53 détermine ensuite par des calculs la ressource la plus proche de la source de la requête. Supposons qu'un serveur Web A se trouve à 150 kilomètres de la source d'une requête et que le serveur Web B se trouve à 100 kilomètres de la source de la requête. Si aucun enregistrement n'avait eu de valeur d'écart, Route 53 aurait acheminé la requête vers le serveur Web B, en raison de sa proximité. Cependant, puisque l'enregistrement pour le serveur Web A s'accompagne d'une valeur d'écart positive de 50, Route 53 considère que le serveur Web A se trouve à 75 kilomètres de la source de la requête. Route 53 va donc acheminer la requête vers le serveur Web A. 

Voici le calcul pour une valeur d'écart positive de 50 :

```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]

Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```

# Routage basé sur la latence
<a name="routing-policy-latency"></a>

Si votre application est hébergée sur plusieurs sites Régions AWS, vous pouvez améliorer les performances de vos utilisateurs en traitant leurs demandes à partir de la solution Région AWS offrant la latence la plus faible. 

**Note**  
Les données relatives à la latence entre les utilisateurs et vos ressources sont entièrement basées sur le trafic entre les utilisateurs et les centres de données AWS . Si vous n'utilisez pas de ressources dans un Région AWS, la latence réelle entre vos utilisateurs et vos ressources peut varier considérablement en fonction des données de AWS latence. Cela est vrai même si vos ressources sont situées dans la même ville qu'une Région AWS.

Pour utiliser le routage basé sur la latence, vous créez des enregistrements pour vos ressources dans plusieurs Régions AWS. Lorsque Route 53 reçoit une requête DNS pour votre domaine ou un sous-domaine (exemple.com ou acme.exemple.com), il détermine les Régions AWS pour lesquelles vous avez créé des enregistrements de latence, les régions offrant aux utilisateurs la latence la plus faible, puis sélectionne un enregistrement de latence pour cette région. Route 53 répond avec la valeur de l'enregistrement sélectionné, telle que l'adresse IP d'un serveur Web. 

Par exemple, si vous disposez d'équilibreurs de charge Elastic Load Balancing dans la région USA Ouest (Oregon) et la région Asie-Pacifique (Singapour). Vous avez créé un enregistrement de latence pour chaque équilibreur de charge. Voici ce qui se produit quand un utilisateur basé à Londres entre le nom de votre domaine dans un navigateur :

1. DNS achemine la requête vers un serveur de noms Route 53.

1. Route 53 se réfère à ses données relatives à la latence entre Londres et la région Singapour, et entre Londres et la région Oregon. 

1. Si la latence est inférieure entre les régions de Londres et de l'Oregon, Route 53 répond à la requête avec l'adresse IP de l'équilibreur de charge de l'Oregon. Si la latence est inférieure entre les régions de Londres et de Singapour, Route 53 répond avec l'adresse IP de l'équilibreur de charge de Singapour. 

La latence entre les hôtes sur Internet peut évoluer au fil du temps, suite à des modifications de connectivité réseau et de routage. Le routage basé sur la latence s'appuie sur des mesures de latence réalisées sur une période donnée. Ces mesures reflètent ces évolutions. Une demande acheminée vers la région de l'Oregon une semaine peut être acheminée vers la région de Singapour la semaine suivante.

**Note**  
Lorsqu'un navigateur ou un autre utilisateur utilise un résolveur DNS qui prend en charge l' edns-client-subnetextension de EDNS0, le résolveur DNS envoie à Route 53 une version tronquée de l'adresse IP de l'utilisateur. Si vous configurez le routage en fonction de la latence, Route 53 tient compte de cette valeur lors de l'acheminement du trafic vers vos ressources. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md).

Vous pouvez utiliser la stratégie de routage de latence pour des enregistrements dans une zone hébergée privée.

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage de latence pour créer des enregistrements, consultez les rubriques suivantes :
+ [Valeurs spécifiques aux enregistrements de latence](resource-record-sets-values-latency.md)
+ [Valeurs spécifiques aux enregistrements d'alias de latence](resource-record-sets-values-latency-alias.md)
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

# Routage basé sur la latence dans les zones hébergées privées
<a name="routing-policy-latency-phz"></a>

Pour les zones hébergées privées, Route 53 répond aux requêtes DNS avec un point de terminaison Région AWS situé au même endroit ou le plus proche Région AWS du VPC d'où provient la requête.

**Note**  
Si un point de terminaison sortant est transféré vers un point de terminaison entrant, l'enregistrement sera résolu en fonction de l'emplacement du point de terminaison entrant, et non du point de terminaison sortant.

Si vous incluez des surveillances de l'état et que l'enregistrement avec la latence la plus faible par rapport à l'origine de la requête est défectueux, un point de terminaison sain avec la latence la plus faible est renvoyé.

Dans l'exemple de configuration illustré dans la figure suivante, les requêtes DNS provenant d'un Région AWS us-east-1, ou du plus proche de celui-ci, seront acheminées vers le point de terminaison 1.1.1.1. Les requêtes DNS provenant de la région us-west-2, ou la plus proche de celle-ci, seront acheminées vers le point de terminaison 2.2.2.2.

![\[Une capture d'écran qui montre deux enregistrements de latence pour une zone hébergée privée.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/latency-phz.png)


# Routage basé sur IP
<a name="routing-policy-ipbased"></a>

Avec le routage basé sur IP dans Amazon Route 53, vous pouvez affiner votre routage DNS en utilisant votre compréhension de votre réseau, de vos applications, et de vos clients pour prendre les meilleures décisions de routage DNS pour vos utilisateurs finaux. Le routage basé sur IP vous donne un contrôle granulaire pour optimiser les performances ou réduire les coûts du réseau en téléchargeant vos données sur Route 53 sous forme de mappages. user-IP-to-endpoint

Le routage basé sur la géolocalisation et la latence s'appuie sur les données que Route 53 collecte et tient à jour. Cette approche fonctionne bien pour la majorité des clients, mais le routage basé sur IP vous offre la possibilité supplémentaire d'optimiser le routage en fonction de la connaissance spécifique de votre clientèle. Par exemple, un fournisseur mondial de contenu vidéo peut vouloir acheminer les utilisateurs finaux à partir d'un fournisseur de services Internet (FSI) particulier.

Voici quelques cas d'utilisation courants du routage basé sur IP :
+ Vous souhaitez acheminer les utilisateurs finaux de certains points de terminaison ISPs vers des points de terminaison spécifiques afin d'optimiser les coûts ou les performances du réseau.
+ Vous voulez ajouter des surcharges aux types de routage Route 53 existants, comme le routage de géolocalisation, en fonction de votre connaissance des emplacements physiques de vos clients.

**Gérer les plages d'adresses IP et les associer à un ensemble d'enregistrements de ressources (RRSet)**  
 Pour IPv4, vous pouvez utiliser des blocs CIDR d'une longueur comprise entre 1 et 24 bits inclus, tandis que pourIPv6, vous pouvez utiliser des blocs d'adresse CIDR d'une longueur comprise entre 1 et 48 bits inclus. Pour définir un bloc d'adresse CIDR zéro bit (0.0.0.0/0 or ::/0), utilisez l'emplacement par défaut (« \$1 »).

Pour les requêtes DNS dont le CIDR est plus long que celui spécifié dans la collection d'adresses CIDR, Route 53 les met en correspondance avec le CIDR le plus court. Par exemple, si vous spécifiez 2001:0 DB8 : :/32 comme bloc CIDR dans votre collection CIDR et qu'une requête provient de 2001:0 DB8 : 0000:1234 : :/48, elle correspondra. Si, par contre, vous spécifiez 2001:0 DB8 : 0000:1234 : :/48 dans votre collection CIDR et qu'une requête provient de 2001:0 DB8 : :/32, cela ne correspondra pas et Route 53 répondra avec l'enregistrement correspondant à l'emplacement par défaut (« \$1 »).

Vous pouvez regrouper des jeux de blocs CIDR (ou plages IP) en emplacements CIDR, qui sont à leur tour regroupés en entités réutilisables appelées collections CIDR :

**Bloc d'adresse CIDR**  
Une plage d'adresses IP en notation CIDR, par exemple 192.0.2.0/24 ou 2001 : : :/32. DB8

**Emplacement CIDR**  
Une liste nommée de blocs CIDR. Par exemple, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001 : : :/32]. DB8 Les blocs d'une liste d'emplacements CIDR ne doivent pas nécessairement être adjacents ou appartenir à la même plage.   
Un même emplacement peut avoir les deux IPv6 blocs IPv4 et cet emplacement peut être associé à la fois aux ensembles d'enregistrements A et AAAA, respectivement.   
Le nom de l'emplacement est souvent un emplacement par convention, mais peut être n'importe quelle chaîne, par exemple *Entreprise-A*.

**Collection CIDR**  
Une collection d'emplacements nommée. Par exemple, mycollection = [example-isp-seattle, example-isp-tokyo].  
Les jeux d'enregistrements de ressources de routage basé sur IP font référence à un emplacement dans une collection, et tous les jeux d'enregistrements de ressources pour le même nom et type de jeu d'enregistrements doivent faire référence à la même collection. Par exemple, si vous créez des sites Web dans deux régions et que vous voulez diriger les requêtes DNS de deux emplacements CIDR différents vers un site Web spécifique en fonction des adresses IP d'origine, ces deux emplacements doivent être répertoriés dans la même collection CIDR.

Vous ne pouvez pas utiliser la politique de routage basée sur IP pour les enregistrements dans une zone hébergée privée.

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la politique de routage basée sur IP pour créer des enregistrements, consultez les rubriques suivantes :
+ [Valeurs spécifiques aux enregistrements basés sur IP](resource-record-sets-values-ipbased.md)
+ [Valeurs spécifiques aux enregistrements d'alias basés sur IP](resource-record-sets-values-ipbased-alias.md)
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

**Topics**
+ [Création d'une collection CIDR avec des emplacements et des blocs CIDR](resource-record-sets-creating-cidr-collection.md)
+ [Utilisation des emplacements et des blocs CIDR](resource-record-sets-working-with-cidr-locations.md)
+ [Suppression d'une collection CIDR](resource-record-sets-delete-cidr-collection.md)
+ [Déplacement d'un routage par géolocalisation vers un routage basé sur IP](resource-record-sets-move-geolocation-to-cidr.md)

# Création d'une collection CIDR avec des emplacements et des blocs CIDR
<a name="resource-record-sets-creating-cidr-collection"></a>



Pour commencer, créez une collection CIDR et ajoutez-y des blocs et des emplacements CIDR.<a name="CIDR-collection-creating-procedure"></a>

**Pour créer une collection CIDR à l'aide de la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **IP-based routing** (Routage basé sur IP), puis **CIDR collections** (Collections CIDR).

1. Sélectionnez **Create CIDR collection** (Créer une collection CIDR).

1. Dans le panneau **Create CIDR collection** (Créer une collection CIDR), sous **Details** (Détails), saisissez un nom pour la collection.

1. Choisissez **Create collection** (Créer une collection) pour créer une collection vide.

   - ou -

   Dans la section **Créer des emplacements CIDR**, saisissez le nom de l'emplacement CIDR dans le champ **Emplacement CIDR**. Le nom de l'emplacement peut être n'importe quelle chaîne d'identification, par exemple **company 1** ou **Seattle**. Il ne doit pas nécessairement s'agir d'un emplacement géographique réel.
**Important**  
Le nom de l'emplacement CIDR a une longueur maximale de 16 caractères.

   Saisissez les blocs d'adresse CIDR dans le champ **Blocs CIDR**, un par ligne. Il peut s'agir IPv4 d' IPv6 adresses comprises entre /0 et /24 pour IPv4 et /0 à /48 pour. IPv6

1. Après avoir saisi les blocs CIDR, choisissez **Create CIDR collection** (Créer une collection CIDR), ou **Add another location** (Ajouter un autre emplacement) pour continuer à saisir des emplacements et un bloc CIDR. Vous pouvez saisir plusieurs emplacements CIDR par collection.

1. Après avoir saisi les emplacements CIDR, choisissez **Create CIDR collection** (Créer une collection CIDR).

# Utilisation des emplacements et des blocs CIDR
<a name="resource-record-sets-working-with-cidr-locations"></a>

<a name="CIDR-locations-work-with-procedure"></a>

**Pour travailler avec des emplacements CIDR en utilisant la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **IP-based routing** (Routage basé sur IP), **CIDR collections** (Collections CIDR), puis, dans la section **CIDR collections** (Collections CIDR), cliquez sur un lien vers une collection CIDR dans la liste **Collection name** (Nom de la collection).

   Sur la page **CIDR locations** (Emplacements CIDR), vous pouvez créer un emplacement CIDR, le supprimer ou modifier un emplacement et ses blocs.
   + Pour créer un emplacement, choisissez **Create CIDR location** (Créer un emplacement CIDR). 
   + Dans le panneau **Create CIDR location** (Créer un emplacement CIDR), saisissez un nom pour l'emplacement, les blocs CIDR associés à l'emplacement, puis cliquez sur **Create** (Créer).
   + Pour afficher un emplacement CIDR et les blocs qu'il contient, choisissez la case d'option en regard d'un emplacement pour afficher son nom et ses blocs CIDR dans le panneau d'emplacement.

     Dans ce panneau, vous pouvez également choisir **Modifier** pour mettre à jour le nom de l'emplacement ou de ses blocs CIDR. Choisissez **Save** (Enregistrer) lorsque vous avez terminé la modification.
   + Pour supprimer un emplacement CIDR et les blocs qu'il contient, sélectionnez la case d'option en regard de l'emplacement que vous voulez supprimer, puis cliquez sur **Delete** (Supprimer). Pour confirmer la suppression, saisissez le nom de l'emplacement dans la zone de saisie de texte et sélectionnez à nouveau **Delete** (Supprimer).
**Important**  
La suppression d'un emplacement CIDR ne peut pas être annulée. Si vous avez des enregistrements DNS associés à l'emplacement, votre domaine peut devenir inaccessible.

# Suppression d'une collection CIDR
<a name="resource-record-sets-delete-cidr-collection"></a>

<a name="CIDR-collection-delete-procedure"></a>

**Pour supprimer une collection CIDR, ses emplacements et blocs en utilisant la console Route 53**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **IP-based routing** (Routage basé sur IP), puis **CIDR collections** (Collections CIDR).

1. Dans la section **CIDR collections** (Collections CIDR), cliquez sur le nom lié de la collection que vous voulez supprimer.

1. Sur la page **CIDR locations** (Emplacements CIDR), sélectionnez chaque emplacement un par un, choisissez **Delete** (Supprimer), saisissez son nom dans la boîte de dialogue, puis choisissez **Delete** (Supprimer). Vous devez supprimer chaque emplacement associé à une collection CIDR avant de pouvoir supprimer la collection.

1. Une fois la suppression de chaque emplacement CIDR terminée, sur la page **CIDR locations** (Emplacements CIDR), choisissez le bouton radio en regard de la collection que vous voulez supprimer, puis choisissez **Delete** (Supprimer).

# Déplacement d'un routage par géolocalisation vers un routage basé sur IP
<a name="resource-record-sets-move-geolocation-to-cidr"></a>

Si vous utilisez des politiques de routage par géolocalisation ou par géoproximité et que vous constatez régulièrement que des clients spécifiques sont acheminés vers un point de terminaison qui n'est pas optimal en fonction de leur emplacement physique ou de la topologie du réseau, vous pouvez mieux cibler les plages IP publiques de ces clients en utilisant le routage par IP.

Le tableau suivant contient un exemple de configuration de géolocalisation pour un routage de géolocalisation existant que nous allons acheminer avec précision pour les plages IP de Californie.


| Nom du jeu d'enregistrements | Politique et origine du routage | Adresse IP du point de terminaison de l'application  | 
| --- | --- | --- | 
|  example.com  |  Routage par géolocalisation (US)  |  `198.51.100.1`  | 
|  example.com  |  Routage par géolocalisation (UE)   |  `198.51.100.2`  | 

Pour remplacer les plages IP de Californie par un nouveau point de terminaison d'application, recréez d'abord le routage de géolocalisation sous un nouveau nom de jeu d'enregistrements.


| Nom du jeu d'enregistrements | Politique et origine du routage | Adresse IP du point de terminaison de l'application  | 
| --- | --- | --- | 
|  geo.example.com  |  Routage par géolocalisation (US)  |  `198.51.100.1`  | 
|  geo.example.com  |  Routage par géolocalisation (UE)   |  `198.51.100.2`  | 

Créez ensuite des enregistrements de routage basés sur IP et un enregistrement par défaut qui pointe vers votre jeu d'enregistrements de routage de géolocalisation récemment recréé. 


| Nom du jeu d'enregistrements | Politique et origine du routage | Adresse IP du point de terminaison de l'application  | 
| --- | --- | --- | 
|  example.com  |  Routage basé sur IP (par défaut)   |  Enregistrement d'alias vers le point de terminaison de l'application geo.example.com que vous voulez être le point par défaut. Par exemple, `198.51.100.1`.  | 
|  example.com  |  Routage basé sur IP (plages IP de Californie)   |  `198.51.100.3`  | 

# Multivalue answer routing (Routage de réponse multivaleur)
<a name="routing-policy-multivalue"></a>

Le routage de réponse multivaleur vous permet de configurer Amazon Route 53 pour renvoyer plusieurs valeurs, comme des adresses IP pour vos serveurs web, en réponse aux requêtes DNS. Vous pouvez spécifier plusieurs valeurs pour la plupart des enregistrements, mais le routage de réponse multivaleur vous permet également de vérifier l'intégrité de chaque ressource. Route 53 renvoie donc uniquement les valeurs des ressources saines. Il ne constitue pas de substitut pour un équilibreur de charge, mais la capacité de retourner plusieurs adresses IP dont l'intégrité est vérifiable permet d'utiliser DNS pour améliorer la disponibilité et l'équilibrage de charge.

Pour acheminer le trafic approximativement de manière aléatoire vers plusieurs ressources, comme des serveurs web, vous créez un enregistrement de réponse multivaleur pour chaque ressource et, facultativement, vous associez une surveillance de l'état Route 53 à chaque enregistrement. Route 53 répond aux requêtes DNS par jusqu'à huit enregistrements et fournit des réponses distinctes aux différents résolveurs DNS. Si un serveur web devient indisponible après qu'un résolveur met une réponse en cache, le logiciel client peut essayer une autre adresse IP dans la réponse.

Notez ce qui suit :
+ Si vous associez une surveillance de l'état à un enregistrement de réponse multivaleur, Route 53 répond aux requêtes DNS avec l'adresse IP correspondante uniquement lorsque la surveillance de l'état est saine.
+ Si vous n'associez pas de surveillance de l'état à un enregistrement de réponse multivaleur, Route 53 considère toujours l'enregistrement comme sain.
+ Si vous disposez de huit enregistrements sains ou moins, Route 53 répond à toutes les requêtes DNS par tous les enregistrements sains.
+ Lorsque tous les registres sont non sains, Route 53 répond à toutes les requêtes DNS par jusqu'à huit registres non sains.

Vous pouvez utiliser la stratégie de routage de réponse multivaleur pour des enregistrements dans une zone hébergée privée.

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la politique de routage de réponse multivaleur pour créer des enregistrements, veuillez consulter [Valeurs spécifiques pour les enregistrements de réponses multivaleur](resource-record-sets-values-multivalue.md) et [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md).

# Weighted routing (Routage pondéré)
<a name="routing-policy-weighted"></a>

Le routage pondéré vous permet d'associer plusieurs ressources à un nom de domaine unique (par exemple, example.com) ou à un nom de sous-domaine (par exemple, acme.example.com) et de choisir le volume de trafic acheminé vers chaque ressource. Cela peut vous être utile pour de nombreuses actions, notamment l'équilibrage de charge et le test de nouvelles versions de logiciels.

Pour configurer un acheminement pondéré, créez des enregistrements avec les mêmes valeurs pour les champs Nom et Type que celles de vos ressources. Vous attribuez à chaque enregistrement une pondération relative correspondant au volume de trafic à envoyer à chaque ressource. Amazon Route 53 retourne le trafic vers une ressource en fonction de la pondération attribuée à l'enregistrement par rapport au poids total des enregistrements dans le groupe : 

![\[Formule pour le calcul de la quantité de trafic acheminée vers une ressource donnée : poids d'un enregistrement spécifié/somme des poids de tous les enregistrements.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/WRR_calculation.png)


Par exemple, si vous souhaitez envoyer une petite partie de votre trafic vers une ressource et que le reste soit acheminé vers une autre ressource, vous pouvez spécifier des pondérations de 1 à 255. La ressource ayant une pondération de 1 obtient 1/256e du trafic (1/(1\$1255)) et l'autre ressource obtient 255/256e (255/(1\$1255)). Vous pouvez progressivement modifier l'équilibre en changeant les pondérations. Si vous arrêtez d'envoyer du trafic vers une ressource, vous pouvez passer la pondération de cette ressource à 0.

Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage pondéré pour créer des enregistrements, consultez les rubriques suivantes :
+ [Valeurs spécifiques aux enregistrements pondérés](resource-record-sets-values-weighted.md)
+ [Valeurs spécifiques aux enregistrements d'alias pondérés](resource-record-sets-values-weighted-alias.md)
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

Vous pouvez utiliser la stratégie de routage pondéré pour des enregistrements dans une zone hébergée privée.

## Surveillance de l'état et routage pondéré
<a name="routing-policy-weighted-healthchecks"></a>

Si vous ajoutez les surveillances de l'état à tous les enregistrements d'un groupe d'enregistrements pondérés, mais que vous attribuez des pondérations différentes de zéro à certains enregistrements et des pondérations égales à zéro pour d'autres, les surveillances de l'état fonctionnent de la même manière que lorsque tous les enregistrements ont des pondérations différentes de zéro, avec les exceptions suivantes :
+ Initialement, Route 53 prend uniquement en compte les enregistrements pondérés dont la pondération est différente de zéro, s'il y en a.
+ Si tous les enregistrements ayant une pondération supérieure à 0 ne sont pas sains, Route 53 prend en compte les enregistrements dont la pondération est égale à zéro.

Le tableau suivant détaille le comportement lorsque l'enregistrement à pondération nulle inclut une surveillance de l'état :


|   | Enregistrement 1 | Enregistrement 2 | Enregistrement 3 | 
| --- |--- |--- |--- |
|  Pondération  |  1  |  1  |  0  | 
|  Comprend la surveillance de l'état ?  |  Oui  |  Oui  |  Oui  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Non sain  |  Non sain  |  Sain  | 
|  Requête DNS répondue ?  |  Non  |  Non  |  Oui  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Non sain  |  Non sain  |  Non sain  | 
| Requête DNS répondue ? |  Oui  |  Oui  |  Non  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Non sain  |  Sain  |  Non sain  | 
|  Requête DNS répondue ?  |  Non  |  Oui  |  Non  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Sain  |  Sain  |  Non sain  | 
|  Requête DNS répondue ?  |  Oui  |  Oui  |  Non  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Sain  |  Sain  |  Sain  | 
|  Requête DNS répondue ?  |  Oui  |  Oui  |  Non  | 

Le tableau suivant détaille le comportement lorsque l'enregistrement à pondération nulle n'inclut pas une surveillance de l'état :


|   | Enregistrement 1 | Enregistrement 2 | Enregistrement 3 | 
| --- |--- |--- |--- |
|  Pondération  |  1  |  1  |  0  | 
|  Comprend la surveillance de l'état ?  |  Oui  |  Oui  |  Non  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Sain  |  Sain  | N/A | 
| Requête DNS répondue ? | Oui |  Oui  | Non | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Non sain  |  Non sain  |  N/A  | 
|  Requête DNS répondue ?  |  Non  |  Non  |  Oui  | 
|  | 
| --- |
|  Statut de la surveillance de l'état  |  Non sain  |  Sain  |  N/A  | 
| Requête DNS répondue ? |  Non  |  Oui  |  Non  | 

# Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur
<a name="routing-policy-edns0"></a>

Pour améliorer la précision de la géolocalisation, de la géoproximité, du routage basé sur IP et du routage par latence, Amazon Route 53 prend en charge l'extension de. edns-client-subnet EDNS0 (EDNS0 ajoute plusieurs extensions facultatives au protocole DNS.) Route 53 ne peut être utilisée edns-client-subnet que lorsque les résolveurs DNS la prennent en charge :
+ Lorsqu'un navigateur ou un autre lecteur utilise un résolveur DNS non compatible edns-client-subnet, Route 53 utilise l'adresse IP source du résolveur DNS pour localiser approximativement l'utilisateur et répond aux requêtes de géolocalisation avec l'enregistrement DNS correspondant à l'emplacement du résolveur.
+ Lorsqu'un navigateur ou un autre utilisateur utilise un résolveur DNS compatible edns-client-subnet, le résolveur DNS envoie à Route 53 une version tronquée de l'adresse IP de l'utilisateur. Route 53 détermine l'emplacement de l'utilisateur en fonction de l'adresse IP tronquée plutôt que de l'adresse IP source du résolveur DNS ; cela fournit généralement une estimation plus précise de l'emplacement de l'utilisateur. Route 53 répond ensuite aux requêtes de géolocalisation avec l'enregistrement DNS correspondant à l'emplacement de l'utilisateur.
+ EDNS0 ne s'applique pas aux zones hébergées privées. Pour les zones hébergées privées, Route 53 utilise les données des résolveurs VPC dans lesquels se trouve la Région AWS zone hébergée privée pour prendre des décisions de géolocalisation et de routage par latence.

Pour plus d'informations edns-client-subnet, consultez la RFC relative au sous-réseau du client EDNS, sous-réseau [client dans les demandes](https://www.rfc-editor.org/rfc/rfc7871) DNS.

# Choix entre des enregistrements avec ou sans alias
<a name="resource-record-sets-choosing-alias-non-alias"></a>

Les *enregistrements d'alias* Amazon Route 53 fournissent une extension spécifique à Route 53 à la fonctionnalité DNS. Les enregistrements d'alias vous permettent d'acheminer le trafic vers AWS des ressources sélectionnées, y compris, mais sans s'y limiter, les CloudFront distributions et les compartiments Amazon S3. Elles vous permettent également d'acheminer le trafic d'un enregistrement dans une zone hébergée vers un autre enregistrement. 

Contrairement à l'enregistrement CNAME, vous pouvez créer un enregistrement d'alias pour le nœud supérieur d'un espace de nom DNS, également appelé *zone apex*. Par exemple, si vous enregistrez le nom DNS example.com, la zone apex est example.com. Vous ne pouvez pas créer un enregistrement CNAME pour exemple.com, mais vous pouvez créer un enregistrement d'alias pour exemple.com qui achemine le trafic vers www.exemple.com (tant que le type d'enregistrement pour www.exemple.com n'est pas CNAME).

Quand Route 53 reçoit une requête DNS pour un enregistrement d'alias, Route 53 répond avec la valeur applicable pour cette ressource :
+ **Une API régionale Amazon API Gateway personnalisée ou une API optimisée pour les périphériques** : Route 53 répond avec une ou plusieurs adresses IP pour votre API.
+ **Un point de terminaison d'interface d'un VPC Amazon** : Route 53 répond avec une ou plusieurs adresses IP pour votre point de terminaison d'interface.
+ **Une CloudFront distribution** — Route 53 répond avec une ou plusieurs adresses IP pour les serveurs de CloudFront périphérie qui peuvent diffuser votre contenu.
+ **Service App Runner** — Route 53 répond avec une ou plusieurs adresses IP.
+ **Un environnement Elastic Beanstalk** : Route 53 répond avec une ou plusieurs adresses IP pour l'environnement.
+ **Un équilibreur de charge Elastic Load Balancing** : Route 53 répond avec une ou plusieurs adresses IP pour l'équilibreur de charge. Cela inclut Application Load Balancer, Classic Load Balancer et Network Load Balancer.
+ **Un AWS Global Accelerator accélérateur** — Route 53 répond avec les adresses IP de l'accélérateur. 
+ **Un OpenSearch service** — Route 53 répond avec une ou plusieurs adresses IP pour le domaine personnalisé du OpenSearch service.
+ **Un compartiment Amazon S3 configuré comme un site web statique** : Route 53 répond avec une seule adresse IP pour le compartiment Amazon S3.
+ **Un autre enregistrement Route 53 du même type dans la même zone hébergée** – Route 53 répond comme si la requête était destinée à l'enregistrement référencé par l'enregistrement d'alias (voir [Comparaison d'enregistrements d'alias et CNAME](#resource-record-sets-choosing-alias-non-alias-comparison)).
+ **AWS AppSync nom de domaine** — Route 53 répond avec une ou plusieurs adresses IP pour le point de terminaison de votre interface.

Pour de plus amples informations, veuillez consulter [Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

Lorsque vous utilisez un enregistrement d'alias pour acheminer le trafic vers une AWS ressource, Route 53 reconnaît automatiquement les modifications apportées à la ressource. Imaginez par exemple qu'un enregistrement d'alias pour example.com pointe vers un équilibreur de charge Elastic Load Balancing à l'adresse lb1-1234.us-east-2.elb.amazonaws.com. Si l'adresse IP de l'équilibreur de charge change, Route 53 commence automatiquement à répondre aux requêtes DNS à l'aide de la nouvelle adresse IP.

Si un enregistrement d'alias pointe vers une AWS ressource, vous ne pouvez pas définir la durée de vie (TTL) ; Route 53 utilise le TTL par défaut pour la ressource. Si un enregistrement d'alias pointe vers un autre enregistrement de la même zone hébergée, Route 53 utilise la durée de vie de l'enregistrement vers lequel l'enregistrement d'alias pointe. Pour de plus amples informations sur la valeur de la durée de vie actuelle pour Elastic Load Balancing, consultez [Demande de routage](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) dans le *Guide de l'utilisateur Elastic Load Balancing* et recherchez « ttl ».

Pour plus d'informations sur la création d'enregistrements à l'aide de la console Route 53, consultez [Création d'enregistrements à l'aide de la console Amazon Route 53](resource-record-sets-creating.md). Pour plus d'informations sur les valeurs que vous spécifiez dans les enregistrements d'alias, consultez la rubrique correspondante dans [Valeurs à spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53](resource-record-sets-values.md) :
+ [Valeurs spécifiques aux enregistrements d'alias simples](resource-record-sets-values-alias.md)
+ [Valeurs spécifiques aux enregistrements d'alias pondérés](resource-record-sets-values-weighted-alias.md)
+ [Valeurs spécifiques aux enregistrements d'alias de latence](resource-record-sets-values-latency-alias.md)
+ [Valeurs spécifiques aux enregistrements d'alias de basculement](resource-record-sets-values-failover-alias.md)
+ [Valeurs spécifiques aux enregistrements d'alias de géolocalisation](resource-record-sets-values-geo-alias.md)
+ [Valeurs spécifiques aux enregistrements d'alias de géoproximité](resource-record-sets-values-geoprox-alias.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)

## Comparaison d'enregistrements d'alias et CNAME
<a name="resource-record-sets-choosing-alias-non-alias-comparison"></a>

Les enregistrements d'alias sont similaires aux enregistrements CNAME, mais présentent néanmoins des différences importantes : La liste suivante compare les enregistrements d'alias et les enregistrements CNAME.

**Ressources vers lesquelles vous pouvez rediriger des requêtes**    
**Enregistrements d'alias**  
Un enregistrement d'alias peut uniquement rediriger les requêtes vers AWS des ressources sélectionnées, y compris, mais sans s'y limiter, les suivantes :  
+ Compartiments Amazon S3
+ CloudFront distributions
+ Autre enregistrement dans la même zone hébergée Route 53
Par exemple, vous pouvez créer un enregistrement d'alias nommé acme.exemple.com qui redirige les requêtes vers un compartiment Amazon S3 qui est également nommée acme.exemple.com. Vous pouvez également créer un enregistrement d'alias acme.exemple.com qui redirige les requêtes vers un enregistrement nommé zenith.exemple.com dans la zone hébergée exemple.com.  
**Enregistrements CNAME**  
Un enregistrement CNAME peut rediriger les requêtes DNS vers tout enregistrement DNS. Par exemple, vous pouvez créer un enregistrement CNAME qui redirige les requêtes depuis acme.exemple.com vers zenith.exemple.com ou acme.exemple.org. Vous n'avez pas besoin d'utiliser Route 53 comme service DNS pour le domaine vers lequel vous redirigez les requêtes.

**Création d'enregistrements portant le même nom que le domaine (enregistrements dans la zone apex)**    
**Enregistrements d'alias**  
Dans la plupart des configurations, vous pouvez créer un enregistrement d'alias portant le même nom que la zone hébergée (la zone apex). La seule exception survient lorsque vous souhaitez rediriger les requêtes depuis la zone apex (comme exemple.com) vers un enregistrement de la zone hébergée qui est de type CNAME (comme zenith.exemple.com). L'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias.  
**Enregistrements CNAME**  
Vous ne pouvez pas créer un enregistrement CNAME portant le même nom que la zone hébergée (la zone apex). Cela est vrai pour les zones hébergées pour les noms de domaine (exemple.com) et pour les zones hébergées pour les sous-domaines (zenith.exemple.com).

**Tarification des requêtes DNS**    
**Enregistrements d'alias**  
Route 53 ne facture pas les requêtes d'alias vers les AWS ressources. Pour plus d’informations, consultez [Tarification Amazon Route 53](https://aws.amazon.com/route53/pricing/).  
**Enregistrements CNAME**  
Route 53 applique des frais pour les requêtes CNAME.  
Si vous créez un enregistrement CNAME qui procède à une redirection vers le nom d'un autre enregistrement dans une zone hébergée Route 53 (la même zone hébergée ou une autre zone hébergée), chaque requête DNS est facturée sur la base de deux requêtes :  
+ Route 53 répond à la première requête DNS avec le nom de l'enregistrement vers lequel vous souhaitez procéder à la redirection.
+ Ensuite, le résolveur DNS doit soumettre une autre requête pour l'enregistrement dans la première réponse afin d'obtenir des informations sur l'endroit vers lequel diriger le trafic, par exemple, l'adresse IP d'un serveur Web.
Si l'enregistrement CNAME procède à la redirection vers le nom d'un enregistrement hébergé avec un autre service DNS, Route 53 facture une requête. L'autre service DNS peut facturer la deuxième requête.

**Type d'enregistrement spécifié dans la requête DNS**    
**Enregistrements d'alias**  
Route 53 répond à une requête DNS uniquement lorsque le nom de l'enregistrement d'alias (par exemple, acme.exemple.com) et le type de l'enregistrement d'alias (par exemple, A ou AAAA) correspondent au nom et au type dans la requête DNS.  
**Enregistrements CNAME**  
Un enregistrement CNAME redirige les requêtes DNS pour un nom d'enregistrement, quel que soit le type d'enregistrement spécifié dans la requête DNS (A ou AAAA, par exemple).

**Comment les enregistrements sont répertoriés dans des requêtes dig ou nslookup**    
**Enregistrements d'alias**  
Dans la réponse à une requête dig ou nslookup, un enregistrement d'alias est répertorié selon le type d'enregistrement que vous avez spécifié lors de la création de l'enregistrement (A ou AAAA, par exemple). (Le type d'enregistrement que vous spécifiez pour un enregistrement d'alias dépend de la ressource vers laquelle vous acheminez le trafic. Par exemple, pour acheminer le trafic vers un compartiment S3, vous spécifiez le type A.) La propriété alias n'est visible que dans la console Route 53 ou dans la réponse à une demande programmatique, telle qu'une `list-resource-record-sets` commande AWS CLI.  
**Enregistrements CNAME**  
Un enregistrement CNAME est répertorié en tant qu'enregistrement CNAME en réponse à des requêtes dig ou nslookup.

# Types d'enregistrements DNS pris en charge
<a name="ResourceRecordTypes"></a>

Amazon Route 53 prend en charge les types d'enregistrement DNS qui sont répertoriés dans cette section. Chaque type d'enregistrement inclut également un exemple illustrant la façon de formater l'élément `Value` lorsque vous accédez à Route 53 à l'aide de l'API.

**Note**  
Pour les types d'enregistrement qui incluent un nom de domaine, entrez un nom de domaine complet, par exemple, *www.example.com*. Le point final est facultatif ; Route 53 suppose que le nom de domaine est complet. Cela signifie que Route 53 traite *www.example.com* (sans point final) et *www.example.com.* (avec un point final) de la même façon.

Route 53 fournit une extension à la fonctionnalité DNS connue sous le nom d'enregistrement d'alias. À l'instar des enregistrements CNAME, les enregistrements d'alias vous permettent d'acheminer le trafic vers AWS des ressources sélectionnées, telles que les CloudFront distributions et les compartiments Amazon S3. Pour plus d'informations, notamment une comparaison des enregistrements d'alias et CNAME, consultez [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Type d'enregistrement](#AFormat)
+ [Type d'enregistrement AAAA](#AAAAFormat)
+ [Type d'enregistrement CAA](#CAAFormat)
+ [Type d'enregistrement CNAME](#CNAMEFormat)
+ [Type d'enregistrement DS](#DSFormat)
+ [Type d'enregistrement HTTPS](#HTTPSFormat)
+ [Type d'enregistrement MX](#MXFormat)
+ [Type d'enregistrement NAPTR](#NAPTRFormat)
+ [Type d'enregistrement NS](#NSFormat)
+ [Type d'enregistrement PTR](#PTRFormat)
+ [Type d'enregistrement SOA](#SOAFormat)
+ [Type d'enregistrement SPF](#SPFFormat)
+ [Type d'enregistrement SRV](#SRVFormat)
+ [Type d'enregistrement SSHFP](#SSHFPFormat)
+ [Type d'enregistrement SVCB](#SVCBFormat)
+ [Type d'enregistrement TLSA](#TLSAFormat)
+ [Type d'enregistrement TXT](#TXTFormat)

## Type d'enregistrement
<a name="AFormat"></a>

Vous utilisez un enregistrement A pour acheminer le trafic vers une ressource, telle qu'un serveur Web, en utilisant une IPv4 adresse en notation décimale en pointillés.

**Exemple pour la console Amazon Route 53**

```
192.0.2.1
```

**Exemple pour l'API Route 53**

```
<Value>192.0.2.1</Value>
```

## Type d'enregistrement AAAA
<a name="AAAAFormat"></a>

Vous utilisez un enregistrement AAAA pour acheminer le trafic vers une ressource, telle qu'un serveur Web, en utilisant une IPv6 adresse au format hexadécimal séparé par des deux-points.

**Exemple pour la console Amazon Route 53**

```
2001:0db8:85a3:0:0:8a2e:0370:7334
```

**Exemple pour l'API Route 53**

```
<Value>2001:0db8:85a3:0:0:8a2e:0370:7334</Value>
```

## Type d'enregistrement CAA
<a name="CAAFormat"></a>

Un enregistrement CAA indique quelles autorités de certification (CAs) sont autorisées à délivrer des certificats pour un domaine ou un sous-domaine. La création d'un enregistrement CAA permet d'éviter que des personnes mal CAs intentionnées ne délivrent des certificats pour vos domaines. Un enregistrement CAA ne se substitue pas exigences de sécurité formulées par votre autorité de certification, dont celle vous imposant de confirmer que vous êtes le propriétaire d'un domaine.

Vous pouvez utiliser des enregistrements CAA pour spécifier ce qui suit :
+ Quelles autorités de certification (CAs) peuvent délivrer SSL/TLS des certificats, le cas échéant
+ L'adresse e-mail ou l'URL à contacter quand une autorité de certification émet un certificat pour le domaine ou le sous-domaine

Lorsque vous ajoutez un enregistrement CAA à votre zone hébergée, vous devez spécifier trois paramètres séparés par des espaces :

`flags tag "value"`

Notez ce qui suit à propos du format des enregistrements CAA :
+ La valeur de `tag` peut uniquement contenir les caractères A-Z, a-z et 0-9.
+ Veillez à toujours placer `value` entre guillemets ("").
+ Certains CAs autorisent ou exigent des valeurs supplémentaires pour`value`. Spécifiez les valeurs supplémentaires en tant que paires nom-valeur, en les séparant par des points-virgules (;), par exemple :

  `0 issue "ca.example.net; account=123456"`
+ Si une autorité de certification reçoit une demande de certificat pour un sous-domaine (par exemple, www.example.com) et s'il n'existe aucun enregistrement CAA pour le sous-domaine, l'autorité de certification soumet une requête DNS portant sur un enregistrement CAA pour le domaine parent (comme example.com). S'il existe un enregistrement pour le domaine parent et si la demande de certificat est valide, l'autorité de certification émet le certificat pour le sous-domaine.
+ Nous vous invitons à vous renseigner auprès de votre autorité de certification pour savoir quelles valeurs spécifier pour un enregistrement CAA.
+ Vous ne pouvez pas créer un enregistrement CAA et un enregistrement CNAME ayant le même nom, car DNS ne permet pas d'utiliser le même nom pour un enregistrement CNAME et pour tout autre type d'enregistrement.

**Topics**
+ [Autoriser une autorité de certification à émettre un certificat pour un domaine ou un sous-domaine](#CAAFormat-issue)
+ [Autoriser une autorité de certification à émettre un certificat générique pour un domaine ou un sous-domaine](#CAAFormat-issue-wild)
+ [Empêcher toute autorité de certification d'émettre un certificat pour un domaine ou sous-domaine](#CAAFormat-prevent-issue)
+ [Demander à n'importe quelle autorité de certification de vous contacter si elle reçoit une demande de certificat non valide](#CAAFormat-contact)
+ [Utiliser un autre paramètre pris en charge par l'autorité de certification](#CAAFormat-custom-setting)
+ [Exemples](#CAAFormat-examples)

### Autoriser une autorité de certification à émettre un certificat pour un domaine ou un sous-domaine
<a name="CAAFormat-issue"></a>

Pour autoriser une autorité de certification à émettre un certificat pour un domaine ou un sous-domaine, créez un enregistrement portant le même nom que le domaine ou sous-domaine, et spécifiez les paramètres suivants :
+ **flags (indicateurs)** – `0`
+ **étiquette** — `issue`
+ **value (valeur)** – le code de l'autorité de certification que vous autorisez à émettre un certificat pour le domaine ou sous-domaine

Par exemple, supposons que vous voulez autoriser ca.example.net pour émettre un certificat pour exemple.com. Vous allez créer un enregistrement CAA pour exemple.com avec les paramètres suivants :

```
0 issue "ca.example.net"
```

Pour plus d'informations sur la façon AWS Certificate Manager d'autoriser l'émission d'un certificat, voir [Configurer un enregistrement CAA](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) dans le *guide de AWS Certificate Manager l'utilisateur*.

### Autoriser une autorité de certification à émettre un certificat générique pour un domaine ou un sous-domaine
<a name="CAAFormat-issue-wild"></a>

Pour autoriser une autorité de certification à émettre un certificat générique pour un domaine ou un sous-domaine, créez un enregistrement portant le même nom que le domaine ou sous-domaine, et spécifiez les paramètres suivants. Un certificat générique s'applique au domaine ou sous-domaine et à tous ses sous-domaines.
+ **flags (indicateurs)** – `0`
+ **étiquette** — `issuewild`
+ **value (valeur)** – le code de l'autorité de certification que vous autorisez à émettre un certificat pour le domaine ou le sous-domaine et ses sous-domaines

Par exemple, supposons que vous voulez autoriser ca.example.net à émettre un certificat générique pour example.com, qui s'applique à example.com et à l'ensemble de ses sous-domaines. Vous allez créer un enregistrement CAA pour exemple.com avec les paramètres suivants :

```
0 issuewild "ca.example.net"
```

Si vous souhaitez autoriser une autorité de certification à émettre un certificat générique pour un domaine ou un sous-domaine, créez un enregistrement portant le même nom que le domaine ou sous-domaine, et spécifiez les paramètres suivants. Un certificat générique s'applique au domaine ou sous-domaine et à tous ses sous-domaines.

### Empêcher toute autorité de certification d'émettre un certificat pour un domaine ou sous-domaine
<a name="CAAFormat-prevent-issue"></a>

Pour empêcher une autorité de certification d'émettre un certificat générique pour un domaine ou un sous-domaine, créez un enregistrement portant le même nom que le domaine ou sous-domaine, et spécifiez les paramètres suivants :
+ **flags (indicateurs)** – `0`
+ **étiquette** — `issue`
+ **valeur** – `";"`

Par exemple, supposons que vous ne voulez qu'aucune autorité de certification n'émette de certificat pour example.com. Vous allez créer un enregistrement CAA pour exemple.com avec les paramètres suivants :

`0 issue ";"`

Si vous ne voulez pas qu'une autorité de certification émette de certificat pour example.com ou ses sous-domaines, vous devez créer un enregistrement CAA pour example.com avec les paramètres suivants : 

`0 issuewild ";"`

**Note**  
Si vous créez un enregistrement CAA pour example.com et spécifiez les deux valeurs suivantes, une autorité de certification qui utilise la valeur ca.example.net peut émettre le certificat pour example.com :  

```
0 issue ";"
0 issue "ca.example.net"
```

### Demander à n'importe quelle autorité de certification de vous contacter si elle reçoit une demande de certificat non valide
<a name="CAAFormat-contact"></a>

Si vous souhaitez qu'une autorité de certification vous contacte si elle reçoit une demande de certificat non valide, spécifiez les paramètres suivants :
+ **flags (indicateurs)** – `0`
+ **étiquette** — `iodef`
+ **value (valeur)** – l'URL ou l'adresse e-mail que vous souhaitez que l'autorité de certification contacte si elle reçoit une requête non valide demandant un certificat. Utilisez le format applicable :

  `"mailto:email-address"`

  `"http://URL"`

  `"https://URL"`

Par exemple, si vous voulez que toute autorité de certification qui reçoit une demande de certificat non valide envoie un e-mail à admin@example.com, vous devez créer un enregistrement CAA avec les paramètres suivants :

```
0 iodef "mailto:admin@example.com"
```

### Utiliser un autre paramètre pris en charge par l'autorité de certification
<a name="CAAFormat-custom-setting"></a>

Si votre autorité de certification prend en charge une fonctionnalité qui n'est pas définie dans la spécification RFC pour les enregistrements CAA, spécifiez les paramètres suivants :
+ **flags (indicateurs)** – 128 (cette valeur empêche l'autorité de certification d'émettre un certificat si celle-ci ne prend pas en charge la fonction spécifiée.)
+ **tag (balise)** – la balise que vous autorisez l'autorité de certification à utiliser
+ **value (valeur)** – la valeur qui correspond à la valeur de tag

Par exemple, supposons que votre autorité de certification envoie un SMS si elle reçoit une demande de certificat non valide. (Nous n'en connaissons aucun CAs qui supporte cette option.) Les paramètres de l'enregistrement peuvent prendre la forme suivante :

```
128 exampletag "15555551212"
```

### Exemples
<a name="CAAFormat-examples"></a>

**Exemple pour la console Route 53**

```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```

**Exemple pour l'API Route 53**

```
<ResourceRecord>
   <Value>0 issue "ca.example.net"</Value>
   <Value>0 iodef "mailto:admin@example.com"</Value>
</ResourceRecord>
```

## Type d'enregistrement CNAME
<a name="CNAMEFormat"></a>

Un enregistrement CNAME mappe les requêtes DNS pour le nom de l'enregistrement actuel, comme acme.example.com, à un autre domaine (example.com ou example.net) ou sous-domaine (acme.example.com ou zenith.example.org). 

**Important**  
Le protocole DNS ne permet pas de créer un enregistrement CNAME pour le nœud supérieur d'un espace de nom DNS, également dénommé zone apex. Par exemple, si vous enregistrez le nom DNS example.com, la zone apex est example.com. Vous ne pouvez pas créer un enregistrement CNAME pour example.com, mais vous pouvez créer des enregistrements CNAME pour www.example.com, newproduct.example.com, etc.  
En outre, si vous créez un enregistrement CNAME pour un sous-domaine, vous ne pouvez pas créer d'autres enregistrements pour ce sous-domaine. Par exemple, si vous créez un enregistrement CNAME pour www.example.com, vous ne pouvez pas créer d'autres enregistrements dont la valeur du champ **Name (nom)** est www.example.com.

Amazon Route 53 prend également en charge les enregistrements d'alias, qui vous permettent d'acheminer les requêtes vers AWS des ressources sélectionnées, telles que CloudFront les distributions et les compartiments Amazon S3. Les alias sont relativement similaires au type d'enregistrement CNAME. Cependant, vous pouvez créer un alias pour la zone apex. Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Exemple pour la console Route 53**

```
hostname.example.com
```

**Exemple pour l'API Route 53**

```
<Value>hostname.example.com</Value>
```

## Type d'enregistrement DS
<a name="DSFormat"></a>

Un enregistrement de signataire de délégation (DS) fait référence à une clé de zone pour une zone de sous-domaine déléguée. Vous pouvez créer un enregistrement DS lorsque vous établissez une chaîne d'approbation lorsque vous configurez la signature DNSSEC. Pour plus d'informations sur la configuration DNSSEC dans Route 53, consultez [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md).

Les trois premières valeurs sont des nombres décimaux représentant la balise clé, l'algorithme et le type de prétraitement. La quatrième valeur est le prétraitement de la clé de zone. Pour plus de détails sur le format d'enregistrement DS, consultez la spécification [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt).

**Exemple pour la console Route 53**

```
123 4 5 1234567890abcdef1234567890absdef
```

**Exemple pour l'API Route 53**

```
<Value>123 4 5 1234567890abcdef1234567890absdef</Value>
```

## Type d'enregistrement HTTPS
<a name="HTTPSFormat"></a>

Un enregistrement de ressource HTTPS est une forme d'enregistrement DNS SVCB (Service Binding) qui fournit des informations de configuration étendues, permettant à un client de se connecter facilement et en toute sécurité à un service via un protocole HTTP. Les informations de configuration sont fournies dans des paramètres qui permettent la connexion en une seule requête DNS, plutôt que de nécessiter plusieurs requêtes DNS. 

Le format d'un enregistrement de ressource HTTPS est le suivant :

`SvcPriority TargetName SvcParams(optional)`

Les paramètres suivants sont décrits dans la [RFC 9460, section 9.1](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1).

**SvcPriority**  
Un entier qui représente la priorité. La priorité 0 signifie le mode alias et est généralement destiné à l'alias au sommet de la zone. Cette valeur est un entier compris entre 0 et 32767 pour Route 53, dont 1 à 32767 sont des enregistrements en mode service. Plus la priorité est faible, plus la préférence est élevée. 

**TargetName**  
Le nom de domaine de l'alias cible (pour le mode alias) ou du point de terminaison alternatif (pourServiceMode).

**SvcParams (facultatif)**  
 Une liste séparée par des espaces, chaque paramètre étant constitué d'une paire Key=Value ou d'une clé autonome. S'il existe plusieurs valeurs, elles sont présentées sous forme de liste séparée par des virgules. Les éléments suivants sont définis SvcParams :  
+ `1:alpn`— Protocole de négociation du protocole de couche application IDs. La valeur par défaut est HTTP/1.1, `h2` HTTP/2 sur TLS et `h3` HTTP/3 (protocole HTTP sur QUIC). 
+ `2:no-default-alpn`— La valeur par défaut n'est pas prise en charge et vous devez fournir un `alpn` paramètre.
+ `3:port`— le point de terminaison alternatif ou le port où le service peut être atteint. 
+ `4:ipv4hint`— indications IPv4 d'adresse.
+ `5:ech`— Client crypté Bonjour.
+ `6:ipv6hint`— indications IPv6 d'adresse.
+ `7:dohpath`— Modèle DNS sur HTTPS
+ `8:ohttp`— Le service utilise une cible HTTP Oblivious

**Exemple pour la console Amazon Route 53 en mode alias**

```
0 example.com
```

**Exemple pour la console Amazon Route 53 en mode service**

```
16 example.com alpn="h2,h3" port=808
```

**Exemple d'API Amazon Route 53 pour le mode alias**

```
<Value>0 example.com</Value>
```

**Exemple d'API Route 53 pour le mode service**

```
<Value>16 example.com alpn="h2,h3" port=808</Value>
```

Pour plus d'informations, consultez la [RFC 9460, Liaison de service et spécification des paramètres via le DNS (enregistrements de ressources SVCB et HTTPS](https://datatracker.ietf.org/doc/html/rfc9460)).

**Note**  
Route 53 ne prend pas en charge le format de présentation arbitraire à clé inconnue `keyNNNNN`

## Type d'enregistrement MX
<a name="MXFormat"></a>

Un enregistrement MX spécifie les noms de vos serveurs de messagerie et, si vous disposez de plusieurs serveurs de messagerie, l'ordre de priorité. Chaque valeur d'un enregistrement MX contient deux valeurs, la priorité et le nom de domaine.

**Priorité**  
Un nombre entier qui représente la priorité pour un serveur de messagerie. Si vous ne spécifiez qu'un seul serveur, la priorité peut être n'importe quel nombre entier compris entre 0 et 65 535. Si vous spécifiez plusieurs serveurs, la valeur que vous spécifiez pour la priorité indique vers quel serveur de messagerie vous voulez que les e-mails soient acheminés en premier, en deuxième, et ainsi de suite. Le serveur avec la valeur de priorité la plus basse est prioritaire. Par exemple, si vous avez deux serveurs de messagerie et que vous spécifiez les valeurs de priorité 10 et 20, les e-mails vont toujours vers le serveur qui a la priorité 10, sauf s'il n'est pas disponible. Si vous spécifiez les valeurs 10 et 10, les e-mails sont acheminés vers les deux serveurs de façon relativement équitable.

**Nom de domaine**  
Le nom de domaine du serveur de messagerie. Spécifiez le nom (par exemple mail.example.com) d'un enregistrement A ou AAAA. Dans [RFC 2181, Clarifications to the DNS Specification](https://tools.ietf.org/html/rfc2181), la section 10.3 interdit de spécifier le nom d'un enregistrement CNAME pour la valeur du nom de domaine. (Lorsque le RFC indique « alias », cela indique un enregistrement CNAME, et non un enregistrement d'alias Route 53.)

**Exemple pour la console Amazon Route 53**

```
10 mail.example.com
```

**Exemple pour l'API Route 53**

```
<Value>10 mail.example.com</Value>
```

## Type d'enregistrement NAPTR
<a name="NAPTRFormat"></a>

Un pointeur d'autorité de nom (NAPTR) est un type d'enregistrement qui est utilisé par les applications DDDS (Dynamic Delegation Discovery System) pour convertir une valeur en une autre ou remplacer une valeur par une autre. Par exemple, une utilisation courante consiste à convertir des numéros de téléphone en SIP URIs. 

L'élément `Value` d'un enregistrement NAPTR se compose de six valeurs séparées par des espaces :

**Ordre**  
Lorsque vous spécifiez plusieurs enregistrements, l'ordre dans lequel vous souhaitez que l'application DDDS évalue les enregistrements. Valeurs valides : 0 - 65535.

**Préférence**  
Lorsque vous spécifiez deux ou plusieurs enregistrements ayant le même **ordre**, votre préférence pour l'ordre dans lequel ces enregistrements sont évalués. Par exemple, si deux enregistrements ont un **ordre** de 1, l'application DDDS évalue d'abord l'enregistrement ayant la **préférence** la plus basse. Valeurs valides : 0 - 65535.

**Indicateurs**  
Paramètre spécifique aux applications DDDS. Les valeurs actuellement définies dans [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) sont les lettres **« A »**, **« P »**, **« S »** et **« U »** en majuscules et minuscules et la chaîne vide, **« »**. Placez les **indicateurs** entre guillemets. 

**Service**  
Paramètre spécifique aux applications DDDS. Placez le **service** entre guillemets.  
Pour plus d'informations, consultez le document applicable RFCs :  
+ **Application DDDS URI** — [https://tools.ietf.org/html/rfc3404](https://tools.ietf.org/html/rfc3404#section-4.4) \$1section -4.4
+ **Application DDDS S-NAPTR — /rfc3958 \$1section** [-6.5 https://tools.ietf.org/html](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **Application DDDS U-NAPTR — /rfc4848 \$1section** [-4.5 https://tools.ietf.org/html](https://tools.ietf.org/html/rfc4848#section-4.5)

**Regexp**  
Expression régulière que l'application DDDS utilise pour convertir une valeur d'entrée en une valeur de sortie. Par exemple, un système de téléphonie IP peut utiliser une expression régulière pour convertir un numéro de téléphone qui est entré par un utilisateur en une URI SIP. Placez **Regexp** entre guillemets. Spécifiez une valeur pour **Regexp** ou **Remplacement**, mais pas les deux.  
L'expression régulière peut inclure les caractères ASCII imprimables suivants :  
+ a-z
+ 0-9
+ - (trait d'union)
+ (espace)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ " (guillemet). Pour inclure un guillemet dans une chaîne, faites-le précéder par un caractère \$1 : \$1".
+ \$1 (barre oblique inverse). Pour inclure une barre oblique inverse dans une chaîne, faites-la précéder par un caractère \$1 : \$1\$1.
Spécifiez toutes les autres valeurs, telles que les noms de domaine internationaux, au format octal.  
Pour la syntaxe de **Regexp**, consultez la [RFC 3402, section 3.2, Substitution Expression Syntax](https://tools.ietf.org/html/rfc3402#section-3.2)

**Remplacement**  
Le nom de domaine complet (FQDN) du prochain nom de domaine pour lequel vous souhaitez que l'application DDDS soumettre une requête DNS. L'application DDDS remplace la valeur d'entrée par la valeur que vous spécifiez dans **Remplacement**, le cas échéant. Spécifiez une valeur pour **Regexp** ou **Remplacement**, mais pas les deux. Si vous indiquez une valeur pour **Regexp**, spécifiez un point (**.**) pour **Remplacement**.  
Le nom de domaine peut inclure a-z, 0-9 et - (tiret).

Pour plus d'informations sur les applications DDDS et sur les enregistrements NAPTR, consultez les rubriques suivantes : RFCs
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)

**Exemple pour la console Amazon Route 53**

```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```

**Exemple pour l'API Route 53**

```
<ResourceRecord>
   <Value>100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .</Value>
   <Value>100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .</Value>
   <Value>100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .</Value>
</ResourceRecord>
```

## Type d'enregistrement NS
<a name="NSFormat"></a>

Un enregistrement NS identifie les serveurs de noms de la zone hébergée. Remarques :
+ L'utilisation la plus courante d'un enregistrement NS consiste à contrôler le routage du trafic Internet pour un domaine. Pour utiliser les enregistrements d'une zone hébergée pour acheminer le trafic d'un domaine, vous mettez à jour les paramètres d'enregistrement de domaine pour utiliser les quatre serveurs de noms dans l'enregistrement NS par défaut. (Il s'agit de l'enregistrement NS portant le même nom que la zone hébergée.)
+ Vous pouvez créer une zone hébergée distincte pour un sous-domaine (acme.example.com) et utiliser cette zone hébergée pour acheminer le trafic Internet pour le sous-domaine et ses sous-domaines (subdomain.acme.example.com). Vous définissez cette configuration, qualifiée de « délégation de la responsabilité d'un sous-domaine à une zone hébergée » en créant un autre enregistrement NS dans la zone hébergée pour le domaine racine (example.com). Pour de plus amples informations, veuillez consulter [Acheminement du trafic pour les sous-domaines](dns-routing-traffic-for-subdomains.md).
+ Vous utilisez également des enregistrements NS pour configurer des serveurs de noms en marque blanche. Pour de plus amples informations, veuillez consulter [Configuration de serveurs de noms en marque blanche](white-label-name-servers.md).
+ Un enregistrement NS peut également être utilisé pour les zones hébergées privées lorsque vous créez une règle de délégation pour déléguer l'autorité d'un sous-domaine à votre résolveur local. Vous devez créer cet enregistrement NS avant de créer une règle de délégation. Pour de plus amples informations, veuillez consulter [Comment les points de terminaison Resolver transfèrent les requêtes DNS de vous VPCs vers votre réseau](resolver-overview-forward-vpc-to-network.md).

Pour plus d'informations sur les enregistrements NS, consultez la section [Registres NS et SOA créés par Amazon Route 53 pour une zone hébergée publique](SOA-NSrecords.md).

**Exemple pour la console Amazon Route 53**

```
ns-1.example.com
```

**Exemple pour l'API Route 53**

```
<Value>ns-1.example.com</Value>
```

## Type d'enregistrement PTR
<a name="PTRFormat"></a>

Un enregistrement PTR mappe une adresse IP au nom de domaine correspondant.

**Exemple pour la console Amazon Route 53**

```
hostname.example.com
```

**Exemple pour l'API Route 53**

```
<Value>hostname.example.com</Value>
```

## Type d'enregistrement SOA
<a name="SOAFormat"></a>

Un enregistrement de source de noms (SOA) fournit des informations concernant un domaine et la zone hébergée Amazon Route 53. Pour plus d'informations sur les champs d'un enregistrement SOA, consultez [Registres NS et SOA créés par Amazon Route 53 pour une zone hébergée publique](SOA-NSrecords.md).

**Exemple pour la console Route 53**

```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```

**Exemple pour l'API Route 53**

```
<Value>ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60</Value>
```

## Type d'enregistrement SPF
<a name="SPFFormat"></a>

Auparavant, les enregistrements SPF étaient utilisés pour vérifier l'identité de l'expéditeur d'e-mails. Toutefois, nous vous recommandons de ne plus créer d'enregistrements pour lesquels le type d'enregistrement est SPF. La RFC 7208, *Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, version 1,* a été mise à jour pour indiquer : «... [L] 'existence et le mécanisme définis dans [RFC4408] ont entraîné certains problèmes d'interopérabilité. Accordingly, its use is no longer appropriate for SPF version 1; implementations are not to use it. » Dans la norme RFC 7208, consultez la section 14.1 [The SPF DNS Record Type](http://tools.ietf.org/html/rfc7208#section-14.1).

Plutôt que de créer un enregistrement SPF, nous vous recommandons de créer un enregistrement TXT contenant la valeur applicable. Pour plus d'informations sur les valeurs valides, consultez l'article Wikipédia [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework).

**Exemple pour la console Amazon Route 53**

```
"v=spf1 ip4:192.168.0.1/16 -all"
```

**Exemple pour l'API Route 53**

```
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>
```

## Type d'enregistrement SRV
<a name="SRVFormat"></a>

Un élément `Value` d'un enregistrement SRV se compose de quatre valeurs séparées par des espaces. Les trois premières valeurs sont des nombres décimaux représentant la priorité, la pondération et le port. La quatrième valeur est un nom de domaine. Les enregistrements SRV sont utilisés pour accéder à des services, tels qu'un service pour le courrier électronique ou les communications. Pour plus d'informations sur le format d'enregistrement SRV, consultez la documentation du service auquel vous souhaitez vous connecter.

**Exemple pour la console Amazon Route 53**

```
10 5 80 hostname.example.com
```

**Exemple pour l'API Route 53**

```
<Value>10 5 80 hostname.example.com</Value>
```

## Type d'enregistrement SSHFP
<a name="SSHFPFormat"></a>

Un enregistrement d'empreintes digitales Secure Shell (SSHFP) identifie les clés SSH associées au nom de domaine. Les enregistrements SSHFP doivent être sécurisés par le protocole DNSSEC pour qu'une chaîne de confiance soit établie. Pour plus d'informations sur le protocole DNSSEC, voir [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md)

Le format d'un enregistrement de ressource SSHFP est le suivant :

`[Key Algorithm] [Hash Type] Fingerprint`

Les paramètres suivants sont définis dans la [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255).

**Algorithme clé**  
Type d'algorithme :  
+ `0`— Réservé et non utilisé.
+ `1: RSA`— L'algorithme Rivest-Shamir-Adleman est l'un des premiers systèmes cryptographiques à clé publique et est toujours utilisé pour la transmission sécurisée de données.
+ `2: DSA`— L'algorithme de signature numérique est une norme fédérale de traitement de l'information pour les signatures numériques. Le DSA est basé sur l'exponentiation modulaire et les modèles mathématiques du logarithme discret.
+ `3: ECDSA`— L'algorithme de signature numérique à courbe elliptique est une variante du DSA qui utilise la cryptographie à courbe elliptique.
+ `4: Ed25519`— L'algorithme Ed25519 est le schéma de signature eDDSA qui utilise SHA-512 (SHA-2) et Curve25519.
+ `6: Ed448`— Ed448 est le schéma de signature eDDSA qui utilise et Curve448. SHAKE256 

**Type de hachage**  
Algorithme utilisé pour créer le hachage de la clé publique :  
+ `0`—Réservé et non utilisé.
+ `1: SHA-1`
+ `2: SHA-256`

**Empreinte digitale**  
Représentation hexadécimale du hachage.

**Exemple pour la console Amazon Route 53**

```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```

**Exemple pour l'API Route 53**

```
<Value>1 1 09F6A01D2175742B257C6B98B7C72C44C4040683</Value>
```

Pour plus d'informations, consultez la [RFC 4255 : Utilisation du DNS pour publier en toute sécurité les empreintes clés du protocole Secure Shell (SSH).](https://datatracker.ietf.org/doc/html/rfc4255)

## Type d'enregistrement SVCB
<a name="SVCBFormat"></a>

Vous utilisez un enregistrement SVCB pour fournir des informations de configuration permettant d'accéder aux points de terminaison du service. Le SVCB est un enregistrement DNS générique qui peut être utilisé pour négocier les paramètres de divers protocoles d'application.

Le format d'un enregistrement de ressource SVCB est le suivant :

`SvcPriority TargetName SvcParams(optional)`

Les paramètres suivants sont décrits dans la [RFC 9460, section 2.3](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3).

**SvcPriority**  
Un entier qui représente la priorité. La priorité 0 signifie le mode alias et est généralement destiné à l'alias au sommet de la zone. Plus la priorité est faible, plus la préférence est élevée. 

**TargetName**  
Le nom de domaine de l'alias cible (pour le mode alias) ou du point de terminaison alternatif (pourServiceMode).

**SvcParams (facultatif)**  
 Une liste séparée par des espaces, chaque paramètre étant constitué d'une paire Key=Value ou d'une clé autonome. S'il existe plusieurs valeurs, elles sont présentées sous forme de liste séparée par des virgules. Cette valeur est un entier compris entre 0 et 32767 pour Route 53, dont 1 à 32767 sont des enregistrements en mode service. Les éléments suivants sont définis SvcParams :  
+ `1:alpn`— Protocole de négociation du protocole de couche application IDs. La valeur par défaut est HTTP/1.1, `h2` HTTP/2 sur TLS et `h3` HTTP/3 (protocole HTTP sur QUIC). 
+ `2:no-default-alpn`— La valeur par défaut n'est pas prise en charge et vous devez fournir un `alpn` paramètre.
+ `3:port`— le port de l'autre point de terminaison où le service peut être atteint. 
+ `4:ipv4hint`— indications IPv4 d'adresse.
+ `5:ech`— Client crypté Bonjour.
+ `6:ipv6hint`— indications IPv6 d'adresse.
+ `7:dohpath`— Modèle DNS sur HTTPS
+ `8:ohttp`— Le service utilise une cible HTTP Oblivious

**Exemple pour la console Amazon Route 53 en mode alias**

```
0 example.com
```

**Exemple pour la console Amazon Route 53 en mode service**

```
16 example.com alpn="h2,h3" port=808
```

**Exemple d'API Amazon Route 53 pour le mode alias**

```
<Value>0 example.com</Value>
```

**Exemple d'API Route 53 pour le mode service**

```
<Value>16 example.com alpn="h2,h3" port=808</Value>
```

Pour plus d'informations, consultez la [RFC 9460, Liaison de service et spécification des paramètres via le DNS (enregistrements de ressources SVCB et HTTPS](https://datatracker.ietf.org/doc/html/rfc9460)).

**Note**  
Route 53 ne prend pas en charge le format de présentation arbitraire à clé inconnue `keyNNNNN`

## Type d'enregistrement TLSA
<a name="TLSAFormat"></a>

Vous utilisez un enregistrement TLSA pour utiliser l'authentification des entités nommées (DANE) basée sur le DNS. Un enregistrement TLSA associe une certificate/public clé à un point de terminaison TLS (Transport Layer Security), et les clients peuvent valider la certificate/public clé à l'aide d'un enregistrement TLSA signé avec DNSSEC.

Les enregistrements TLSA ne sont fiables que si le protocole DNSSEC est activé sur votre domaine. Pour plus d'informations sur le protocole DNSSEC, voir [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md)

Le format d'un enregistrement de ressource TLSA est le suivant :

`[Certificate usage] Selector [Matching type] [Certificate association data]`

Les paramètres suivants sont spécifiés dans la [RFC 6698, section 3](https://datatracker.ietf.org/doc/html/rfc6698#section-3).

**Utilisation des certificats**  
Spécifie l'association fournie qui sera utilisée pour correspondre au certificat présenté dans le handshake TLS :  
+ 0 : contrainte CA — Le certificat ou la clé publique doit se trouver dans l'un des chemins de certification de l'infrastructure à clé publique (PKIX) pour le certificat d'entité finale fourni par le serveur dans TLS. Cette contrainte limite ce qui CAs peut être utilisé pour émettre des certificats pour un service spécifique.
+ 1 : Contrainte de certificat de service — Spécifie un certificat d'entité finale (ou la clé publique) qui doit correspondre au certificat d'entité finale fourni par le serveur dans TLS. Cette certification limite le certificat d'entité finale qui peut être utilisé par un service spécifique sur un hôte.
+ 2 : Une assertion d'ancrage de confiance — Spécifie un certificat (ou la clé publique) qui doit être utilisé comme « ancre de confiance » lors de la validation du certificat d'entité finale fourni par le serveur dans TLS. Permet à un administrateur de domaine de spécifier une ancre de confiance.
+ 3 : Certification délivrée par le domaine — Spécifie un certificat (ou la clé publique) qui doit correspondre au certificat d'entité finale fourni par le serveur dans TLS. Cette certification permet à un administrateur de domaine d'émettre des certificats pour un domaine sans faire appel à une autorité de certification tierce. Ce certificat n'a pas besoin de passer la validation PKIX.

**Selector**  
Spécifie la partie du certificat présentée par le serveur lors de la poignée de main qui correspond à la valeur de l'association :  
+ 0 : L'intégralité du certificat doit correspondre.
+ 1 : La clé publique du sujet, ou la structure binaire codée DER, doit correspondre.

**Type correspondant**  
Spécifie la présentation (telle que déterminée par le champ de sélection) du certificat correspondant :  
+ 0 : Correspondance exacte du contenu.
+ 1 : hachage SHA-256.
+ 2 : hachage SHA-512.

**Données d'association de certificats**  
Les données à comparer en fonction des paramètres des autres champs.

**Exemple pour la console Amazon Route 53**

```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```

**Exemple pour l'API Route 53**

```
<Value>0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971</Value>
```

Pour plus d'informations, consultez la [RFC 6698, Protocole de sécurité de la couche de transport (TLS) basé sur le DNS pour l'authentification des entités nommées (DANE)](https://datatracker.ietf.org/doc/html/rfc6698) : TLSA.

## Type d'enregistrement TXT
<a name="TXTFormat"></a>

Un enregistrement TXT contient une ou plusieurs chaînes entre guillemets doubles (`"`). Lorsque vous utilisez la [stratégie de routage](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) simple, incluez toutes les valeurs d'un domaine (example.com) ou d'un sous-domaine (www.example.com) dans le même enregistrement TXT.

**Topics**
+ [Saisie des valeurs d'enregistrement TXT](#TXTformat-limits)
+ [Caractères spéciaux dans une valeur d'enregistrement TXT](#TXTformat-special-characters)
+ [Majuscules et minuscules dans une valeur d'enregistrement TXT](#TXTformat-case)
+ [Exemples](#TXTformat-examples)

### Saisie des valeurs d'enregistrement TXT
<a name="TXTformat-limits"></a>

Une seule chaîne peut contenir jusqu'à 255 caractères des types suivants :
+ a-z
+ A-Z
+ 0-9
+ Espace
+ - (trait d’union)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 . 

Si vous devez entrer une valeur supérieure à 255 caractères, divisez-la en chaînes de 255 caractères ou moins et placez chaque chaîne entre guillemets doubles (`"`). Dans la console, listez toutes les chaînes sur la même ligne :

```
"String 1" "String 2" "String 3"
```

Pour l'API, incluez toutes les chaînes dans le même élément `Value` :

```
<Value>"String 1" "String 2" "String 3"</Value>
```

La longueur maximale d'une valeur dans un enregistrement TXT est de 4 000 caractères. 

Pour entrer plusieurs valeurs TXT, entrez une valeur par ligne.

### Caractères spéciaux dans une valeur d'enregistrement TXT
<a name="TXTformat-special-characters"></a>

Si votre enregistrement TXT contient l'un des caractères suivants, vous devez spécifier les caractères en utilisant des codes d'échappement au format `\` *three-digit octal code* :
+ Caractères 000 à 040 octal (0 à 32 décimal, 0x00 à 0x20 hexadécimal)
+ Caractères 177 à 377 octal (127 à 255 décimal, 0x7F à 0xFF hexadécimal)

Par exemple, si la valeur de votre enregistrement TXT est `"exämple.com"`, vous devez spécifier `"ex\344mple.com"`.

Pour établir un mappage entre les caractères ASCII et les codes octaux, effectuez une recherche sur Internet pour trouver des « codes octaux ASCII ». La référence [ASCII Code - The extended ASCII table](https://www.ascii-code.com/) peut vous être utile. 

Pour inclure un guillemet (`"`) dans une chaîne, placez une barre oblique inversée (`\`) avant le guillemet : `\"`. 

### Majuscules et minuscules dans une valeur d'enregistrement TXT
<a name="TXTformat-case"></a>

La casse étant conservée, `"Ab"` et `"aB"` sont des valeurs différentes.

### Exemples
<a name="TXTformat-examples"></a>

**Exemple pour la console Amazon Route 53**

Placez chaque valeur sur une ligne distincte :

```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```

**Exemple pour l'API Route 53**

Placez chaque valeur dans un élément `Value` distinct :

```
<Value>"This string includes \"quotation marks\"."</Value>
<Value>"The last character in this string is an accented e specified in octal format: \351"</Value>
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>
```

# Création d'enregistrements à l'aide de la console Amazon Route 53
<a name="resource-record-sets-creating"></a>

La procédure suivante explique comment créer des enregistrements à l'aide de la console Amazon Route 53. Pour plus d'informations sur la création d'enregistrements à l'aide de l'API Route 53, consultez [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)le manuel *Amazon Route 53 API Reference*.

**Note**  
Pour créer des enregistrements pour des configurations de routage complexes, vous pouvez également utiliser l'éditeur visuel Traffic Flow et enregistrer la configuration en tant que politique de trafic. Vous pouvez ensuite associer la stratégie de trafic à un ou plusieurs noms de domaine (par exemple, example.com) ou noms de sous-domaine (par exemple, www.example.com), dans la même zone hébergée ou dans plusieurs zones hébergées. En outre, vous pouvez restaurer les mises à jour si la nouvelle configuration ne fonctionne pas comme vous l'aviez prévu. Pour de plus amples informations, veuillez consulter [Utiliser Traffic Flow pour acheminer le trafic DNS](traffic-flow.md).<a name="resource-record-sets-creating-procedure"></a>

**Pour créer un enregistrement à l'aide de la console Route 53**

1. Si vous ne créez pas d'enregistrement d'alias, passez à l'étape 2. 

   Passez également à l'étape 2 si vous créez un enregistrement d'alias qui achemine le trafic DNS vers une AWS ressource autre qu'un équilibreur de charge Elastic Load Balancing ou un autre enregistrement Route 53.

   Si vous créez un enregistrement d'alias qui achemine le trafic vers un équilibreur de charge Elastic Load Balancing, et si vous avez créé votre zone hébergée et votre équilibreur de charge à l'aide de différents comptes, exécutez la procédure [Obtention du nom DNS d'un équilibreur de charge Elastic Load Balancing](#resource-record-sets-elb-dns-name-procedure) pour obtenir le nom DNS de l'équilibreur de charge. 

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Si vous disposez déjà d'une zone hébergée pour votre domaine, passez à l'étape 5. Si ce n'est pas le cas, exécutez la procédure applicable pour créer une zone hébergée :
   + Pour acheminer le trafic Internet vers vos ressources, telles que des compartiments Amazon S3 ou des instances Amazon EC2, consultez [Création d'une zone hébergée publique](CreatingHostedZone.md).
   + Pour acheminer le trafic dans votre VPC, consultez [Création d'une zone hébergée privée](hosted-zone-private-creating.md).

1. Sur la page **Hosted zones (Zones hébergées)**, choisissez le nom de la zone hébergée dans laquelle vous voulez créer des enregistrements.

1. Choisissez **Créer un registre**.

1. Choisissez et définissez la stratégie de routage et les valeurs applicables. Pour plus d'informations, consultez la rubrique pour le type d'enregistrement que vous souhaitez créer :
   + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
   + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)
   + [Valeurs spécifiques aux enregistrements simples](resource-record-sets-values-basic.md)
   + [Valeurs spécifiques aux enregistrements d'alias simples](resource-record-sets-values-alias.md)
   + [Valeurs spécifiques aux enregistrements de basculement](resource-record-sets-values-failover.md)
   + [Valeurs spécifiques aux enregistrements d'alias de basculement](resource-record-sets-values-failover-alias.md)
   + [Valeurs spécifiques aux enregistrements de géolocalisation](resource-record-sets-values-geo.md)
   + [Valeurs spécifiques aux enregistrements d'alias de géolocalisation](resource-record-sets-values-geo-alias.md)
   + [Valeurs spécifiques aux enregistrements de géoproximité](resource-record-sets-values-geoprox.md)
   + [Valeurs spécifiques aux enregistrements d'alias de géoproximité](resource-record-sets-values-geoprox-alias.md)
   + [Valeurs spécifiques aux enregistrements de latence](resource-record-sets-values-latency.md)
   + [Valeurs spécifiques aux enregistrements d'alias de latence](resource-record-sets-values-latency-alias.md)
   + [Valeurs spécifiques aux enregistrements basés sur IP](resource-record-sets-values-ipbased.md)
   + [Valeurs spécifiques aux enregistrements d'alias basés sur IP](resource-record-sets-values-ipbased-alias.md)
   + [Valeurs spécifiques pour les enregistrements de réponses multivaleur](resource-record-sets-values-multivalue.md)
   + [Valeurs spécifiques aux enregistrements pondérés](resource-record-sets-values-weighted.md)
   + [Valeurs spécifiques aux enregistrements d'alias pondérés](resource-record-sets-values-weighted-alias.md)

1. Choisissez **Créer des enregistrements**.
**Note**  
La propagation de vos nouveaux registres sur les serveurs DNS Route 53 prend un certain temps. À l'heure actuelle, le seul moyen de vérifier que les modifications se sont propagées consiste à utiliser l'action [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Les changements se propagent généralement sur tous les serveurs de Route 53 en 60 secondes.

1. Si vous créez plusieurs enregistrements, répétez les étapes 7 à 8.<a name="resource-record-sets-elb-dns-name-procedure"></a>

**Obtention du nom DNS d'un équilibreur de charge Elastic Load Balancing**

1. Connectez-vous à l' AWS Management Console aide du AWS compte qui a été utilisé pour créer le Classic, l'Application ou le Network Load Balancer pour lequel vous souhaitez créer un enregistrement d'alias.

1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Dans le volet de navigation, choisissez **Load Balancers**.

1. Dans la liste des équilibreurs de charge, sélectionnez celui pour lequel vous souhaitez créer un enregistrement d'alias.

1. Dans l'onglet **Description**, obtenez la valeur de **DNS name**.

1. Si vous souhaitez créer des enregistrements d'alias pour d'autres équilibreurs de charge Elastic Load Balancing, répétez les étapes 4 et 5. 

1. Déconnectez-vous du AWS Management Console.

1. Connectez-vous à AWS Management Console nouveau à l'aide du AWS compte que vous avez utilisé pour créer la zone hébergée Route 53.

1. Revenez à l'étape 3 de la procédure [Création d'enregistrements à l'aide de la console Amazon Route 53](#resource-record-sets-creating).

# Autorisations relatives aux ensembles d'enregistrements
<a name="resource-record-sets-permissions"></a>

Les autorisations relatives aux ensembles d'enregistrements de ressources utilisent les conditions de politique de gestion des identités et des accès (IAM) pour vous permettre de définir des autorisations granulaires pour les actions sur la console Route 53 ou pour l'utilisation de l'[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API.

Un ensembles d'enregistrements de ressources est défini comme plusieurs enregistrements de ressources portant le même nom et le même type (et la même classe, mais dans la plupart des cas, la classe est toujours IN ou Internet), cependant ils contiennent des données différentes. Par exemple, si vous choisissez le routage de géolocalisation, vous pouvez avoir plusieurs enregistrements A ou AAAA pointant vers différents points de terminaison pour le même domaine. Tous ces enregistrements A ou AAAA se combinent pour former un ensemble d'enregistrements de ressources. Pour plus d'informations sur la terminologie DNS, consultez [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719).

Avec les conditions de la politique IAM,, `route53:ChangeResourceRecordSetsNormalizedRecordNames``route53:ChangeResourceRecordSetsRecordTypes`, et`route53:ChangeResourceRecordSetsActions`, vous pouvez accorder des droits administratifs granulaires à d'autres AWS utilisateurs sur n'importe quel autre AWS compte. Cela vous permet d'accorder à quelqu'un les autorisations nécessaires pour :
+ un ensemble d'enregistrements de ressource unique ;
+ tous les ensembles d'enregistrements de ressources d'un type d'enregistrement DNS spécifique ;
+ des ensembles d'enregistrements de ressources dont les noms contiennent une chaîne spécifique.
+ Effectuez une ou toutes les `CREATE | UPSERT | DELETE ` actions lorsque vous utilisez l'[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API ou la console Route 53.

Vous pouvez également créer des autorisations d'accès qui combinent toutes les conditions de politique de Route 53. Par exemple, vous pouvez accorder à quelqu'un l'autorisation de modifier les données de l'enregistrement A pour marketing-example.com, mais ne pas autoriser cet utilisateur à supprimer des enregistrements. 

Pour plus d'informations sur les autorisations relatives aux ensembles d'enregistrements de ressources et pour des exemples de leur utilisation, consultez[Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions-route53.md).

Pour savoir comment authentifier AWS les utilisateurs, consultez [Authentification par des identités](security-iam.md#security_iam_authentication) et pour savoir comment contrôler l'accès aux ressources Route 53, voir[Contrôle d’accès](security-iam.md#access-control).

# Valeurs à spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53
<a name="resource-record-sets-values"></a>

Lorsque vous créez des enregistrements à l'aide de la console Amazon Route 53, les valeurs que vous spécifiez dépendent de la politique de routage que vous souhaitez utiliser et du fait que vous créez ou non des enregistrements d'alias, qui acheminent le trafic vers les AWS ressources.

Enregistrements d'alias qui acheminent le trafic vers certaines AWS ressources pour lesquelles vous spécifiez la ressource cible (par exemple, Elastic Load Balancing, CloudFront distribution, compartiment Amazon S3). Vous pouvez également éventuellement associer des contrôles de santé et configurer une évaluation de l'état cible. Les rubriques suivantes fournissent des informations détaillées sur les valeurs requises pour chaque politique de routage et chaque type d'enregistrement, afin de vous aider à configurer efficacement vos enregistrements Route 53.

**Topics**
+ [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md)
+ [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md)
+ [Valeurs spécifiques aux enregistrements simples](resource-record-sets-values-basic.md)
+ [Valeurs spécifiques aux enregistrements d'alias simples](resource-record-sets-values-alias.md)
+ [Valeurs spécifiques aux enregistrements de basculement](resource-record-sets-values-failover.md)
+ [Valeurs spécifiques aux enregistrements d'alias de basculement](resource-record-sets-values-failover-alias.md)
+ [Valeurs spécifiques aux enregistrements de géolocalisation](resource-record-sets-values-geo.md)
+ [Valeurs spécifiques aux enregistrements d'alias de géolocalisation](resource-record-sets-values-geo-alias.md)
+ [Valeurs spécifiques aux enregistrements de géoproximité](resource-record-sets-values-geoprox.md)
+ [Valeurs spécifiques aux enregistrements d'alias de géoproximité](resource-record-sets-values-geoprox-alias.md)
+ [Valeurs spécifiques aux enregistrements de latence](resource-record-sets-values-latency.md)
+ [Valeurs spécifiques aux enregistrements d'alias de latence](resource-record-sets-values-latency-alias.md)
+ [Valeurs spécifiques aux enregistrements basés sur IP](resource-record-sets-values-ipbased.md)
+ [Valeurs spécifiques aux enregistrements d'alias basés sur IP](resource-record-sets-values-ipbased-alias.md)
+ [Valeurs spécifiques pour les enregistrements de réponses multivaleur](resource-record-sets-values-multivalue.md)
+ [Valeurs spécifiques aux enregistrements pondérés](resource-record-sets-values-weighted.md)
+ [Valeurs spécifiques aux enregistrements d'alias pondérés](resource-record-sets-values-weighted-alias.md)

# Valeurs communes à toutes les politiques de routage
<a name="resource-record-sets-values-shared"></a>

Ce sont les valeurs communes que vous pouvez spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53. Ces valeurs sont utilisées par toutes les politiques de routage.



**Topics**
+ [Nom de l’enregistrement](#rrsets-values-common-name)
+ [Valeur/acheminer le trafic vers](#rrsets-values-common-value)
+ [TTL (secondes)](#rrsets-values-common-ttl)

## Nom de l’enregistrement
<a name="rrsets-values-common-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

**Enregistrements CNAME**  
Si vous créez un enregistrement dont la valeur est **CNAME** pour **Record type (Type d'enregistrement)**, le nom de l'enregistrement ne peut être identique à celui de la zone hébergée.

**Caractères spéciaux**  
Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

**Caractères génériques**  
Vous pouvez utiliser un astérisque (\$1) dans le nom. DNS traite le caractère \$1 comme un caractère générique ou comme le caractère \$1 (ASCII 42), en fonction de son emplacement dans le nom. Pour de plus amples informations, veuillez consulter [Utilisation d'un astérisque (\$1) dans les noms des zones hébergées et des enregistrements](DomainNameFormat.md#domain-name-format-asterisk).  
Vous ne pouvez pas utiliser le caractère générique \$1 pour les jeux d'enregistrements de ressources de type **NS**.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-common-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

**A — IPv4 adresse**  
Adresse IP au IPv4 format **192.0.2.235**, par exemple.

**AAAA — adresse IPv6 **  
Une adresse IP au IPv6 format, par exemple, **2001:0 db 8:85 a 3:0:0:8 a2e : 0370:7334**.

**CAA — Autorisation de l'autorité de certification**  
Trois valeurs séparées par un espace qui contrôlent les autorités de certification qui sont autorisées à émettre des certificats ou des certificats génériques pour le domaine ou le sous-domaine spécifié par **Record name (Nom de l'enregistrement)**. Vous pouvez utiliser des enregistrements CAA pour spécifier ce qui suit :  
+ Quelles autorités de certification (CAs) peuvent délivrer SSL/TLS des certificats, le cas échéant
+ L'adresse e-mail ou l'URL à contacter quand une autorité de certification émet un certificat pour le domaine ou le sous-domaine

**CNAME — Nom canonique**  
Nom de domaine complet (par exemple, *www.exemple.com*) que Route 53 doit renvoyer en réponse à des requêtes DNS pour cet enregistrement. Un point final est facultatif. Route 53 part du principe que le nom de domaine est complet. Cela signifie que Route 53 traite *www.example.com* (sans point final) et *www.example.com.* (avec un point final) de la même façon.

**MX — Échange de courrier**  
Priorité et nom de domaine spécifiant un serveur de messagerie, par exemple, **10 mailserver.example.com**. Le point final est traité comme facultatif.

**NAPTR — Pointeur d'autorité de nom**  
Six paramètres séparés par des espaces utilisés par les applications DDDS (Dynamic Delegation Discovery System) pour convertir une valeur en une autre valeur ou pour remplacer une valeur par une autre. Pour de plus amples informations, veuillez consulter [Type d'enregistrement NAPTR](ResourceRecordTypes.md#NAPTRFormat).

**PTR — Pointeur**  
Nom de domaine que vous voulez que Route 53 renvoie.

**NS — Serveur de noms**  
Nom de domaine d'un serveur de noms, par exemple, **ns1.example.com**.  
Vous ne pouvez spécifier un enregistrement NS qu'avec une politique de routage simple.

**SPF — Sender Policy Framework**  
Enregistrement SPF entre guillemets, par exemple, **"v=spf1 ip4:192.168.0.1/16-all"**. Les enregistrements SPF ne sont pas recommandés. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

**SRV — Localisateur de service**  
Enregistrement SRV. Les enregistrements SRV sont utilisés pour accéder à des services, tels qu'un service pour le courrier électronique ou les communications. Pour plus d'informations sur le format d'enregistrement SRV, consultez la documentation du service auquel vous souhaitez vous connecter. Le point final est traité comme facultatif.  
Le format d'un enregistrement SRV est :  
**[priorité] [poids] [port] [nom d'hôte serveur]**  
Par exemple :  
**1 10 5269 xmpp-server.example.com.**

**TXT — Texte**  
Enregistrement de type texte. Placez le texte entre guillemets, par exemple, **"Exemple d'entrée de texte"**. 

## TTL (secondes)
<a name="rrsets-values-common-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

# Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage
<a name="resource-record-sets-values-alias-common"></a>

Ce sont les valeurs d'alias communes que vous pouvez spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53. Ces valeurs sont utilisées par toutes les politiques de routage.

**Topics**
+ [Nom de l’enregistrement](#rrsets-values-common-alias-name)
+ [Évaluer/acheminer le trafic vers](#rrsets-values-alias-common-target)

## Nom de l’enregistrement
<a name="rrsets-values-common-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

**Enregistrements CNAME**  
Si vous créez un enregistrement dont la valeur est **CNAME** pour **Type**, le nom de l'enregistrement ne peut être identique à celui de la zone hébergée.

**Alias des CloudFront distributions et des compartiments Amazon S3**  
La valeur que vous spécifiez dépend en partie de la AWS ressource vers laquelle vous acheminez le trafic :  
+ **CloudFront distribution** — Votre distribution doit inclure un autre nom de domaine correspondant au nom de l'enregistrement. Par exemple, si le nom de l'enregistrement est **acme.example.com**, votre distribution CloudFront doit inclure **acme.example.com** parmi les autres noms de domaine. Pour plus d'informations, consultez la section [Utilisation de noms de domaine alternatifs (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) dans le manuel *Amazon CloudFront Developer Guide*. 
+ **Compartiment Amazon S3** : le nom de l'enregistrement doit correspondre au nom de votre compartiment Amazon S3. Par exemple, si le nom de votre compartiment est **acme.example.com**, le nom de cet enregistrement doit également être **acme.example.com**.

  En outre, vous devez configurer le compartiment pour l'hébergement de site web. Pour de plus amples informations, veuillez consulter la section [Configurer un compartiment pour l'hébergement de sites Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*. 

**Caractères spéciaux**  
Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

**Caractères génériques**  
Vous pouvez utiliser un astérisque (\$1) dans le nom. DNS traite le caractère \$1 comme un caractère générique ou comme le caractère \$1 (ASCII 42), en fonction de son emplacement dans le nom. Pour de plus amples informations, veuillez consulter [Utilisation d'un astérisque (\$1) dans les noms des zones hébergées et des enregistrements](DomainNameFormat.md#domain-name-format-asterisk).

## Évaluer/acheminer le trafic vers
<a name="rrsets-values-alias-common-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur la configuration de Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

**Important**  
Si vous avez utilisé le même AWS compte pour créer votre zone hébergée et la ressource vers laquelle vous acheminez le trafic, et si votre ressource n'apparaît pas dans la liste des **points de terminaison**, vérifiez les points suivants :  
Vérifiez que la valeur choisie pour **Record type (Type d'enregistrement)** est prise en charge. Les valeurs prise en charge dépendent de la ressource vers laquelle vous acheminez du trafic. Par exemple, pour acheminer le trafic vers un compartiment S3, vous devez choisir **A — IPv4 address** pour le **type d'enregistrement**.
Vérifiez que le compte dispose des autorisations IAM nécessaires pour répertorier les ressources applicables. Par exemple, pour que les distributions CloudFront fassent partie de la liste **Endpoint** (Point de terminaison), le compte doit être autorisé à effectuer l'action suivante : `cloudfront:ListDistributions`.  
Pour obtenir un exemple de politique IAM, consultez [Autorisations requises pour utiliser la console Amazon Route 53](access-control-managing-permissions.md#console-required-permissions).
Si vous avez utilisé différents AWS comptes pour créer la zone hébergée et la ressource, la liste des **points de terminaison** n'affiche pas votre ressource. Consultez la documentation suivante correspondant à votre type de ressource afin de déterminer la valeur à saisir dans **Endpoint (Point de terminaison)**.

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Pour une API Gateway personnalisée régionale APIs et optimisée pour les périphériques APIs, effectuez l'une des opérations suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre API** : sélectionnez **Endpoint (Point de terminaison)** et choisissez une API dans la liste. Si vous en avez beaucoup APIs, vous pouvez saisir les premiers caractères du point de terminaison de l'API pour filtrer la liste.
**Note**  
Le nom de l'enregistrement doit correspondre à un nom de domaine personnalisé pour votre API, tel que **api.example.com**.
+ **Si vous avez utilisé des comptes différents pour créer votre zone hébergée Route 53 et votre API** : entrez le point de terminaison d'API pour l'API, par exemple **api.example.com**.

  Si vous avez utilisé un AWS compte pour créer la zone hébergée actuelle et un autre compte pour créer une API, l'API n'apparaîtra pas dans la liste des **points de terminaison** sous **API Gateway APIs**.

  Si vous avez utilisé un compte pour créer la zone hébergée actuelle et un ou plusieurs comptes différents pour créer toutes les vôtres APIs, la liste des **points de terminaison** indique qu'**aucune cible n'est disponible** sous **API Gateway APIs**. Pour de plus amples informations, veuillez consulter [Acheminer le trafic vers une API Amazon API Gateway à l'aide de votre nom de domaine](routing-to-api-gateway.md).

**CloudFront distributions**  
Pour les CloudFront distributions, effectuez l'une des opérations suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre CloudFront distribution**, choisissez **Endpoint** et choisissez une distribution dans la liste. Si vous disposez de beaucoup de distributions, vous pouvez entrer les premiers caractères du nom de domaine de votre distribution afin de filtrer la liste.

  Si votre distribution n'apparaît pas dans la liste, notez les points suivants :
  + Le nom de l'enregistrement doit correspondre à un autre nom de domaine dans votre distribution.
  + Si vous venez d'ajouter un autre nom de domaine à votre distribution, la propagation de vos modifications à tous les emplacements CloudFront périphériques peut prendre 15 minutes. Tant que les modifications ne sont pas propagées, Route 53 ne peut pas connaître le nouveau nom de domaine.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre distribution, entrez le nom de CloudFront domaine de la distribution**, par exemple **d111111abcdef8.cloudfront.net**.

  Si vous avez utilisé un AWS compte pour créer la zone hébergée actuelle et un autre compte pour créer une distribution, la distribution n'apparaîtra pas dans la liste des **points de terminaison**.

  Si vous avez utilisé un compte pour créer la zone hébergée actuelle et un ou plusieurs comptes différents pour créer toutes vos distributions, la liste **Endpoints** indique qu'**aucune cible n'est disponible** dans le cadre des **CloudFront distributions**.
N'acheminez pas les requêtes vers une CloudFront distribution qui ne s'est pas propagée à tous les emplacements périphériques, sinon vos utilisateurs ne pourront pas accéder au contenu applicable. 
Votre CloudFront distribution doit inclure un autre nom de domaine correspondant au nom de l'enregistrement. Par exemple, si le nom de l'enregistrement est **acme.exemple.com, votre CloudFront distribution doit inclure **acme.example.com**** comme l'un des noms de domaine alternatifs. Pour plus d'informations, consultez la section [Utilisation de noms de domaine alternatifs (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) dans le manuel *Amazon CloudFront Developer Guide*.  
Si la distribution IPv6 est activée, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour le **type d'enregistrement**, et l'autre avec la valeur **AAAA — IPv6 adresse**. Pour de plus amples informations, veuillez consulter [Acheminement du trafic vers une CloudFront distribution Amazon en utilisant votre nom de domaine](routing-to-cloudfront-distribution.md).

**Service App Runner**  
Pour le service App Runner, effectuez l'une des opérations suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre service App Runner**, choisissez le Région AWS, puis le nom de domaine de l'environnement vers lequel vous souhaitez acheminer le trafic dans la liste.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre App Runner**, entrez le nom de domaine personnalisé. Pour plus d'informations, consultez [Gestion des noms de domaine personnalisés pour App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html).

  Si vous avez utilisé un AWS compte pour créer la zone hébergée actuelle et un autre compte pour créer un App Runner, l'App Runner n'apparaîtra pas dans la liste des **points de terminaison**.
Pour de plus amples informations, veuillez consulter [Configuration d'Amazon Route 53 pour acheminer le trafic vers un service App Runner](routing-to-app-runner.md#routing-to-app-runner-configuring).

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si le nom de domaine de votre environnement Elastic Beanstalk inclut la région dans laquelle vous avez déployé l'environnement, vous pouvez créer un enregistrement d'alias qui achemine le trafic vers l'environnement. Par exemple, le nom de domaine `my-environment.us-west-2.elasticbeanstalk.com` est un nom de domaine régionalisé.  
Concernant les environnements qui ont été créés avant début 2016, le nom de domaine n'inclut pas la région. Pour acheminer le trafic vers ces environnements, vous devez créer un enregistrement CNAME au lieu d'un enregistrement d'alias. Notez que vous ne pouvez pas créer un enregistrement CNAME pour le nom de domaine racine. Par exemple, si votre nom de domaine est example.com, vous pouvez créer un enregistrement qui achemine le trafic pour acme.example.com vers votre environnement Elastic Beanstalk, mais vous ne pouvez pas créer d'enregistrement qui achemine le trafic pour example.com vers votre environnement Elastic Beanstalk.
Pour les environnements Elastic Beanstalk comportant des sous-domaines régionalisés, effectuez l'une des actions suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre environnement Elastic Beanstalk** : sélectionnez **Endpoint (Point de terminaison)** et choisissez un environnement dans la liste. Si vous disposez de beaucoup d'environnements, vous pouvez entrer les premiers caractères de l'attribut CNAME de l'environnement afin de filtrer la liste.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre environnement Elastic Beanstalk** : entrez l'attribut CNAME de l'environnement Elastic Beanstalk.
Pour de plus amples informations, veuillez consulter [Acheminement du trafic vers un AWS Elastic Beanstalk environnement](routing-to-beanstalk-environment.md).

**Équilibreurs de charge ELB**  
Pour les équilibreurs de charge ELB, effectuez l'une des actions suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre équilibreur de charge** : sélectionnez **Endpoint (Point de terminaison)** et choisissez un équilibreur de charge dans la liste. Si vous disposez de beaucoup d'équilibreurs de charge, vous pouvez entrer les premiers caractères du nom DNS afin de filtrer la liste.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre équilibreur de charge** : entrez la valeur que vous avez obtenue au cours de la procédure [Obtention du nom DNS d'un équilibreur de charge Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure).

  Si vous avez utilisé un AWS compte pour créer la zone hébergée actuelle et un autre compte pour créer un équilibreur de charge, l'équilibreur de charge n'apparaîtra pas dans la liste des points de **terminaison**.

  Si vous avez utilisé un compte pour créer la zone hébergée actuelle et un ou plusieurs autres comptes pour créer tous vos équilibreurs de charge, la liste **Endpoints (Points de terminaison)** affiche **No targets available (Aucune cible disponible)** sous **Elastic Load Balancers**.
La console ajoute le préfixe **dualstack.** pour l'Application et le Classic Load Balancer à partir d'un compte différent. Lorsqu'un client, tel qu'un navigateur Web, demande l'adresse IP de votre nom de domaine (exemple.com) ou de votre nom de sous-domaine (www.exemple.com), le client peut demander une IPv4 adresse (enregistrement A), une IPv6 adresse (enregistrement AAAA), ou les deux IPv4 et des IPv6 adresses (dans des demandes distinctes). La désignation **dualstack.** permet à Route 53 de répondre avec l'adresse IP appropriée pour votre équilibreur de charge en fonction du format d'adresse IP que le client a demandé.  
Pour de plus amples informations, veuillez consulter [Routage du trafic vers un équilibreur de charge ELB](routing-to-elb-load-balancer.md).

**AWS Accélérateurs Global Accelerator**  
Pour les accélérateurs AWS Global Accelerator, entrez le nom DNS de l'accélérateur. Vous pouvez saisir le nom DNS d'un accélérateur que vous avez créé à l'aide du AWS compte actuel ou d'un autre AWS compte. 

**Compartiments Amazon S3**  
Pour les compartiments Amazon S3 qui sont configurés en tant que points de terminaison de site Web, effectuez l'une des actions suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre compartiment Amazon S3** : sélectionnez **Endpoint (Point de terminaison)** et choisissez un compartiment dans la liste. Si vous disposez de beaucoup de compartiments, vous pouvez entrer les premiers caractères du nom DNS afin de filtrer la liste.

  La valeur **Endpoint (Point de terminaison)** change pour le point de terminaison du site web Amazon S3 de votre compartiment.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre compartiment Amazon S3** : saisissez le nom de la région dans laquelle vous avez créé votre compartiment S3. Utilisez la valeur applicable de la colonne **Point de terminaison des sites Web** dans le tableau [Points de terminaison des sites Web Amazon S3](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) dans le *Référence générale d'Amazon Web Services*.

  Si vous avez utilisé AWS des comptes autres que le compte actuel pour créer vos compartiments Amazon S3, le compartiment n'apparaîtra pas dans la liste des **points de terminaison**.
Vous devez configurer le compartiment pour l'hébergement de site web. Pour de plus amples informations, veuillez consulter la section [Configurer un compartiment pour l'hébergement de sites Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.  
Le nom de l'enregistrement doit correspondre au nom de votre compartiment Amazon S3. Par exemple, si le nom de votre compartiment Amazon S3 est **acme.example.com**, le nom de cet enregistrement doit également être **acme.example.com**.  
Dans un groupe d'enregistrements d'alias pondérés, d'alias de latence, d'alias de basculement ou d'alias de géolocalisation, vous ne pouvez créer qu'un seul enregistrement qui achemine les requêtes vers un compartiment Amazon S3, car le nom de l'enregistrement doit correspondre au nom du compartiment et les noms de compartiment doivent être globalement uniques.

**Amazon OpenSearch Service**  
Pour le OpenSearch service, effectuez l'une des opérations suivantes :  
+ **OpenSearch Domaine personnalisé du service** : le nom de l'enregistrement doit correspondre au domaine personnalisé. Par exemple, si le nom de votre domaine personnalisé est test.example.com, le nom de cet enregistrement doit également être test.example.com.
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre domaine de OpenSearch service**, choisissez le Région AWS, puis le nom de domaine.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre domaine de OpenSearch service**, entrez le nom de domaine personnalisé. Pour plus d'informations, voir [Création d'un point de terminaison personnalisé](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html).

  Si vous avez utilisé un AWS compte pour créer la zone hébergée actuelle et un autre compte pour créer un domaine de OpenSearch service, le domaine n'apparaîtra pas dans la liste des **points de terminaison**.

  Si vous avez utilisé un compte pour créer la zone hébergée actuelle et un ou plusieurs comptes différents pour créer tous vos domaines de OpenSearch service, la liste des **points de terminaison** indique qu'**aucune cible n'est disponible** sous **OpenSearch Service**.
Pour de plus amples informations, veuillez consulter [Configuration d'Amazon Route 53 pour acheminer le trafic vers un point de terminaison OpenSearch de domaine Amazon Service](routing-to-open-search-service.md#routing-to-open-search-service-configuring).

**Points de terminaison de l'interface d'un VPC Amazon**  
Pour les points de terminaison d'interface d'un VPC Amazon, effectuez l'une des actions suivantes :  
+ **Si vous avez utilisé le même compte pour créer votre zone hébergée Route 53 et votre point de terminaison d'interface** : sélectionnez **Endpoint (Point de terminaison)**, puis choisissez un point de terminaison d'interface dans la liste. Si vous disposez de beaucoup de points de terminaison d'interface, vous pouvez entrer les premiers caractères du nom DNS afin de filtrer la liste.
+ **Si vous avez utilisé différents comptes pour créer votre zone hébergée Route 53 et votre point de terminaison d'interface, entrez le nom d'hôte DNS du point de terminaison d'interface**, par exemple **vpce-123456789abcdef01- -1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**. example-us-east

  Si vous avez utilisé un AWS compte pour créer la zone hébergée actuelle et un autre compte pour créer un point de terminaison d'interface, le point de terminaison d'interface n'apparaîtra pas dans la liste des **points de terminaison** sous points de terminaison **VPC**.

  Si vous avez utilisé un compte pour créer la zone hébergée actuelle et un ou plusieurs autres comptes pour créer tous vos points de terminaison d'interface, la liste **Endpoint (Point de terminaison)** affiche **No targets available (Aucune cible disponible)** sous **VPC endpoints (Points de terminaison d'un VPC)**.

  Pour de plus amples informations, veuillez consulter [Acheminer le trafic vers un point de terminaison d'interface Amazon Virtual Private Cloud à l'aide de votre nom de domaine](routing-to-vpc-interface-endpoint.md).

**Enregistrements dans cette zone hébergée**  
Pour les enregistrements dans cette zone hébergée, sélectionnez **Endpoint (Point de terminaison)** et choisissez l'enregistrement applicable. Si vous disposez de beaucoup d'enregistrements, vous pouvez entrer les premiers caractères du nom afin de filtrer la liste.  
Si la zone hébergée contient uniquement les enregistrements NS et SOA par défaut, la liste **Endpoints (Points de terminaison)** affiche **No targets available (Aucune cible disponible)**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas choisir un enregistrement dont la valeur **Record type (Type d'enregistrement)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

# Valeurs spécifiques aux enregistrements simples
<a name="resource-record-sets-values-basic"></a>

Lorsque vous créez des enregistrements simples, vous spécifiez les valeurs suivantes.

**Topics**
+ [Stratégie de routage](#rrsets-values-basic-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-basic-name)
+ [Valeur/acheminer le trafic vers](#rrsets-values-basic-value)
+ [Type de registre](#rrsets-values-basic-type)
+ [TTL (secondes)](#rrsets-values-basic-ttl)

## Stratégie de routage
<a name="rrsets-values-basic-routing-policy"></a>

Choisissez **Simple routing (Routage simple)**.

## Nom de l’enregistrement
<a name="rrsets-values-basic-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Valeur/acheminer le trafic vers
<a name="rrsets-values-basic-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **NS — Serveur de noms**

  Nom de domaine d'un serveur de noms, par exemple, **ns1.example.com**.
**Note**  
Vous ne pouvez spécifier un enregistrement NS qu'avec une politique de routage simple.
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Type de registre
<a name="rrsets-values-basic-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur pour le champ **Record type (Type d'enregistrement)** en fonction de la façon dont vous voulez que Route 53 réponde aux requêtes DNS. 

## TTL (secondes)
<a name="rrsets-values-basic-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

# Valeurs spécifiques aux enregistrements d'alias simples
<a name="resource-record-sets-values-alias"></a>

Lorsque vous créez des enregistrements d'alias, vous spécifiez les valeurs suivantes. Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Note**  
Si vous utilisez Route 53 dans le AWS GovCloud (US) Region, cette fonctionnalité comporte certaines restrictions. Pour plus d'informations, consultez la [page Amazon Route 53](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) dans le *Guide de l'utilisateur AWS GovCloud (US) *.

**Topics**
+ [Stratégie de routage](#rrsets-values-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-alias-name)
+ [Évaluer/acheminer le trafic vers](#rrsets-values-alias-alias-target)
+ [Type de registre](#rrsets-values-alias-type)
+ [Évaluer l'état de la cible](#rrsets-values-alias-evaluate-target-health)

## Stratégie de routage
<a name="rrsets-values-alias-routing-policy"></a>

Choisissez **Simple routing (Routage simple)**.

## Nom de l’enregistrement
<a name="rrsets-values-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Évaluer/acheminer le trafic vers
<a name="rrsets-values-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez [les valeurs communes des enregistrements d'alias destinés au value/route trafic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la configuration de Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

## Type de registre
<a name="rrsets-values-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

## Évaluer l'état de la cible
<a name="rrsets-values-alias-evaluate-target-health"></a>

Lorsque la valeur de **Routing policy (Politique de routage)** est **Simple (Simple)**, vous pouvez choisir **No (Non)** ou la valeur par défaut **Yes (Oui)**, car **Evaluate target health (Évaluer l'état de la cible)** n'a aucun effet pour le routage **Simple (Simple)**. Si vous avez un seul enregistrement avec un nom et un type donnés, Route 53 répond aux requêtes DNS à l'aide des valeurs de cet enregistrement que la ressource soit saine ou non.

Pour les autres politiques de routage, **Evaluate target health** détermine si Route 53 vérifie l'état de santé de la ressource à laquelle l'enregistrement d'alias fait référence :
+ **Services dans lesquels l'évaluation de l'état de santé de la cible présente un avantage opérationnel** : pour les équilibreurs de charge (ELB) et AWS Elastic Beanstalk les environnements dotés d'équilibreurs de charge, le réglage de l'**état de la cible sur **Oui** permet à la** Route 53 d'acheminer le trafic loin des ressources malsaines.
+ **Services hautement disponibles** : pour des services tels que les compartiments Amazon S3, les points de terminaison d'interface VPC, Amazon API Gateway AWS Global Accelerator, Amazon Service et OpenSearch Amazon VPC Lattice**, Evaluate target** health n'apporte aucun avantage opérationnel car ces services sont conçus pour une haute disponibilité. Pour les scénarios de basculement avec ces services, utilisez plutôt les [contrôles de santé de Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html).

Pour obtenir des informations détaillées sur le fonctionnement **d'Evaluate Target Health** avec différents AWS services, consultez la [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth)documentation dans la référence de l'API.

# Valeurs spécifiques aux enregistrements de basculement
<a name="resource-record-sets-values-failover"></a>

Lorsque vous créez des enregistrements de basculement, vous spécifiez les valeurs suivantes.

**Note**  
Pour plus d'informations sur la création d'enregistrements de basculement dans une zone hébergée privée, consultez [Configuration du basculement dans une zone hébergée privée](dns-failover-private-hosted-zones.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-failover-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-failover-name)
+ [Type de registre](#rrsets-values-failover-type)
+ [TTL (secondes)](#rrsets-values-failover-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-failover-value)
+ [Type d’enregistrement de basculement](#rrsets-values-failover-record-type)
+ [Surveillance de l'état](#rrsets-values-failover-associate-with-health-check)
+ [ID d’enregistrement](#rrsets-values-failover-set-id)

## Stratégie de routage
<a name="rrsets-values-failover-routing-policy"></a>

Choisissez **Basculement**. 

## Nom de l’enregistrement
<a name="rrsets-values-failover-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour les deux enregistrements du groupe d'enregistrements de basculement. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Type de registre
<a name="rrsets-values-failover-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la même valeur pour les enregistrements de basculement principaux et secondaires.

## TTL (secondes)
<a name="rrsets-values-failover-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-failover-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Type d’enregistrement de basculement
<a name="rrsets-values-failover-record-type"></a>

Choisissez la valeur applicable pour cet enregistrement. Pour que le basculement fonctionne correctement, vous devez créer un enregistrement de basculement principal et un secondaire.

Vous ne pouvez pas créer d'enregistrements qui ne sont pas de type basculement en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements de basculement.

## Surveillance de l'état
<a name="rrsets-values-failover-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes (Oui)** pour **Evaluate target health (Évaluer l'état de la cible)** pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Nom de domaine**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une surveillance de l'état pour laquelle la valeur du champ **Nom de domaine** correspond au nom des enregistrements et si vous associez ensuite la surveillance de l'état à ces enregistrements, les résultats de la surveillance de l'état seront imprévisibles.

## ID d’enregistrement
<a name="rrsets-values-failover-set-id"></a>

Entrez une valeur qui identifie de façon unique les enregistrements principaux et secondaires. 

# Valeurs spécifiques aux enregistrements d'alias de basculement
<a name="resource-record-sets-values-failover-alias"></a>

Lorsque vous créez des enregistrements d'alias de basculement, vous spécifiez les valeurs suivantes.

Pour plus d’informations, consultez les rubriques suivantes :
+ Pour plus d'informations sur la création d'enregistrements de basculement dans une zone hébergée privée, consultez [Configuration du basculement dans une zone hébergée privée](dns-failover-private-hosted-zones.md).
+ Pour plus d'informations sur les enregistrements d'alias, consultez [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-failover-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-failover-alias-name)
+ [Type de registre](#rrsets-values-failover-alias-type)
+ [Valeur/acheminer le trafic vers](#rrsets-values-failover-alias-alias-target)
+ [Type d’enregistrement de basculement](#rrsets-values-failover-alias-failover-record-type)
+ [Surveillance de l'état](#rrsets-values-failover-alias-associate-with-health-check)
+ [Évaluer l'état de la cible](#rrsets-values-failover-alias-evaluate-target-health)
+ [ID d’enregistrement](#rrsets-values-failover-alias-set-id)

## Stratégie de routage
<a name="rrsets-values-failover-alias-routing-policy"></a>

Choisissez **Basculement**. 

## Nom de l’enregistrement
<a name="rrsets-values-failover-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour les deux enregistrements du groupe d'enregistrements de basculement. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Type de registre
<a name="rrsets-values-failover-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic. Sélectionnez la même valeur pour les enregistrements de basculement principaux et secondaires :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

## Valeur/acheminer le trafic vers
<a name="rrsets-values-failover-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez [les valeurs communes des enregistrements d'alias destinés au value/route trafic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la façon de configurer Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

**Note**  
Lorsque vous créez des enregistrements de basculement principaux et secondaires, vous pouvez éventuellement créer un enregistrement de basculement et un enregistrement d'*alias* de basculement ayant les mêmes valeurs pour les champs **Name (Nom)** et **Record type (Type d'enregistrement)**. Si vous mélangez des enregistrements de basculement et d'alias de basculement, n'importe lequel d'entre eux peut être l'enregistrement principal. 

## Type d’enregistrement de basculement
<a name="rrsets-values-failover-alias-failover-record-type"></a>

Choisissez la valeur applicable pour cet enregistrement. Pour que le basculement fonctionne correctement, vous devez créer un enregistrement de basculement principal et un secondaire.

Vous ne pouvez pas créer d'enregistrements qui ne sont pas de type basculement en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements de basculement.

## Surveillance de l'état
<a name="rrsets-values-failover-alias-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes (Oui)** pour **Evaluate target health (Évaluer l'état de la cible)** pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Nom de domaine**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une surveillance de l'état pour laquelle la valeur du champ **Nom de domaine** correspond au nom des enregistrements et si vous associez ensuite la surveillance de l'état à ces enregistrements, les résultats de la surveillance de l'état seront imprévisibles.

## Évaluer l'état de la cible
<a name="rrsets-values-failover-alias-evaluate-target-health"></a>

Sélectionnez **Yes (Oui)** si vous voulez que Route 53 détermine s'il doit répondre aux requêtes DNS à l'aide de cet enregistrement en vérifiant l'état de la ressource spécifiée dans le champ **Endpoint (Point de terminaison)**. 

Notez ce qui suit :

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est une API régionale personnalisée API Gateway ou une API optimisée pour la périphérie.

**CloudFront distributions**  
Vous ne pouvez pas définir **Evaluate target health** sur **Oui** lorsque le point de terminaison est une CloudFront distribution.

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si vous spécifiez un environnement Elastic Beanstalk dans **Endpoint (Point de terminaison)** et que l'environnement contient un équilibreur de charge ELB, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. (Un environnement contient automatiquement un équilibreur de charge ELB s'il inclut plusieurs instances Amazon EC2.) Si vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance Amazon EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources disponibles saines, le cas échéant.   
Si l'environnement contient une seule instance Amazon EC2, il n'y a aucune exigence particulière.

**Equilibreurs de charge ELB**  
Le comportement de la surveillance de l'état dépend du type de l'équilibreur de charge :  
+ **Équilibreurs Classic Load Balancer** : si vous spécifiez un équilibreur Classic Load Balancer ELB dans **Endpoint (Point de terminaison)**, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. Si vous définissez le champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources.
+ **Équilibreurs de charge d'application et Network Load Balancer** : si vous spécifiez un équilibreur de charge ELB d'application ou Network Load Balancer et que vous définissez **Evaluate Target health (Évaluer l'état de la cible)** sur **Yes (Oui)**, Route 53 achemine les requêtes vers l'équilibreur de charge en fonction de l'état des groupes cible associés à l'équilibreur de charge :
  + Pour qu'un équilibreur d'application ou un équilibreur Network Load Balancer soit considéré comme sain, un groupe cible contenant des cibles doit en contenir au moins une saine. Si un groupe cible contient uniquement des cibles qui ne sont pas saines, l'équilibreur de charge est considéré comme étant lui-même défectueux et Route 53 achemine les requêtes vers d'autres ressources.
  + Un groupe cible qui n'a pas de cibles enregistrées est considéré comme non sain.
Lorsque vous créez un équilibreur de charge, vous configurez les paramètres des surveillances de l'état Elastic Load Balancing ; il ne s'agit pas de surveillances de l'état Route 53, mais elles jouent le même rôle. Ne créez pas de surveillances de l'état Route 53 pour les instances EC2 que vous enregistrez auprès d'un équilibreur de charge ELB. 

**Compartiments S3**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un compartiment S3.

**Points de terminaison de l'interface d'un VPC Amazon**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un point de terminaison d'interface d'un VPC Amazon.

**Autres enregistrements dans la même zone hébergée**  
Si la AWS ressource que vous spécifiez dans **Endpoint** est un enregistrement ou un groupe d'enregistrements (par exemple, un groupe d'enregistrements pondérés) mais qu'il ne s'agit pas d'un autre enregistrement alias, nous vous recommandons d'associer un bilan de santé à tous les enregistrements du point de terminaison. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous omettez des surveillances de l'état ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## ID d’enregistrement
<a name="rrsets-values-failover-alias-set-id"></a>

Entrez une valeur qui identifie de façon unique les enregistrements principaux et secondaires. 

# Valeurs spécifiques aux enregistrements de géolocalisation
<a name="resource-record-sets-values-geo"></a>

Lorsque vous créez des enregistrements de géolocalisation, vous spécifiez les valeurs suivantes.

**Topics**
+ [Stratégie de routage](#rrsets-values-geo-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-geo-name)
+ [Type de registre](#rrsets-values-geo-type)
+ [TTL (secondes)](#rrsets-values-geo-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-geo-value)
+ [Location](#rrsets-values-geo-location)
+ [États des États-Unis](#rrsets-values-geo-sublocation)
+ [Surveillance de l'état](#rrsets-values-geo-associate-with-health-check)
+ [ID d’enregistrement](#rrsets-values-geo-set-id)

## Stratégie de routage
<a name="rrsets-values-geo-routing-policy"></a>

Sélectionnez **Geolocation (Géolocalisation)**. 

## Nom de l’enregistrement
<a name="rrsets-values-geo-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements de géolocalisation. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Type de registre
<a name="rrsets-values-geo-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de géolocalisation :

## TTL (secondes)
<a name="rrsets-values-geo-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-geo-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Location
<a name="rrsets-values-geo-location"></a>

Lorsque vous configurez Route 53 pour qu'il réponde aux requêtes DNS en fonction de leur emplacement d'origine, sélectionnez le continent ou le pays pour lequel vous voulez que Route 53 réponde avec les paramètres figurant dans cet enregistrement. Si vous voulez que Route 53 réponde aux requêtes DNS pour certains États des États-Unis, sélectionnez **United States (États-Unis)** dans la liste **Location (Localisation)**, puis choisissez l'État sous le groupe **Sublocation (Sous-localisation)**.

Pour une zone hébergée privée, sélectionnez le continent, le pays ou la subdivision le plus proche de Région AWS celui dans lequel se trouve votre ressource. Par exemple, si votre ressource se trouve dans us-east-1, vous pouvez spécifier Amérique du Nord, États-Unis ou Virginie.

**Important**  
Nous vous conseillons de créer un enregistrement de géolocalisation ayant la valeur **Default (Par défaut)** pour **Location (Localisation)**. Ainsi, les emplacements géographiques pour lesquels vous n'avez pas créé d'enregistrements et les adresses IP dont Route 53 ne peut identifier l'emplacement sont couverts.

Vous ne pouvez pas créer d'enregistrements qui ne sont pas de type géolocalisation en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements de géolocalisation.

Pour de plus amples informations, veuillez consulter [Routage de géolocalisation](routing-policy-geo.md).

Voici les pays qu'Amazon Route 53 associe à chaque continent. Les codes des pays suivent la norme ISO 3166. Pour plus d'informations, consultez l'article Wikipédia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) :

**Afrique (AF)**  
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW

**Antarctique (AN)**  
AQ, GS, TF

**Asie (AS)**  
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE

**Europe (EU)**  
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK  
Certains fournisseurs considèrent que TR se trouve en Asie et les adresses IP refléteront cela.

**Amérique du Nord (NA)**  
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI

**Océanie (OC)**  
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS

**Amérique du Sud (SA)**  
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE

**Note**  
Route 53 ne prend pas en charge la création d'enregistrements de géolocalisation pour les pays suivants : Île Bouvet (BV), Île Christmas (CX), Sahara Occidental (EH) et Île et McDonald îles Heard (HM). Aucune donnée n'est disponible sur les adresses IP pour ces pays.

## États des États-Unis
<a name="rrsets-values-geo-sublocation"></a>

Lorsque vous configurez Route 53 pour qu'il réponde aux requêtes DNS en fonction de l'État des États-Unis dont elles proviennent, sélectionnez l'État dans la liste **U.S. states (États des États-Unis)**. Les territoires des Etats-Unis (par exemple, Porto Rico) sont répertoriés en tant que pays dans la liste **Localisation**.

**Important**  
Certaines adresses IP sont associées aux États-Unis, mais pas à un état individuel. Si vous créez des enregistrements pour tous les États des États-Unis, nous vous recommandons de créer également un enregistrement pour les États-Unis pour acheminer les requêtes pour ces adresses IP non associées. Si vous ne créez pas d'enregistrement pour les États-Unis, Route 53 répond aux requêtes DNS provenant des adresses IP non associées des États-Unis avec les paramètres de l'enregistrement de géolocalisation par défaut (si vous en avez créé un) ou avec un message « aucune réponse ». 

## Surveillance de l'état
<a name="rrsets-values-geo-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes (Oui)** pour **Evaluate target health (Évaluer l'état de la cible)** pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Nom de domaine**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une surveillance de l'état pour laquelle la valeur du champ **Nom de domaine** correspond au nom des enregistrements et si vous associez ensuite la surveillance de l'état à ces enregistrements, les résultats de la surveillance de l'état seront imprévisibles.

Pour les enregistrements de géolocalisation, si un point de terminaison n'est pas sain, Route 53 recherche un enregistrement pour la région géographique associée de taille supérieure. Par exemple, supposons que vous disposez d'enregistrements pour un État des États-Unis, pour les États-Unis, pour l'Amérique du Nord et pour tous les emplacements (la valeur du champ **Location [Emplacement]** est **Default [Par défaut]**). Si le point de terminaison de l'enregistrement de l'État n'est pas sain, Route 53 vérifie les enregistrements pour les États-Unis, pour l'Amérique du Nord, ainsi que pour tous les emplacements, dans cet ordre, jusqu'à ce qu'il trouve un enregistrement comportant un point de terminaison sain. Si tous les enregistrements applicables sont défaillants, y compris l'enregistrement pour tous les emplacements, Route 53 répond à la requête DNS à l'aide de la valeur pour l'enregistrement de la région géographique la plus petite. 

## ID d’enregistrement
<a name="rrsets-values-geo-set-id"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements de géolocalisation.

# Valeurs spécifiques aux enregistrements d'alias de géolocalisation
<a name="resource-record-sets-values-geo-alias"></a>

Lorsque vous créez des enregistrements d'alias de géolocalisation, vous spécifiez les valeurs suivantes.

Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-geo-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-geo-alias-name)
+ [Type de registre](#rrsets-values-geo-alias-type)
+ [Valeur/acheminer le trafic vers](#rrsets-values-geo-alias-alias-target)
+ [Location](#rrsets-values-geo-alias-location)
+ [États des États-Unis](#rrsets-values-geo-alias-sublocation)
+ [Surveillance de l'état](#rrsets-values-geo-alias-associate-with-health-check)
+ [Évaluer l'état de la cible](#rrsets-values-geo-alias-evaluate-target-health)
+ [ID d’enregistrement](#rrsets-values-geo-alias-set-id)

## Stratégie de routage
<a name="rrsets-values-geo-alias-routing-policy"></a>

Sélectionnez **Geolocation (Géolocalisation)**. 

## Nom de l’enregistrement
<a name="rrsets-values-geo-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements de géolocalisation. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Type de registre
<a name="rrsets-values-geo-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic. Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de géolocalisation :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

## Valeur/acheminer le trafic vers
<a name="rrsets-values-geo-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez[Évaluer/acheminer le trafic vers](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la configuration de Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

## Location
<a name="rrsets-values-geo-alias-location"></a>

Lorsque vous configurez Route 53 pour qu'il réponde aux requêtes DNS en fonction de leur emplacement d'origine, sélectionnez le continent ou le pays pour lequel vous voulez que Route 53 réponde avec les paramètres figurant dans cet enregistrement. Si vous voulez que Route 53 réponde aux requêtes DNS pour certains États des États-Unis, sélectionnez **United States (ÉEtats-Unis)** dans la liste **Location (Localisation)**, puis choisissez l'État dans la liste **U.S. states (États des États-Unis)**.

Pour une zone hébergée privée, sélectionnez le continent, le pays ou la subdivision le plus proche de Région AWS celui dans lequel se trouve votre ressource. Par exemple, si votre ressource se trouve dans us-east-1, vous pouvez spécifier Amérique du Nord, États-Unis ou Virginie.

**Important**  
Nous vous conseillons de créer un enregistrement de géolocalisation ayant la valeur **Default (Par défaut)** pour **Location (Localisation)**. Ainsi, les emplacements géographiques pour lesquels vous n'avez pas créé d'enregistrements et les adresses IP dont Route 53 ne peut identifier l'emplacement sont couverts.

Vous ne pouvez pas créer d'enregistrements qui ne sont pas de type géolocalisation en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements de géolocalisation.

Pour de plus amples informations, veuillez consulter [Routage de géolocalisation](routing-policy-geo.md).

Voici les pays qu'Amazon Route 53 associe à chaque continent. Les codes des pays suivent la norme ISO 3166. Pour plus d'informations, consultez l'article Wikipédia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) :

**Afrique (AF)**  
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW

**Antarctique (AN)**  
AQ, GS, TF

**Asie (AS)**  
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE

**Europe (EU)**  
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK  
Certains fournisseurs considèrent que TR se trouve en Asie et les adresses IP refléteront cela.

**Amérique du Nord (NA)**  
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI

**Océanie (OC)**  
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS

**Amérique du Sud (SA)**  
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE

**Note**  
Route 53 ne prend pas en charge la création d'enregistrements de géolocalisation pour les pays suivants : Île Bouvet (BV), Île Christmas (CX), Sahara Occidental (EH) et Île et McDonald îles Heard (HM). Aucune donnée n'est disponible sur les adresses IP pour ces pays.

## États des États-Unis
<a name="rrsets-values-geo-alias-sublocation"></a>

Lorsque vous configurez Route 53 pour qu'il réponde aux requêtes DNS en fonction de l'État des États-Unis dont elles proviennent, sélectionnez l'État dans la liste **U.S. states (États des États-Unis)**. Les territoires des Etats-Unis (par exemple, Porto Rico) sont répertoriés en tant que pays dans la liste **Localisation**.

**Important**  
Certaines adresses IP sont associées aux États-Unis, mais pas à un état individuel. Si vous créez des enregistrements pour tous les États des États-Unis, nous vous recommandons de créer également un enregistrement pour les États-Unis pour acheminer les requêtes pour ces adresses IP non associées. Si vous ne créez pas d'enregistrement pour les États-Unis, Route 53 répond aux requêtes DNS provenant des adresses IP non associées des États-Unis avec les paramètres de l'enregistrement de géolocalisation par défaut (si vous en avez créé un) ou avec un message « aucune réponse ». 

## Surveillance de l'état
<a name="rrsets-values-geo-alias-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP, ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

Pour les enregistrements de géolocalisation, si un point de terminaison n'est pas sain, Route 53 recherche un enregistrement pour la région géographique associée de taille supérieure. Par exemple, supposons que vous disposez d'enregistrements pour un État des États-Unis, pour les États-Unis, pour l'Amérique du Nord et pour tous les emplacements (la valeur du champ **Location [Emplacement]** est **Default [Par défaut]**). Si le point de terminaison de l'enregistrement de l'État n'est pas sain, Route 53 vérifie les enregistrements pour les États-Unis, pour l'Amérique du Nord, ainsi que pour tous les emplacements, dans cet ordre, jusqu'à ce qu'il trouve un enregistrement comportant un point de terminaison sain. Si tous les enregistrements applicables sont défaillants, y compris l'enregistrement pour tous les emplacements, Route 53 répond à la requête DNS à l'aide de la valeur pour l'enregistrement de la région géographique la plus petite. 

## Évaluer l'état de la cible
<a name="rrsets-values-geo-alias-evaluate-target-health"></a>

Sélectionnez **Yes (Oui)** si vous voulez que Route 53 détermine s'il doit répondre aux requêtes DNS à l'aide de cet enregistrement en vérifiant l'état de la ressource spécifiée dans le champ **Endpoint (Point de terminaison)**. 

Notez ce qui suit :

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est une API régionale personnalisée API Gateway ou une API optimisée pour la périphérie.

**CloudFront distributions**  
Vous ne pouvez pas définir **Evaluate target health** sur **Oui** lorsque le point de terminaison est une CloudFront distribution.

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si vous spécifiez un environnement Elastic Beanstalk dans **Endpoint (Point de terminaison)** et que l'environnement contient un équilibreur de charge ELB, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. (Un environnement contient automatiquement un équilibreur de charge ELB s'il inclut plusieurs instances Amazon EC2.) Si vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance Amazon EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources disponibles saines, le cas échéant.   
Si l'environnement contient une seule instance Amazon EC2, il n'y a aucune exigence particulière.

**Equilibreurs de charge ELB**  
Le comportement de la surveillance de l'état dépend du type de l'équilibreur de charge :  
+ **Équilibreurs Classic Load Balancer** : si vous spécifiez un équilibreur Classic Load Balancer ELB dans **Endpoint (Point de terminaison)**, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. Si vous définissez le champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources.
+ **Équilibreurs de charge d'application et Network Load Balancer** : si vous spécifiez un équilibreur de charge ELB d'application ou Network Load Balancer et que vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)**, Route 53 achemine les requêtes vers l'équilibreur de charge en fonction de l'état des groupes cible associés à l'équilibreur de charge :
  + Pour qu'un équilibreur d'application ou un équilibreur Network Load Balancer soit considéré comme sain, chaque groupe cible contenant des cibles doit en contenir au moins une saine. Si un groupe cible contient uniquement des cibles qui ne sont pas saines, l'équilibreur de charge est considéré comme étant lui-même défectueux et Route 53 achemine les requêtes vers d'autres ressources.
  + Un groupe cible qui n'a pas de cibles enregistrées est considéré comme non sain.
Lorsque vous créez un équilibreur de charge, vous configurez les paramètres des surveillances de l'état Elastic Load Balancing ; il ne s'agit pas de surveillances de l'état Route 53, mais elles jouent le même rôle. Ne créez pas de surveillances de l'état Route 53 pour les instances EC2 que vous enregistrez auprès d'un équilibreur de charge ELB. 

**Compartiments S3**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un compartiment S3.

**Points de terminaison de l'interface d'un VPC Amazon**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un point de terminaison d'interface d'un VPC Amazon.

**Autres enregistrements dans la même zone hébergée**  
Si la AWS ressource que vous spécifiez dans **Endpoint** est un enregistrement ou un groupe d'enregistrements (par exemple, un groupe d'enregistrements pondérés) mais qu'il ne s'agit pas d'un autre enregistrement alias, nous vous recommandons d'associer un bilan de santé à tous les enregistrements du point de terminaison. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous omettez des surveillances de l'état ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## ID d’enregistrement
<a name="rrsets-values-geo-alias-set-id"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements de géolocalisation.

# Valeurs spécifiques aux enregistrements de géoproximité
<a name="resource-record-sets-values-geoprox"></a>

Lorsque vous créez des enregistrements de géoproximité, vous spécifiez les valeurs suivantes.

**Topics**
+ [Stratégie de routage](#rrsets-values-geoprox-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-geoprox-name)
+ [Type de registre](#rrsets-values-geoprox-type)
+ [TTL (secondes)](#rrsets-values-geoprox-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-geoprox-value)
+ [Emplacement du point de terminaison](#rrsets-values-geoprox-endpoint-location)
+ [Écart](#rrsets-values-geoprox-bias)
+ [Surveillance de l'état](#rrsets-values-geoprox-associate-with-health-check)
+ [ID d’enregistrement](#rrsets-values-geoprox-set-id)

## Stratégie de routage
<a name="rrsets-values-geoprox-routing-policy"></a>

Choisissez **Geoproximity**. 

## Nom de l’enregistrement
<a name="rrsets-values-geoprox-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements de géoproximité. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Type de registre
<a name="rrsets-values-geoprox-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de géoproximité.

## TTL (secondes)
<a name="rrsets-values-geoprox-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-geoprox-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Emplacement du point de terminaison
<a name="rrsets-values-geoprox-endpoint-location"></a>

Vous pouvez spécifier l'emplacement du point de terminaison de la ressource en utilisant l'une des méthodes suivantes : 

**Coordonnées personnalisées**  
Spécifiez la longitude et la latitude d'une zone géographique.

**Région AWS**  
Choisissez une région disponible dans la liste des **emplacements**.   
Pour plus d'informations sur les régions, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/).

**AWS Groupe de zones local**  
Choisissez un groupe de zones local disponible dans la liste des **emplacements**.  
Pour plus d'informations sur les zones locales, consultez la section [Zones locales disponibles](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) dans le *guide de l'utilisateur des zones AWS locales*. Un groupe de zones local est généralement la zone locale sans le caractère final. Par exemple, si la zone locale est `us-east-1-bue-1a` le groupe de zones local l'est`us-east-1-bue-1`.

Vous pouvez également identifier le groupe de zones locales pour une zone locale spécifique à l'aide de la commande [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI :

```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```

Cette commande renvoie :`"GroupName": "us-west-2-den-1"`, en spécifiant que la zone locale `us-west-2-den-1a` appartient au groupe de zones locales`us-west-2-den-1`.

Vous ne pouvez pas créer d'enregistrements non liés à la géoproximité ayant les mêmes valeurs pour le **nom et le type d'enregistrement** **que pour les enregistrements** de géoproximité.

Vous ne pouvez pas non plus créer deux jeux d'enregistrements de ressources de géoproximité qui spécifient le même emplacement pour le même nom et le même type d'enregistrement.

## Écart
<a name="rrsets-values-geoprox-bias"></a>

Un biais étend ou réduit une zone géographique à partir de laquelle la Route 53 achemine le trafic vers une ressource. Un biais positif élargit la zone et un biais négatif la réduit. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 utilise une valeur d'écart pour acheminer le trafic](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).

## Surveillance de l'état
<a name="rrsets-values-geoprox-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Oui** pour **Evaluate Target Health** pour un enregistrement d'alias ou pour les enregistrements d'un groupe d'alias de basculement, d'alias de géolocalisation, d'alias de géoproximité, d'alias de latence, d'alias basé sur IP ou d'enregistrement d'alias pondéré. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Nom de domaine**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une surveillance de l'état pour laquelle la valeur du champ **Nom de domaine** correspond au nom des enregistrements et si vous associez ensuite la surveillance de l'état à ces enregistrements, les résultats de la surveillance de l'état seront imprévisibles.

Pour les enregistrements de géoproximité, si un point de terminaison est défectueux, Route 53 recherche le point de terminaison le plus proche qui est toujours sain. 

## ID d’enregistrement
<a name="rrsets-values-geoprox-set-id"></a>

Entrez une valeur identifiant de manière unique cet enregistrement dans le groupe d'enregistrements de géoproximité.

# Valeurs spécifiques aux enregistrements d'alias de géoproximité
<a name="resource-record-sets-values-geoprox-alias"></a>

Lorsque vous créez des enregistrements d'alias de géoproximité, vous spécifiez les valeurs suivantes.

Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-geoprox-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-geoprox-alias-name)
+ [Type de registre](#rrsets-values-geoprox-alias-type)
+ [Valeur/acheminer le trafic vers](#rrsets-values-geoprox-alias-alias-target)
+ [Emplacement du point de terminaison](#rrsets-values-geoprox-alias-endpoint-location)
+ [Écart](#rrsets-values-geoprox-alias-bias)
+ [Surveillance de l'état](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [Évaluer l'état de la cible](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [ID d’enregistrement](#rrsets-values-geoprox-alias-set-id)

## Stratégie de routage
<a name="rrsets-values-geoprox-alias-routing-policy"></a>

Choisissez **Geoproximity**. 

## Nom de l’enregistrement
<a name="rrsets-values-geoprox-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements de géoproximité. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Type de registre
<a name="rrsets-values-geoprox-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic. Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de géoproximité :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

## Valeur/acheminer le trafic vers
<a name="rrsets-values-geoprox-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez[Évaluer/acheminer le trafic vers](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la façon de configurer Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

## Emplacement du point de terminaison
<a name="rrsets-values-geoprox-alias-endpoint-location"></a>

Vous pouvez spécifier l'emplacement du point de terminaison de la ressource en utilisant l'une des méthodes suivantes : 

**Coordonnées personnalisées**  
Spécifiez la longitude et la latitude d'une zone géographique.

**Région AWS**  
Choisissez une région disponible dans la liste des **emplacements**.   
Pour plus d'informations sur les régions, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/).

**AWS Groupe de zones local**  
Choisissez une région de zone locale disponible dans la liste des **emplacements**.  
Pour plus d'informations sur les zones locales, consultez la section [Zones locales disponibles](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) dans le *guide de l'utilisateur des zones AWS locales*. Un groupe de zones local est généralement la zone locale sans le caractère final. Par exemple, si la zone locale est `us-east-1-bue-1a` le groupe de zones local l'est`us-east-1-bue-1`.

Vous pouvez également identifier le groupe de zones locales pour une zone locale spécifique à l'aide de la commande [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI :

```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```

Cette commande renvoie :`"GroupName": "us-west-2-den-1"`, en spécifiant que la zone locale `us-west-2-den-1a` appartient au groupe de zones locales`us-west-2-den-1`.

Vous ne pouvez pas créer d'enregistrements non liés à la géoproximité ayant les mêmes valeurs pour le **nom et le type d'enregistrement** **que pour les enregistrements** de géoproximité.

Vous ne pouvez pas non plus créer deux jeux d'enregistrements de ressources de géoproximité qui spécifient le même emplacement pour le même nom et le même type d'enregistrement.

Pour plus d'informations, voir available-local-zones .html

## Écart
<a name="rrsets-values-geoprox-alias-bias"></a>

Un biais étend ou réduit une zone géographique à partir de laquelle la Route 53 achemine le trafic vers une ressource. Un biais positif élargit la zone et un biais négatif la réduit. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 utilise une valeur d'écart pour acheminer le trafic](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).

## Surveillance de l'état
<a name="rrsets-values-geoprox-alias-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Oui** pour **évaluer l'état de santé de la cible** pour un enregistrement d'alias ou les enregistrements d'un groupe d'alias de basculement, d'alias de géolocalisation, d'alias de géoproximité, d'alias de latence, d'alias basé sur l'IP ou d'enregistrement d'alias pondéré. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

Pour les enregistrements de géoproximité, si un point de terminaison est défectueux, Route 53 recherche le point de terminaison le plus proche qui est toujours sain. 

## Évaluer l'état de la cible
<a name="rrsets-values-geoprox-alias-evaluate-target-health"></a>

Sélectionnez **Yes (Oui)** si vous voulez que Route 53 détermine s'il doit répondre aux requêtes DNS à l'aide de cet enregistrement en vérifiant l'état de la ressource spécifiée dans le champ **Endpoint (Point de terminaison)**. 

Notez ce qui suit :

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est une API régionale personnalisée API Gateway ou une API optimisée pour la périphérie.

**CloudFront distributions**  
Vous ne pouvez pas définir **Evaluate target health** sur **Oui** lorsque le point de terminaison est une CloudFront distribution.

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si vous spécifiez un environnement Elastic Beanstalk dans **Endpoint (Point de terminaison)** et que l'environnement contient un équilibreur de charge ELB, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. (Un environnement contient automatiquement un équilibreur de charge ELB s'il inclut plusieurs instances Amazon EC2.) Si vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance Amazon EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources disponibles saines, le cas échéant.   
Si l'environnement contient une seule instance Amazon EC2, il n'y a aucune exigence particulière.

**Equilibreurs de charge ELB**  
Le comportement de la surveillance de l'état dépend du type de l'équilibreur de charge :  
+ **Équilibreurs Classic Load Balancer** : si vous spécifiez un équilibreur Classic Load Balancer ELB dans **Endpoint (Point de terminaison)**, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. Si vous définissez le champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources.
+ **Équilibreurs de charge d'application et Network Load Balancer** : si vous spécifiez un équilibreur de charge ELB d'application ou Network Load Balancer et que vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)**, Route 53 achemine les requêtes vers l'équilibreur de charge en fonction de l'état des groupes cible associés à l'équilibreur de charge :
  + Pour qu'un équilibreur d'application ou un équilibreur Network Load Balancer soit considéré comme sain, chaque groupe cible contenant des cibles doit en contenir au moins une saine. Si un groupe cible contient uniquement des cibles qui ne sont pas saines, l'équilibreur de charge est considéré comme étant lui-même défectueux et Route 53 achemine les requêtes vers d'autres ressources.
  + Un groupe cible qui n'a pas de cibles enregistrées est considéré comme non sain.
Lorsque vous créez un équilibreur de charge, vous configurez les paramètres des surveillances de l'état Elastic Load Balancing ; il ne s'agit pas de surveillances de l'état Route 53, mais elles jouent le même rôle. Ne créez pas de surveillances de l'état Route 53 pour les instances EC2 que vous enregistrez auprès d'un équilibreur de charge ELB. 

**Compartiments S3**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un compartiment S3.

**Points de terminaison de l'interface d'un VPC Amazon**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un point de terminaison d'interface d'un VPC Amazon.

**Autres enregistrements dans la même zone hébergée**  
Si la AWS ressource que vous spécifiez dans **Endpoint** est un enregistrement ou un groupe d'enregistrements (par exemple, un groupe d'enregistrements pondérés) mais qu'il ne s'agit pas d'un autre enregistrement alias, nous vous recommandons d'associer un bilan de santé à tous les enregistrements du point de terminaison. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous omettez des surveillances de l'état ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## ID d’enregistrement
<a name="rrsets-values-geoprox-alias-set-id"></a>

Entrez une valeur identifiant de manière unique cet enregistrement dans le groupe d'enregistrements de géoproximité.

# Valeurs spécifiques aux enregistrements de latence
<a name="resource-record-sets-values-latency"></a>

Lorsque vous créez des enregistrements de latence, vous spécifiez les valeurs suivantes.

**Topics**
+ [Stratégie de routage](#rrsets-values-latency-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-latency-name)
+ [Type de registre](#rrsets-values-latency-type)
+ [TTL (secondes)](#rrsets-values-latency-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-latency-value)
+ [Région](#rrsets-values-latency-region)
+ [Surveillance de l'état](#rrsets-values-latency-associate-with-health-check)
+ [ID d’enregistrement](#rrsets-values-latency-set-id)

## Stratégie de routage
<a name="rrsets-values-latency-routing-policy"></a>

Choisissez **Latency (Latence)**. 

## Nom de l’enregistrement
<a name="rrsets-values-latency-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements de latence. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Type de registre
<a name="rrsets-values-latency-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur pour le champ **Type** en fonction de la façon dont vous voulez que Route 53 réponde aux requêtes DNS. 

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de latence.

## TTL (secondes)
<a name="rrsets-values-latency-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-latency-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Région
<a name="rrsets-values-latency-region"></a>

Région Amazon EC2 où est située la ressource que vous avez spécifiée dans cet enregistrement. Route 53 recommande une région Amazon EC2 en fonction d’autres valeurs que vous avez spécifiées. Cela s'applique également aux zones hébergées privées. Nous vous conseillons de pas modifier cette valeur.

Notez ce qui suit :
+ Vous ne pouvez créer qu’un seul enregistrement de latence pour chaque région Amazon EC2.
+ Vous n’êtes pas obligé de créer des enregistrements de latence pour toutes les régions Amazon EC2. Route 53 choisit la région dotée de la meilleure latence parmi les régions pour lesquelles vous créez des enregistrements de latence.
+ Vous ne pouvez pas créer des enregistrements qui ne sont pas de type latence en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements de latence.
+ Si vous créez un enregistrement balisé avec la région **cn-north-1**, Route 53 répond toujours aux requêtes en provenance de Chine en utilisant cet enregistrement, quelle que soit la latence.

Pour plus d'informations sur l'utilisation des enregistrements de latence, consultez [Routage basé sur la latence](routing-policy-latency.md). 

## Surveillance de l'état
<a name="rrsets-values-latency-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP, ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

## ID d’enregistrement
<a name="rrsets-values-latency-set-id"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements de latence.

# Valeurs spécifiques aux enregistrements d'alias de latence
<a name="resource-record-sets-values-latency-alias"></a>

Lorsque vous créez des enregistrements d'alias de latence, vous spécifiez les valeurs suivantes.

Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-latency-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-latency-alias-name)
+ [Type de registre](#rrsets-values-latency-alias-type)
+ [Valeur/acheminer le trafic vers](#rrsets-values-latency-alias-alias-target)
+ [Région](#rrsets-values-latency-alias-region)
+ [Surveillance de l'état](#rrsets-values-latency-alias-associate-with-health-check)
+ [Évaluer l'état de la cible](#rrsets-values-latency-alias-evaluate-target-health)
+ [ID d’enregistrement](#rrsets-values-latency-alias-set-id)

## Stratégie de routage
<a name="rrsets-values-latency-alias-routing-policy"></a>

Choisissez **Latency (Latence)**. 

## Nom de l’enregistrement
<a name="rrsets-values-latency-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements de latence. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)

## Type de registre
<a name="rrsets-values-latency-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de latence.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-latency-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez [les valeurs communes des enregistrements d'alias destinés au value/route trafic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la configuration de Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

## Région
<a name="rrsets-values-latency-alias-region"></a>

Région Amazon EC2 où est située la ressource que vous avez spécifiée dans cet enregistrement. Route 53 recommande une région Amazon EC2 en fonction d’autres valeurs que vous avez spécifiées. Cela s'applique également aux zones hébergées privées. Nous vous conseillons de pas modifier cette valeur.

Notez ce qui suit :
+ Vous ne pouvez créer qu’un seul enregistrement de latence pour chaque région Amazon EC2.
+ Vous n’êtes pas obligé de créer des enregistrements de latence pour toutes les régions Amazon EC2. Route 53 choisit la région dotée de la meilleure latence parmi les régions pour lesquelles vous créez des enregistrements de latence.
+ Vous ne pouvez pas créer des enregistrements qui ne sont pas de type latence en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements de latence.
+ Si vous créez un enregistrement balisé avec la région **cn-north-1**, Route 53 répond toujours aux requêtes en provenance de Chine en utilisant cet enregistrement, quelle que soit la latence.

Pour plus d'informations sur l'utilisation des enregistrements de latence, consultez [Routage basé sur la latence](routing-policy-latency.md). 

## Surveillance de l'état
<a name="rrsets-values-latency-alias-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP, ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une surveillance de l'état pour laquelle la valeur du champ **Nom de domaine** correspond au nom des enregistrements et si vous associez ensuite la surveillance de l'état à ces enregistrements, les résultats de la surveillance de l'état seront imprévisibles.

## Évaluer l'état de la cible
<a name="rrsets-values-latency-alias-evaluate-target-health"></a>

Sélectionnez **Yes (Oui)** si vous voulez que Route 53 détermine s'il doit répondre aux requêtes DNS à l'aide de cet enregistrement en vérifiant l'état de la ressource spécifiée dans le champ **Endpoint (Point de terminaison)**. 

Notez ce qui suit :

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est une API régionale personnalisée API Gateway ou une API optimisée pour la périphérie.

**CloudFront distributions**  
Vous ne pouvez pas définir **Evaluate Target Health** sur **Oui** lorsque le point de terminaison est une CloudFront distribution.

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si vous spécifiez un environnement Elastic Beanstalk dans **Endpoint (Point de terminaison)** et que l'environnement contient un équilibreur de charge ELB, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. (Un environnement contient automatiquement un équilibreur de charge ELB s'il inclut plusieurs instances Amazon EC2.) Si vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance Amazon EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources disponibles saines, le cas échéant.   
Si l'environnement contient une seule instance Amazon EC2, il n'y a aucune exigence particulière.

**Equilibreurs de charge ELB**  
Le comportement de la surveillance de l'état dépend du type de l'équilibreur de charge :  
+ **Équilibreurs Classic Load Balancer** : si vous spécifiez un équilibreur Classic Load Balancer ELB dans **Endpoint (Point de terminaison)**, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. Si vous définissez le champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources.
+ **Équilibreurs de charge d'application et Network Load Balancer** : si vous spécifiez un équilibreur de charge ELB d'application ou Network Load Balancer et que vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)**, Route 53 achemine les requêtes vers l'équilibreur de charge en fonction de l'état des groupes cible associés à l'équilibreur de charge :
  + Pour qu'un équilibreur d'application ou un équilibreur Network Load Balancer soit considéré comme sain, chaque groupe cible contenant des cibles doit en contenir au moins une saine. Si un groupe cible contient uniquement des cibles qui ne sont pas saines, l'équilibreur de charge est considéré comme étant lui-même défectueux et Route 53 achemine les requêtes vers d'autres ressources.
  + Un groupe cible qui n'a pas de cibles enregistrées est considéré comme non sain.
Lorsque vous créez un équilibreur de charge, vous configurez les paramètres des surveillances de l'état Elastic Load Balancing ; il ne s'agit pas de surveillances de l'état Route 53, mais elles jouent le même rôle. Ne créez pas de surveillances de l'état Route 53 pour les instances EC2 que vous enregistrez auprès d'un équilibreur de charge ELB. 

**Compartiments S3**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un compartiment S3.

**Points de terminaison de l'interface d'un VPC Amazon**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un point de terminaison d'interface d'un VPC Amazon.

**Autres enregistrements dans la même zone hébergée**  
Si la AWS ressource que vous spécifiez dans **Endpoint** est un enregistrement ou un groupe d'enregistrements (par exemple, un groupe d'enregistrements pondérés) mais qu'il ne s'agit pas d'un autre enregistrement alias, nous vous recommandons d'associer un bilan de santé à tous les enregistrements du point de terminaison. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous omettez des surveillances de l'état ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## ID d’enregistrement
<a name="rrsets-values-latency-alias-set-id"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements de latence.

# Valeurs spécifiques aux enregistrements basés sur IP
<a name="resource-record-sets-values-ipbased"></a>

Lorsque vous créez des enregistrements basés sur IP, vous spécifiez les valeurs suivantes.

**Note**  
Bien que la création d'enregistrements basés sur IP dans une zone hébergée privée soit autorisée, elle n'est pas prise en charge.

**Topics**
+ [Stratégie de routage](#rrsets-values-ipbased-routing-policy)
+ [Nom de l'enregistrement](#rrsets-values-ibased-name)
+ [Type de registre](#rrsets-values-ibased-type)
+ [TTL (secondes)](#rrsets-values-ibased-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-ibased-value)
+ [Emplacement](#rrsets-values-ibased-location)
+ [Surveillance de l'état](#rrsets-values-ibased-associate-with-health-check)
+ [ID d'enregistrement](#rrsets-values-ipbased-set-id)

## Stratégie de routage
<a name="rrsets-values-ipbased-routing-policy"></a>

Choisissez **IP-based** (basé sur IP). 

## Nom de l'enregistrement
<a name="rrsets-values-ibased-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Saisissez le même nom pour tous les enregistrements du groupe d'enregistrements basés sur IP. 

**Enregistrements CNAME**  
Si vous créez un enregistrement dont la valeur est **CNAME** pour **Record type (Type d'enregistrement)**, le nom de l'enregistrement ne peut être identique à celui de la zone hébergée.

**Caractères spéciaux**  
Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

**Caractères génériques**  
Vous pouvez utiliser un astérisque (\$1) dans le nom. DNS traite le caractère \$1 comme un caractère générique ou comme le caractère \$1 (ASCII 42), en fonction de son emplacement dans le nom. Pour de plus amples informations, veuillez consulter [Utilisation d'un astérisque (\$1) dans les noms des zones hébergées et des enregistrements](DomainNameFormat.md#domain-name-format-asterisk).

## Type de registre
<a name="rrsets-values-ibased-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur pour le champ **Type** en fonction de la façon dont vous voulez que Route 53 réponde aux requêtes DNS. 

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements basés sur IP.

## TTL (secondes)
<a name="rrsets-values-ibased-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d'appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l'enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une vérification de l'état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l'état de santé.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-ibased-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez [Valeur/acheminer le trafic vers](resource-record-sets-values-shared.md#rrsets-values-common-value) [valeurs communes pour Valeur/Acheminement du trafic vers](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Emplacement
<a name="rrsets-values-ibased-location"></a>

Le nom de l'emplacement CIDR où la ressource que vous avez spécifiée dans cet enregistrement est spécifiée par les valeurs de bloc d'adresse CIDR dans l'emplacement CIDR. 

Pour plus d'informations sur l'utilisation des enregistrements basés sur IP, consultez [Routage basé sur IP](routing-policy-ipbased.md). 

## Surveillance de l'état
<a name="rrsets-values-ibased-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias basés sur IP, d'alias de latence ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

## ID d'enregistrement
<a name="rrsets-values-ipbased-set-id"></a>

Saisissez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements basés sur l'IP.

# Valeurs spécifiques aux enregistrements d'alias basés sur IP
<a name="resource-record-sets-values-ipbased-alias"></a>

Lorsque vous créez des enregistrements d'alias basés sur l'IP, vous spécifiez les valeurs suivantes.

**Note**  
Bien que la création d'enregistrements d'alias basés sur IP dans une zone hébergée privée soit autorisée, elle n'est pas prise en charge.

Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-ipbased-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-ipbased-alias-name)
+ [Type de registre](#rrsets-values-ipbased-alias-type)
+ [Valeur/acheminer le trafic vers](#rrsets-values-ipbased-alias-alias-target)
+ [Location](#rrsets-values-ipbased-alias-location)
+ [Surveillance de l'état](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [Évaluer l'état de la cible](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [ID d’enregistrement](#rrsets-values-ipbased-alias-set-id)

## Stratégie de routage
<a name="rrsets-values-ipbased-alias-routing-policy"></a>

Choisissez **IP-based** (basé sur IP). 

**Note**  
Bien que la création d'enregistrements d'alias basés sur IP dans une zone hébergée privée soit autorisée, elle n'est pas prise en charge.

## Nom de l’enregistrement
<a name="rrsets-values-ipbased-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Saisissez le même nom pour tous les enregistrements du groupe d'enregistrements basés sur IP. 

**Enregistrements CNAME**  
Si vous créez un enregistrement dont la valeur est **CNAME** pour **Record type (Type d'enregistrement)**, le nom de l'enregistrement ne peut être identique à celui de la zone hébergée.

**Alias des CloudFront distributions et des compartiments Amazon S3**  
La valeur que vous spécifiez dépend en partie de la AWS ressource vers laquelle vous acheminez le trafic :  
+ **CloudFront distribution** — Votre distribution doit inclure un autre nom de domaine correspondant au nom de l'enregistrement. Par exemple, si le nom de l'enregistrement est **acme.example.com**, votre distribution CloudFront doit inclure **acme.example.com** parmi les autres noms de domaine. Pour plus d'informations, consultez la section [Utilisation de noms de domaine alternatifs (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) dans le manuel *Amazon CloudFront Developer Guide*. 
+ **Compartiment Amazon S3** : le nom de l'enregistrement doit correspondre au nom de votre compartiment Amazon S3. Par exemple, si le nom de votre compartiment est **acme.example.com**, le nom de cet enregistrement doit également être **acme.example.com**.

  En outre, vous devez configurer le compartiment pour l'hébergement de site web. Pour de plus amples informations, veuillez consulter la section [Configurer un compartiment pour l'hébergement de sites Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*. 

**Caractères spéciaux**  
Pour plus d'informations sur la spécification d'autres caractères que a-z, 0-9 et - (trait d'union), et de noms de domaine internationaux, consultez [Format de nom de domaine DNS](DomainNameFormat.md).

**Caractères génériques**  
Vous pouvez utiliser un astérisque (\$1) dans le nom. DNS traite le caractère \$1 comme un caractère générique ou comme le caractère \$1 (ASCII 42), en fonction de son emplacement dans le nom. Pour de plus amples informations, veuillez consulter [Utilisation d'un astérisque (\$1) dans les noms des zones hébergées et des enregistrements](DomainNameFormat.md#domain-name-format-asterisk).

## Type de registre
<a name="rrsets-values-ipbased-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic. Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements basés sur IP :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

## Valeur/acheminer le trafic vers
<a name="rrsets-values-ipbased-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez [les valeurs communes des enregistrements d'alias destinés au value/route trafic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la configuration de Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

## Location
<a name="rrsets-values-ipbased-alias-location"></a>

Lorsque vous configurez Route 53 pour qu'il réponde aux requêtes DNS en fonction de leur emplacement d'origine, sélectionnez l'emplacement CIDR pour lequel vous voulez que Route 53 réponde avec les paramètres figurant dans cet enregistrement.

**Important**  
Nous vous conseillons de créer un enregistrement basé sur IP ayant la valeur **Default** (Par défaut) pour **Location** (Emplacement). Ainsi, les emplacements pour lesquels vous n'avez pas créé d'enregistrements et les adresses IP dont Route 53 ne peut identifier l'emplacement sont couverts.

Vous ne pouvez pas créer d' non-IP-basedenregistrements dont les valeurs de **nom et de **type** d'enregistrement** sont les mêmes que celles des enregistrements basés sur l'adresse IP.

Pour de plus amples informations, veuillez consulter [Routage basé sur IP](routing-policy-ipbased.md).

## Surveillance de l'état
<a name="rrsets-values-ipbased-alias-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de routage basé sur IP, d'alias de latence ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

Pour les enregistrements d'alias basés sur IP, si un point de terminaison n'est pas en bon état, Route 53 recherche un enregistrement dans l'emplacement associé plus grand. Par exemple, supposons que vous disposez d'enregistrements pour un État des États-Unis, pour les États-Unis, pour l'Amérique du Nord et pour tous les emplacements (la valeur du champ **Location [Emplacement]** est **Default [Par défaut]**). Si le point de terminaison de l'enregistrement de l'État n'est pas sain, Route 53 vérifie les enregistrements pour les États-Unis, pour l'Amérique du Nord, ainsi que pour tous les emplacements, dans cet ordre, jusqu'à ce qu'il trouve un enregistrement comportant un point de terminaison sain. Si tous les enregistrements applicables sont défaillants, y compris l'enregistrement pour tous les emplacements, Route 53 répond à la requête DNS à l'aide de la valeur pour l'enregistrement de la région géographique la plus petite. 

## Évaluer l'état de la cible
<a name="rrsets-values-ipbased-alias-evaluate-target-health"></a>

Sélectionnez **Yes (Oui)** si vous voulez que Route 53 détermine s'il doit répondre aux requêtes DNS à l'aide de cet enregistrement en vérifiant l'état de la ressource spécifiée dans le champ **Endpoint (Point de terminaison)**. 

Notez ce qui suit :

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est une API régionale personnalisée API Gateway ou une API optimisée pour la périphérie.

**CloudFront distributions**  
Vous ne pouvez pas définir **Evaluate target health** sur **Oui** lorsque le point de terminaison est une CloudFront distribution.

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si vous spécifiez un **environnement** Elastic Beanstalk dans Endpoint et que celui-ci contient un équilibreur de charge ELB, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines enregistrées auprès de l'équilibreur de charge. (Un environnement contient automatiquement un équilibreur de charge ELB s'il inclut plusieurs EC2 instances Amazon.) Si vous définissez **Evaluate target health** sur **Oui** et que les EC2 instances Amazon ne sont pas saines ou que l'équilibreur de charge lui-même est défaillant, Route 53 achemine les requêtes vers d'autres ressources disponibles qui sont saines, le cas échéant.   
Si l'environnement contient une seule EC2 instance Amazon, il n'y a aucune exigence particulière.

**Equilibreurs de charge ELB**  
Le comportement de la surveillance de l'état dépend du type de l'équilibreur de charge :  
+ **Classic Load Balancers** : si vous spécifiez un ELB Classic Load Balancer **dans** Endpoint, Elastic Load Balancing achemine les requêtes uniquement vers les instances EC2 Amazon saines enregistrées auprès de l'équilibreur de charge. Si vous définissez **Evaluate target health sur** **Oui** et qu'aucune EC2 instance n'est saine ou que l'équilibreur de charge lui-même est défaillant, Route 53 achemine les requêtes vers d'autres ressources.
+ **Équilibreurs de charge d'application et Network Load Balancer** : si vous spécifiez un équilibreur de charge ELB d'application ou Network Load Balancer et que vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)**, Route 53 achemine les requêtes vers l'équilibreur de charge en fonction de l'état des groupes cible associés à l'équilibreur de charge :
  + Pour qu'un équilibreur d'application ou un équilibreur Network Load Balancer soit considéré comme sain, chaque groupe cible contenant des cibles doit en contenir au moins une saine. Si un groupe cible contient uniquement des cibles qui ne sont pas saines, l'équilibreur de charge est considéré comme étant lui-même défectueux et Route 53 achemine les requêtes vers d'autres ressources.
  + Un groupe cible qui n'a pas de cibles enregistrées est considéré comme non sain.
Lorsque vous créez un équilibreur de charge, vous configurez les paramètres des surveillances de l'état Elastic Load Balancing ; il ne s'agit pas de surveillances de l'état Route 53, mais elles jouent le même rôle. Ne créez pas de bilans de santé Route 53 pour les EC2 instances que vous enregistrez auprès d'un équilibreur de charge ELB. 

**Compartiments S3**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un compartiment S3.

**Points de terminaison de l'interface d'un VPC Amazon**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un point de terminaison d'interface d'un VPC Amazon.

**Autres enregistrements dans la même zone hébergée**  
Si la AWS ressource que vous spécifiez dans **Endpoint** est un enregistrement ou un groupe d'enregistrements (par exemple, un groupe d'enregistrements pondérés) mais qu'il ne s'agit pas d'un autre enregistrement alias, nous vous recommandons d'associer un bilan de santé à tous les enregistrements du point de terminaison. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous omettez des surveillances de l'état ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## ID d’enregistrement
<a name="rrsets-values-ipbased-alias-set-id"></a>

Saisissez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements basés sur l'IP.

# Valeurs spécifiques pour les enregistrements de réponses multivaleur
<a name="resource-record-sets-values-multivalue"></a>

Lorsque vous créez des enregistrements de réponse multivaleur, vous spécifiez les valeurs suivantes.

**Note**  
La création d'enregistrements d'alias de réponse multivaleur n'est pas prise en charge.

**Topics**
+ [Stratégie de routage](#rrsets-values-multivalue-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-multivalue-name)
+ [Type de registre](#rrsets-values-multivalue-type)
+ [TTL (secondes)](#rrsets-values-multivalue-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-multivalue-value)
+ [Surveillance de l'état](#rrsets-values-multivalue-associate-with-health-check)
+ [ID d’enregistrement](#rrsets-values-multivalue-set-identifier)

## Stratégie de routage
<a name="rrsets-values-multivalue-routing-policy"></a>

Choisissez **Multivalue answer (Réponse multivaleur)**.

## Nom de l’enregistrement
<a name="rrsets-values-multivalue-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements multi-valeurs. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Type de registre
<a name="rrsets-values-multivalue-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez n'importe quelle valeur à l'exception de **NS** ou **CNAME**.

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements de réponse à valeurs multiples.

## TTL (secondes)
<a name="rrsets-values-multivalue-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

**Note**  
Si vous créez deux ou plusieurs enregistrements de réponse multivaleur qui ont le même nom et le même type, que vous utilisez la console et que vous spécifiez des valeurs différentes pour le **TTL**, Route 53 change la valeur du **TTL** pour tous les enregistrements à la dernière valeur que vous avez spécifiée.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-multivalue-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Si vous entrez plusieurs valeurs, entrez chacune d'entre elles sur une ligne séparée.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Surveillance de l'état
<a name="rrsets-values-multivalue-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la vérification de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes (Oui)** pour **Evaluate target health (Évaluer l'état de la cible)** pour chercher un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias pondérés, d'alias de latence, d'alias de géolocalisation ou d'alias de basculement. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

## ID d’enregistrement
<a name="rrsets-values-multivalue-set-identifier"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements de réponse à valeurs multiples. 

# Valeurs spécifiques aux enregistrements pondérés
<a name="resource-record-sets-values-weighted"></a>

Lorsque vous créez des enregistrements pondérés, vous spécifiez les valeurs suivantes.

**Topics**
+ [Stratégie de routage](#rrsets-values-weighted-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-weighted-name)
+ [Type de registre](#rrsets-values-weighted-type)
+ [TTL (secondes)](#rrsets-values-weighted-ttl)
+ [Valeur/acheminer le trafic vers](#rrsets-values-weighted-value)
+ [Pondération](#rrsets-values-weighted-weight)
+ [Surveillance de l'état](#rrsets-values-weighted-associate-with-health-check)
+ [ID d’enregistrement](#rrsets-values-weighted-set-identifier)

## Stratégie de routage
<a name="rrsets-values-weighted-routing-policy"></a>

Sélectionnez **Weighted (Pondéré)**.

## Nom de l’enregistrement
<a name="rrsets-values-weighted-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Record name (Nom de l'enregistrement)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements pondérés. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Type de registre
<a name="rrsets-values-weighted-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements pondérés.

## TTL (secondes)
<a name="rrsets-values-weighted-ttl"></a>

Durée, en secondes, pendant laquelle vous voulez que les résolveurs DNS récursifs mettent en cache les informations relatives à cet enregistrement. Si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, soit deux jours), vous limitez le nombre d’appels que les résolveurs DNS récursifs doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Vous réduisez ainsi la latence et le montant de votre facture pour le service Route 53. Pour de plus amples informations, veuillez consulter [Comment Amazon Route 53 achemine le trafic de votre domaine](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

Cependant, si vous spécifiez une valeur de durée de vie plus longue, les modifications apportées à l’enregistrement (par exemple, une nouvelle adresse IP) mettent plus de temps à prendre effet, car les résolveurs récursifs utilisent les valeurs qui se trouvent dans leur cache pendant plus longtemps avant de demander les informations les plus récentes à Route 53. Si vous modifiez les paramètres d'un domaine ou d'un sous-domaine déjà utilisé, nous vous conseillons de spécifier initialement une valeur plus courte, par exemple 300 secondes, et d'augmenter la valeur une fois que vous avez vérifié que les nouveaux paramètres sont corrects.

Si vous associez cet enregistrement à une surveillance de l’état, nous vous recommandons de spécifier une durée de vie de 60 secondes au maximum afin que les clients répondent rapidement aux modifications de l’état de santé.

Vous devez indiquer la même valeur dans le champ **TTL (Durée de vie)** pour tous les enregistrements de ce groupe d'enregistrements pondérés.

**Note**  
Si vous créez plusieurs enregistrements pondérés qui possèdent le même nom et le même type, puis que vous spécifiez des valeurs différentes pour **TTL (Durée de vie)**, Route 53 remplace la valeur de **TTL** de tous les enregistrements par la dernière valeur que vous avez spécifiée.

Si un groupe d'enregistrements pondérés inclut un ou plusieurs enregistrements d'alias pondérés qui acheminent le trafic vers un équilibreur de charge ELB, nous vous recommandons de spécifier une durée de vie de 60 secondes pour tous les enregistrements pondérés sans alias ayant les mêmes nom et type. D'autres valeurs que 60 secondes (durée de vie pour les équilibreurs de charge) modifieront l'effet des valeurs que vous spécifiez pour le champ **Weight (Poids)**.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-weighted-value"></a>

Choisissez **IP address or another value depending on the record type (Adresse IP ou autre valeur selon le type d'enregistrement)**. Entrez une valeur appropriée pour la valeur **Record type (Type d'enregistrement)**. Pour tous les types à l'exception de **CNAME**, vous pouvez entrer plusieurs valeurs. Entrez chaque valeur sur une ligne distincte.

Vous pouvez acheminer le trafic vers, ou spécifier les valeurs suivantes :
+ **A — IPv4 adresse**
+ **AAAA — adresse IPv6 **
+ **CAA : autorisation de l'autorité de certification**
+ **CNAME : nom canonique**
+ **MX : échange de courrier**
+ **NAPTR : nom d'indicateur d'autorité**
+ **PTR : indicateur**
+ **SPF : cadre de la politique de l'envoyeur**
+ **SRV : localisateur de service**
+ **TXT : texte**

Pour plus d'informations sur les valeurs ci-dessus, consultez la section [Valeurs communes pour le Value/Route trafic à destination de](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Pondération
<a name="rrsets-values-weighted-weight"></a>

Valeur qui détermine la proportion de requêtes DNS auxquelles Route 53 répond à l’aide de l’enregistrement actuel. Route 53 calcule la somme des pondérations pour les enregistrements qui ont la même combinaison de type et de nom DNS. Route 53 répond ensuite aux requêtes en fonction du rapport entre le poids d'une ressource et le total. 

Vous ne pouvez pas créer des enregistrements qui ne sont pas de type pondéré en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements pondérés.

Entrez un entier compris entre 0 et 255. Pour désactiver le routage vers une ressource, définissez le champ **Weight (Poids)** sur 0. Si vous définissez le champ **Weight (Poids)** sur 0 pour tous les enregistrements du groupe, le trafic est acheminé vers toutes les ressources avec une probabilité égale. Ainsi, vous ne pouvez pas désactiver accidentellement le routage pour un groupe d’enregistrements pondérés.

La définition du champ **Weight (Poids)** sur 0 produit un autre effet lorsque vous associez des vérifications de l'état à des enregistrements pondérés. Pour de plus amples informations, veuillez consulter [Choix des enregistrements par Amazon Route 53 lorsque la surveillance de l'état est configuréeChoix des enregistrements par Route 53 lorsque la surveillance de l'état est configurée](health-checks-how-route-53-chooses-records.md).

## Surveillance de l'état
<a name="rrsets-values-weighted-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP, ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

## ID d’enregistrement
<a name="rrsets-values-weighted-set-identifier"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements pondérés.

# Valeurs spécifiques aux enregistrements d'alias pondérés
<a name="resource-record-sets-values-weighted-alias"></a>

Lorsque vous créez des enregistrements d'alias pondérés, vous spécifiez les valeurs suivantes. Pour de plus amples informations, veuillez consulter [Choix entre des enregistrements avec ou sans alias](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [Stratégie de routage](#rrsets-values-weighted-alias-routing-policy)
+ [Nom de l’enregistrement](#rrsets-values-weighted-alias-name)
+ [Type de registre](#rrsets-values-weighted-alias-type)
+ [Valeur/acheminer le trafic vers](#rrsets-values-weighted-alias-alias-target)
+ [Pondération](#rrsets-values-weighted-alias-weight)
+ [Surveillance de l'état](#rrsets-values-weighted-alias-associate-with-health-check)
+ [Évaluer l'état de la cible](#rrsets-values-weighted-alias-evaluate-target-health)
+ [ID d’enregistrement](#rrsets-values-weighted-alias-set-identifier)

## Stratégie de routage
<a name="rrsets-values-weighted-alias-routing-policy"></a>

Choisissez **Weighted (Pondéré)**.

## Nom de l’enregistrement
<a name="rrsets-values-weighted-alias-name"></a>

Saisissez le nom de domaine ou de sous-domaine vers lequel vous souhaitez acheminer le trafic. La valeur par défaut est le nom de la zone hébergée. 

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ **Name (Nom)**. 

Entrez le même nom pour tous les enregistrements du groupe d'enregistrements pondérés. 

Pour plus d'informations sur les noms d'enregistrements, veuillez consulter [Nom de l’enregistrement](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)

## Type de registre
<a name="rrsets-values-weighted-alias-type"></a>

Type d'enregistrement DNS. Pour de plus amples informations, veuillez consulter [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

Sélectionnez la valeur applicable en fonction de la AWS ressource vers laquelle vous acheminez le trafic :

**API régionale personnalisée API Gateway et API optimisée pour la périphérie**  
Sélectionnez **A — IPv4 adresse**.

**Points de terminaison de l'interface d'un VPC Amazon**  
Sélectionnez **A — IPv4 adresse**.

**CloudFront distribution**  
Sélectionnez **A — IPv4 adresse**.  
Si cette option IPv6 est activée pour la distribution, créez deux enregistrements, l'un avec la valeur **A — IPv4 adresse** pour **Type**, et l'autre avec la valeur **AAAA — IPv6 adresse**.

**Service App Runner**  
Sélectionnez **A — IPv4 adresse**

**Environnement Elastic Beanstalk comportant des sous-domaines régionalisés**  
Sélectionnez **A — IPv4 adresse**

**Équilibreur de charge ELB**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Compartiment Amazon S3**  
Sélectionnez **A — IPv4 adresse**

**OpenSearch Service**  
Sélectionnez **A — IPv4 adresse** ou **AAAA — IPv6 ** adresse

**Autre enregistrement de cette zone hébergée**  
Sélectionnez le type d'enregistrement pour lequel vous créez l'alias. Tous les types sont pris en charge, sauf **NS** et **SOA**.  
Si vous créez un enregistrement d'alias qui a le même nom que la zone hébergée (appelée aussi *zone apex*), vous ne pouvez pas acheminer le trafic vers un enregistrement dont la valeur pour **Type (Type)** est **CNAME**. Cela est dû au fait que l'enregistrement d'alias doit être du même type que l'enregistrement vers lequel vous acheminez le trafic et que la création d'un enregistrement CNAME pour la zone apex n'est pas prise en charge, même pour un enregistrement d'alias. 

Sélectionnez la même valeur pour tous les enregistrements du groupe d'enregistrements pondérés.

## Valeur/acheminer le trafic vers
<a name="rrsets-values-weighted-alias-alias-target"></a>

La valeur que vous choisissez dans la liste ou que vous saisissez dans le champ dépend de la AWS ressource vers laquelle vous acheminez le trafic.

Pour plus d'informations sur AWS les ressources que vous pouvez cibler, consultez [les valeurs communes des enregistrements d'alias destinés au value/route trafic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

Pour plus d'informations sur la façon de configurer Route 53 pour acheminer le trafic vers des AWS ressources spécifiques, consultez[Acheminement du trafic Internet vers vos AWS ressources](routing-to-aws-resources.md).

## Pondération
<a name="rrsets-values-weighted-alias-weight"></a>

Valeur qui détermine la proportion de requêtes DNS auxquelles Route 53 répond à l’aide de l’enregistrement actuel. Route 53 calcule la somme des pondérations pour les enregistrements qui ont la même combinaison de type et de nom DNS. Route 53 répond ensuite aux requêtes en fonction du rapport entre le poids d'une ressource et le total. 

Vous ne pouvez pas créer des enregistrements qui ne sont pas de type pondéré en utilisant les mêmes valeurs pour les champs **Record name (Nom de l'enregistrement)** et **Record type (Type d'enregistrement)** que celles des enregistrements pondérés.

Entrez un entier compris entre 0 et 255. Pour désactiver le routage vers une ressource, définissez le champ **Weight (Poids)** sur 0. Si vous définissez le champ **Weight (Poids)** sur 0 pour tous les enregistrements du groupe, le trafic est acheminé vers toutes les ressources avec une probabilité égale. Ainsi, vous ne pouvez pas désactiver accidentellement le routage pour un groupe d’enregistrements pondérés.

La définition du champ **Weight (Poids)** sur 0 produit un autre effet lorsque vous associez des vérifications de l'état à des enregistrements pondérés. Pour de plus amples informations, veuillez consulter [Choix des enregistrements par Amazon Route 53 lorsque la surveillance de l'état est configuréeChoix des enregistrements par Route 53 lorsque la surveillance de l'état est configurée](health-checks-how-route-53-chooses-records.md).

## Surveillance de l'état
<a name="rrsets-values-weighted-alias-associate-with-health-check"></a>

Sélectionnez une surveillance de l'état si vous voulez que Route 53 vérifie l'état d'un point de terminaison spécifique et réponde aux requêtes DNS à l'aide de cet enregistrement uniquement lorsque le point de terminaison est sain. 

Route 53 ne vérifie pas l'état du point de terminaison spécifié dans l'enregistrement, par exemple, le point de terminaison indiqué par l'adresse IP dans le champ **Value (Valeur)**. Lorsque vous sélectionnez une surveillance de l'état pour un enregistrement, Route 53 vérifie l'état du point de terminaison que vous avez spécifié dans la surveillance de l'état. Pour plus d'informations sur la façon dont Route 53 détermine si un point de terminaison est sain, consultez [Comment Amazon Route 53 détermine si une surveillance de l'état est saineComment Route 53 détermine si une surveillance de l'état est saine](dns-failover-determining-health-of-endpoints.md).

L'association d'une surveillance de l'état à un enregistrement est utile uniquement lorsque Route 53 doit choisir entre plusieurs enregistrements pour répondre à une requête DNS et que vous souhaitez que Route 53 base en partie son choix sur le statut d'une surveillance de l'état. Utilisez des surveillances de l'état uniquement dans les configurations suivantes :
+ Vous vérifiez l'état de santé de tous les enregistrements d'un groupe d'enregistrements portant le même nom, le même type et la même politique de routage (tels que le basculement ou les enregistrements pondérés), et vous spécifiez un contrôle de santé IDs pour tous les enregistrements. Si la surveillance de l'état d'un enregistrement spécifie un point de terminaison qui n'est pas sain, Route 53 cesse de répondre aux requêtes utilisant la valeur indiquée pour cet enregistrement.
+ Vous sélectionnez **Yes** (Oui) pour **Evaluate target health** (Évaluer l'état de la cible) pour un enregistrement d'alias ou les enregistrements dans un groupe d'enregistrements d'alias de basculement, d'alias de géolocalisation, d'alias de latence, d'alias basés sur IP, ou d'alias pondérés. Si les enregistrements d'alias font référence à des enregistrements sans alias dans une même zone hébergée, vous devez spécifier les surveillances d'état pour les enregistrements référencés. Si vous associez une surveillance de l'état à un enregistrement d'alias et que vous sélectionnez également **Yes** (Oui) pour **Evaluate Target Health** (Évaluer l'état de la cible), les deux doivent être évalués à vrai. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous associez une surveillance de l'état à un enregistrement d'alias ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

Si vos surveillances de l'état spécifient le point de terminaison uniquement par nom de domaine, nous vous recommandons de créer une surveillance de l'état distincte pour chaque point de terminaison. Par exemple, créez une surveillance de l'état pour chaque serveur HTTP qui diffuse du contenu pour www.example.com. Pour la valeur du champ **Domain name (Nom de domaine)**, indiquez le nom de domaine du serveur (par exemple, us-east-2-www.example.com), et non pas le nom des enregistrements (example.com).

**Important**  
Dans cette configuration, si vous créez une vérification de l'état pour laquelle la valeur du champ **Domain name (Nom de domaine)** correspond au nom des enregistrements et si vous associez ensuite la vérification de l'état à ces enregistrements, les résultats de la vérification de l'état seront imprévisibles.

## Évaluer l'état de la cible
<a name="rrsets-values-weighted-alias-evaluate-target-health"></a>

Sélectionnez **Yes (Oui)** si vous voulez que Route 53 détermine s'il doit répondre aux requêtes DNS à l'aide de cet enregistrement en vérifiant l'état de la ressource spécifiée dans le champ **Endpoint (Point de terminaison)**. 

Notez ce qui suit :

**API Gateway personnalisé, régional APIs et optimisé pour les périphériques APIs**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est une API régionale personnalisée API Gateway ou une API optimisée pour la périphérie.

**CloudFront distributions**  
Vous ne pouvez pas définir **Evaluate target health** sur **Oui** lorsque le point de terminaison est une CloudFront distribution.

**Environnements Elastic Beanstalk comportant des sous-domaines régionalisés**  
Si vous spécifiez un environnement Elastic Beanstalk dans **Endpoint (Point de terminaison)** et que l'environnement contient un équilibreur de charge ELB, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. (Un environnement contient automatiquement un équilibreur de charge ELB s'il inclut plusieurs instances Amazon EC2.) Si vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance Amazon EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources disponibles saines, le cas échéant.   
Si l'environnement contient une seule instance Amazon EC2, il n'y a aucune exigence particulière.

**Equilibreurs de charge ELB**  
Le comportement de la surveillance de l'état dépend du type de l'équilibreur de charge :  
+ **Équilibreurs Classic Load Balancer** : si vous spécifiez un équilibreur Classic Load Balancer ELB dans **Endpoint (Point de terminaison)**, Elastic Load Balancing achemine les requêtes uniquement vers les instances Amazon EC2 saines qui sont enregistrées auprès de l'équilibreur de charge. Si vous définissez le champ **Evaluate Target Health (Évaluer l'état de la cible)** sur **Yes (Oui)** et qu'aucune instance EC2 n'est saine ou que l'équilibreur de charge lui-même est défectueux, Route 53 achemine les requêtes vers d'autres ressources.
+ **Équilibreurs de charge d'application et Network Load Balancer** : si vous spécifiez un équilibreur de charge ELB d'application ou Network Load Balancer et que vous définissez **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)**, Route 53 achemine les requêtes vers l'équilibreur de charge en fonction de l'état des groupes cible associés à l'équilibreur de charge :
  + Pour qu'un équilibreur d'application ou un équilibreur Network Load Balancer soit considéré comme sain, chaque groupe cible contenant des cibles doit en contenir au moins une saine. Si un groupe cible contient uniquement des cibles qui ne sont pas saines, l'équilibreur de charge est considéré comme étant lui-même défectueux et Route 53 achemine les requêtes vers d'autres ressources.
  + Un groupe cible qui n'a pas de cibles enregistrées est considéré comme non sain.
Lorsque vous créez un équilibreur de charge, vous configurez les paramètres des surveillances de l'état Elastic Load Balancing ; il ne s'agit pas de surveillances de l'état Route 53, mais elles jouent le même rôle. Ne créez pas de surveillances de l'état Route 53 pour les instances EC2 que vous enregistrez auprès d'un équilibreur de charge ELB. 

**Compartiments S3**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un compartiment S3.

**Points de terminaison de l'interface d'un VPC Amazon**  
Il n'y a aucune exigence spécifique pour la définition du champ **Evaluate target health (Évaluer l'état de la cible)** sur **Yes (Oui)** lorsque le point de terminaison est un point de terminaison d'interface d'un VPC Amazon.

**Autres enregistrements dans la même zone hébergée**  
Si la AWS ressource que vous spécifiez dans **Endpoint** est un enregistrement ou un groupe d'enregistrements (par exemple, un groupe d'enregistrements pondérés) mais qu'il ne s'agit pas d'un autre enregistrement alias, nous vous recommandons d'associer un bilan de santé à tous les enregistrements du point de terminaison. Pour de plus amples informations, veuillez consulter [Que se passe-t-il lorsque vous omettez des surveillances de l'état ?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## ID d’enregistrement
<a name="rrsets-values-weighted-alias-set-identifier"></a>

Entrez une valeur qui identifie de manière unique cet enregistrement dans le groupe d'enregistrements pondérés.

# Création d'enregistrements par importation d'un fichier de zone
<a name="resource-record-sets-creating-import"></a>

Si vous migrez à partir d'un autre fournisseur de services DNS, et si votre fournisseur de services DNS actuel vous permet d'exporter vos paramètres DNS actuels dans un fichier de zone, vous pouvez rapidement créer tous les enregistrements pour une zone hébergée Amazon Route 53 en important un fichier de zone.

**Note**  
Un fichier de zone utilise un format standard appelé BIND pour représenter les enregistrements au format texte. Pour plus d'informations sur le format d'un fichier de zone, consultez l'entrée Wikipedia [Zone file](https://en.wikipedia.org/wiki/Zone_file). Des informations supplémentaires sont disponibles dans la section 3.6.1 [RFC 1034, Noms de domaine — Concepts et installations](https://datatracker.ietf.org/doc/html/rfc1034) et la section 5 [RFC 1035, Noms de domaine — Implémentation et spécification](https://datatracker.ietf.org/doc/html/rfc1035). 

Si vous souhaitez créer des enregistrements en important un fichier de zone, veuillez noter les points suivants :
+ Le format du fichier de zone doit être conforme à la norme RFC.
+ Le nom de domaine des enregistrements du fichier de zone doit correspondre au nom de la zone hébergée.
+ Route 53 prend en charge les mots-clés `$ORIGIN` et `$TTL`. Si le fichier de zone comprend les mots-clés `$GENERATE` ou `$INCLUDE`, l'importation échoue et Route 53 renvoie une erreur.
+ Lorsque vous importez le fichier de zone, Route 53 ignore l'enregistrement SOA dans le fichier de zone. Route 53 ignore également les enregistrements NS ayant le même nom que la zone hébergée.
+ Vous pouvez importer un maximum de 1000 enregistrements.
+ Si la zone hébergée contient déjà des enregistrements qui apparaissent dans le fichier de zone, le processus d'importation échoue et aucun enregistrement n'est créé.
+ Pour les enregistrements TXT contenant des barres obliques inversées, le processus d'importation du fichier de zone interprète certaines séquences de barres obliques inversées comme des caractères de contrôle. Pour inclure des barres obliques inverses littérales dans les valeurs d'enregistrement TXT :
  + Utilisez des barres obliques inverses (`\\\\`) dans le fichier de zone pour représenter une seule barre oblique inverse littérale dans l'enregistrement TXT final.
  + Par exemple, si votre enregistrement TXT doit contenir `\\jYTDWqH...` (avec une barre oblique inverse littérale et j), spécifiez-le `\\\\jYTDWqH...` dans le fichier de zone.

  Cela est particulièrement important pour les enregistrements de défis ACME et les autres enregistrements TXT contenant des barres obliques inverses littérales.
+ Pour les longs enregistrements TXT (tels que les enregistrements DKIM), le processus d'importation des fichiers de zone permet de diviser le contenu en plusieurs chaînes. Pour créer des enregistrements TXT contenant plusieurs chaînes, procédez comme suit :
  + Utilisez des lignes distinctes dans votre fichier de zone portant le même nom et le même type d'enregistrement.  
**Example**  

    ```
    example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
    example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
    example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
    ```

  Le processus d'importation les combine automatiquement en un seul enregistrement TXT avec plusieurs chaînes. Chaque chaîne individuelle peut contenir jusqu'à 65 535 caractères. Ne concaténez pas de longues chaînes en une seule valeur entre guillemets.
+ Nous vous recommandons de vérifier le contenu du fichier de zone pour vous assurer que les noms d'enregistrements incluent ou excluent un point final, le cas échéant :
  + Lorsque le nom d'un enregistrement du fichier de zone comprend un point final (`example.com.`), le processus d'importation l'interprète comme un nom de domaine complet et crée un enregistrement Route 53 avec le même nom.
  + Lorsque le nom d'un enregistrement du fichier de zone n'inclut pas de point final (`www`), le processus d'importation concatène ce nom avec le nom de domaine du fichier de zone (`example.com`) et crée un enregistrement Route 53 avec le nom concaténé (`www.example.com`).

  Si le processus d'exportation n'ajoute pas de point final aux noms de domaine complets d'un enregistrement, le processus d'importation Route 53 ajoute le nom de domaine au nom de l'enregistrement. Supposons par exemple que vous importez des enregistrements dans la zone hébergée `example.com` et que le nom d'un enregistrement MX dans le fichier de zone est `mail.example.com`, sans point final. Le processus d'importation Route 53 crée un enregistrement MX nommé `mail.example.com.example.com`.
**Important**  
Pour les enregistrements CNAME, MX, PTR et SRV, ce comportement s'applique également au nom de domaine qui est inclus dans la valeur RDATA. Supposons par exemple que vous avez un fichier de zone pour `example.com`. Si un enregistrement CNAME du fichier de zone (`support`, sans point final) comporte une valeur RDATA `www.example.com` (également sans point final), le processus d'importation crée un enregistrement Route 53 nommé `support.example.com` qui achemine le trafic vers `www.example.com.example.com`. Avant d'importer votre fichier de zone, consultez les valeurs RDATA et procédez à la mise à jour nécessaire. Pour les enregistrements TXT contenant des barres obliques inverses, utilisez des barres obliques inverses doubles (`\\\\`) dans le fichier de zone pour représenter des barres obliques inverses littérales.

Route 53 ne prend pas en charge l'exportation d'enregistrements vers un fichier de zone.

**Note**  
Si vous créez un enregistrement qui porte le même nom que la zone hébergée, n'entrez aucune valeur (par exemple, un symbole @) dans le champ Name (Nom).<a name="RRSchanges_import_console_procedure"></a>

**Pour créer des enregistrements par importation d'un fichier de zone**

1. Obtenez un fichier de zone auprès du fournisseur de services DNS actuellement en charge du domaine. Les processus et la terminologie varient d'un fournisseur de service à l'autre. Reportez-vous à l'interface et la documentation du fournisseur pour obtenir des informations sur l'exportation ou l'enregistrement de vos données dans un fichier de zone ou dans un fichier BIND.

   Si le processus n'est pas évident, demandez au service client de votre fournisseur DNS actuel de vous communiquer les informations relatives à votre *liste d'enregistrements* ou à votre *fichier de zone*.

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Sur la page **Hosted zones (Zones hébergées)**, créez une zone hébergée :

   1. Choisissez **Create Hosted Zone (Créer une zone hébergée)**.

   1. Entrez le nom de votre domaine et, le cas échéant, un commentaire. 

   1. Sélectionnez **Create (Créer)**.

1. Choisissez **Import Zone File (Importer un fichier de zone)**.

1. Dans le volet **Import Zone File (Importer un fichier de zone)**, collez le contenu de votre fichier de zone dans la zone de texte **Zone file (Fichier de zone)**.

1. Choisissez **Import (Importer)**.
**Note**  
En fonction du nombre d'enregistrements dans votre fichier de zone, la création des enregistrements peut prendre quelques minutes.

1. Si vous utilisez un autre service DNS pour le domaine (ce qui est courant lorsque vous avez enregistré le domaine avec un autre bureau), migrez le service DNS vers Route 53. Lorsque cette étape est terminée, votre bureau d'enregistrement commence à identifier Route 53 en tant que service DNS en réponse aux requêtes DNS pour votre domaine, et les requêtes commencent à être envoyées vers des serveurs DNS Route 53. (En règle générale, un délai d'un jour ou deux est nécessaire avant que les requêtes DNS commencent à être acheminées vers Route 53, car les informations relatives à votre service DNS précédent sont mises en cache sur des résolveurs DNS pendant cette durée.) Pour de plus amples informations, veuillez consulter [Configuration d'Amazon Route 53 en tant que service DNS d'un domaine existantFaire de Route 53 le service DNS d'un domaine existant](MigratingDNS.md).

# Modification des enregistrements
<a name="resource-record-sets-editing"></a>

La procédure suivante explique comment modifier des enregistrements à l'aide de la console Amazon Route 53. Pour plus d'informations sur la façon de modifier des enregistrements à l'aide de l'API Route 53, consultez [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)la *référence de l'API Amazon Route 53*.

**Note**  
La propagation de vos registres modifiés sur les serveurs DNS Route 53 n'est pas immédiate. À l'heure actuelle, le seul moyen de vérifier que les modifications se sont propagées consiste à utiliser l'action [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Les changements se propagent généralement sur tous les serveurs de Route 53 en 60 secondes.<a name="resource-record-sets-editing-procedure"></a>

**Pour modifier des enregistrements à l'aide de la console Route 53**

1. Si vous ne modifiez pas des enregistrements d'alias, passez à l'étape 2. 

   Si vous modifiez des enregistrements d'alias qui acheminent le trafic vers un Classic Load Balancer Elastic Load Balancing, Application Load Balancer ou Network Load Balancer, et si vous avez créé votre zone hébergée Route 53 et votre équilibreur de charge à l'aide de différents comptes, exécutez la procédure [Obtention du nom DNS d'un équilibreur de charge Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) pour obtenir le nom DNS de l'équilibreur de charge. 

   Si vous modifiez des enregistrements d'alias pour une autre AWS ressource, passez à l'étape 2.

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Sur la page **Hosted Zones (Zones hébergées)**, choisissez sur la ligne de la zone hébergée qui contient les enregistrements que vous souhaitez modifier.

1. Sélectionnez la ligne de l'enregistrement que vous voulez modifier, puis entrez vos modifications dans le panneau **Edit record (Modifier l'enregistrement)**.

1. Entrez les valeurs applicables. Pour de plus amples informations, veuillez consulter [Valeurs à spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53](resource-record-sets-values.md). 

1. Sélectionnez **Save Changes (Enregistrer les modifications)**.

1. Si vous modifiez plusieurs enregistrements, répétez les étapes 5 à 7.

# Suppression d'enregistrements
<a name="resource-record-sets-deleting"></a>

La procédure suivante explique comment supprimer des enregistrements à l'aide de la console Route 53. Pour plus d'informations sur la façon de supprimer des enregistrements à l'aide de l'API Route 53, consultez [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)la *référence de l'API Amazon Route 53*.

**Note**  
La propagation de vos registres modifiés sur les serveurs DNS Route 53 n'est pas immédiate. À l'heure actuelle, le seul moyen de vérifier que les modifications se sont propagées consiste à utiliser l'action [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Les changements se propagent généralement sur tous les serveurs de Route 53 en 60 secondes.<a name="resource-record-sets-deleting-procedure"></a>

**Pour supprimer des enregistrements**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Sur la page Hosted Zones (Zones hébergées), choisissez la ligne de la zone hébergée qui contient les enregistrements que vous souhaitez supprimer. 

1. Dans la liste des enregistrements, sélectionnez l'enregistrement que vous voulez supprimer.

   Pour sélectionner plusieurs enregistrements consécutifs, sélectionnez la première ligne, maintenez la touche **Maj**, puis sélectionnez la dernière ligne. Pour sélectionner plusieurs enregistrements non consécutifs, choisissez la première ligne, maintenez la touche **Ctrl** enfoncée, puis choisissez les autres lignes. 

   Vous ne pouvez pas supprimer les registres dont la valeur est **NS** ou **SOA** pour le champ **Type**.

1. Sélectionnez **Delete (Supprimer)**.

1. Choisissez **Delete (Supprimer)** pour fermer la boîte de dialogue.

# Liste des enregistrements
<a name="resource-record-sets-listing"></a>

La procédure suivante explique comment utiliser la console Amazon Route 53 pour répertorier les enregistrements d'une zone hébergée. Pour plus d'informations sur la façon de répertorier des enregistrements à l'aide de l'API Route 53, consultez [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)le manuel de *référence de l'API Amazon Route 53*. 

**Pour lister des enregistrements**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Zones hébergées**.

1. Sur la page **Hosted Zones (Zones hébergées)**, choisissez le nom d'une zone hébergée.

1. Pour changer le mode de recherche, choisissez l'icône d'engrenage en haut à droite du tableau **Enregistrements**. Choisissez-en parmi :
   + **Automatique**

     Dans ce mode, le service utilise un filtre basé sur un certain nombre d'enregistrements. Complet pour moins de 2000 et rapide pour plus de 2000 enregistrements.
   + **Complet**

     Dans ce mode, tous les filtres de recherche sont disponibles, mais les performances de recherche peuvent être plus lentes.
   + **Rapide**

     Dans ce mode, certaines fonctionnalités avancées ne sont pas disponibles, mais les performances de recherche seront plus rapides.

Pour afficher uniquement les enregistrements sélectionnés, entrez les critères de recherche applicables au-dessus de la liste des enregistrements. En mode automatique, le comportement de recherche varie selon que la zone hébergée contient jusqu'à 2000 enregistrements ou plus de 2 000 enregistrements :

**Jusqu'à 2000 enregistrements et mode complet**  
+ Pour afficher les enregistrements ayant des valeurs spécifiques, entrez une valeur dans la barre de recherche et appuyez sur **Entrée**. Par exemple, pour afficher les enregistrements dont l'adresse IP commence par **192.0**, entrez cette valeur dans le champ **Search (Recherche)** et appuyez sur **Entrée**.
+ Pour afficher uniquement les enregistrements ayant le même type d'enregistrement DNS, sélectionnez le **Record type (Type d'enregistrement)** dans la liste déroulante et saisissez le type d'enregistrement. 
+ Pour afficher uniquement les registres d'alias, sélectionnez **Alias** dans la liste déroulante, puis saisissez **Yes**.
+ Pour afficher uniquement les enregistrements pondérés, sélectionnez **Routing policy (Stratégie de routage)** dans la liste déroulante, puis entrez **WEIGHTED**.

**Plus de 2000 enregistrements et mode rapide**  
+ Vous pouvez effectuer des recherches uniquement sur les noms d'enregistrement, et non sur les valeurs d'enregistrements. De même, vous ne pouvez pas filtrer en fonction du type d'enregistrement, ou sur l'alias ou sur les enregistrements pondérés.

  Pour ce faire, placez votre curseur dans la zone de texte **Filtre**, sélectionnez **Propriétés**, puis **Nom de l'enregistrement**.
+ Pour les enregistrements ayant trois étiquettes (trois parties séparées par des points), lorsque vous saisissez une valeur dans le champ de recherche et appuyez sur **Entrée**, la console Route 53 effectue automatiquement une recherche de caractère générique sur la troisième étiquette à partir de la droite dans le nom d'enregistrement. Par exemple, supposons que la zone hébergée example.com contienne 100 enregistrements appelés record1.example.com jusqu'à record100.example.com. (Record1 est la troisième étiquette à partir de la droite.) Voici ce qui se produit lorsque vous effectuez une recherche sur les valeurs suivantes :
  + **record1** : la console Route 53 recherche **record1\$1. example.com**, qui renvoie **record1.example.com**, **record10.example.com** jusqu'à **record19.example.com** et **record100.example.com**.
  + **record1.example.com** : comme dans l'exemple précédent, la console recherche **record1\$1. example.com** et renvoie les mêmes enregistrements.
  + **1 :**: la console recherche **1\$1.example.com** et ne renvoie aucun enregistrement.
  + **example** : la console recherche **example\$1.example.com** et ne renvoie aucun enregistrement.
  + **example.com** : dans cet exemple, la console n'effectue pas de recherche de caractère générique. Elle renvoie tous les enregistrements de la zone hébergée.
  + **Mode de recherche automatique** : lorsque vous utilisez ce mode de recherche, vous devez d'abord fournir une propriété, comme le nom de l'enregistrement, pour pouvoir effectuer la recherche.
**Note**  
Si la troisième étiquette à partir de la droite contient un ou plusieurs traits d'union (comme `third-label.example.com`), et si vous recherchez la partie de la troisième étiquette immédiatement avant le trait d'union (`third` dans cet exemple), Route 53 ne renverra aucun enregistrement. Au lieu de cela, incluez le trait d'union (recherchez `third-`) ou omettez le caractère situé immédiatement avant le trait d'union (recherchez `third`).
+ Pour les enregistrements qui ont quatre étiquettes ou plus, vous devez spécifier le nom exact de l'enregistrement. Aucune recherche générique n'est prise en charge. Par exemple, si la zone hébergée inclut un enregistrement appelé label4.record1.example.com, vous pouvez trouver cet enregistrement uniquement si vous spécifiez **label4.record1.example.com** dans le champ de recherche.

# Configuration de la signature DNSSEC dans Amazon Route 53
<a name="dns-configuring-dnssec"></a>

La signature DNSSEC (Domain Name System Security Extensions) permet aux résolveurs DNS de valider qu'une réponse DNS provient d'Amazon Route 53 et qu'elle n'a pas été altérée. Lorsque vous utilisez la signature DNSSEC, chaque réponse pour une zone hébergée est signée à l'aide du chiffrement par clé publique. Pour un aperçu du DNSSEC, consultez la section DNSSEC de [AWS re:Invent 2021 - Amazon Route 53](https://www.youtube.com/watch?v=77V23phAaAE) : A year in review.

Dans ce chapitre, nous expliquons comment activer la signature DNSSEC pour Route 53, comment utiliser les clés de signature par clé (KSKs) et comment résoudre les problèmes. Vous pouvez utiliser la signature DNSSEC dans l'API AWS Management Console ou par programmation. Pour plus d'informations sur l'utilisation de la CLI ou SDKs sur l'utilisation de Route 53, consultez[Configurer Amazon Route 53](setting-up-route-53.md).

Avant d'activer la signature DNSSEC, prenez les éléments suivants en considération :
+ Pour éviter une panne de zone et éviter que votre domaine ne devienne indisponible, vous devez rapidement corriger et résoudre les erreurs DNSSEC. Nous vous recommandons vivement de configurer une CloudWatch alarme qui vous avertira chaque fois qu'une `DNSSECInternalFailure` `DNSSECKeySigningKeysNeedingAction` erreur est détectée. Pour de plus amples informations, veuillez consulter [Surveillance des zones hébergées à l'aide d'Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Il existe deux types de clés dans DNSSEC : une clé KSK et une clé ZSK. Dans la signature DNSSEC Route 53, chaque clé KSK est basée sur une [clé asymétrique gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) dans AWS KMS que vous possédez. Vous êtes responsable de la gestion des clés KSK, ce qui inclut la rotation, le cas échéant. La gestion des ZSK est assurée par Route 53.
+ Lorsque vous activez la signature DNSSEC pour une zone hébergée, Route 53 limite la TTL à une semaine. Si vous définissez une TTL de plus d'une semaine pour les registres dans la zone hébergée, vous n'obtenez pas d'erreur. Cependant, la Route 53 applique une TTL d'une semaine pour les registres. Les registres dont la TTL est inférieure à une semaine et les registres dans d'autres zones hébergées pour lesquelles la signature DNSSEC n'est pas activée ne sont pas affectés. 
+ Lorsque vous utilisez la signature DNSSEC, les configurations multi-fournisseurs ne sont pas prises en charge. Si vous avez configuré des serveurs de noms en marque blanche (également appelés serveurs de noms personnalisés ou serveurs de noms privés), assurez-vous que ces serveurs de noms sont fournis par un seul fournisseur DNS.
+ Certains fournisseurs de DNS ne prennent pas en charge les enregistrements DS (Delegation Signer) dans leur DNS officiel. Si votre zone parent est hébergée par un fournisseur DNS qui ne prend pas en charge les requêtes DS (sans définir d'indicateur AA dans la réponse aux requêtes DS), lorsque vous activez DNSSEC dans sa zone enfant, la zone enfant ne peut plus être résolue. Assurez-vous que votre fournisseur DNS prend en charge les enregistrements DS.
+ Il peut être utile de configurer des autorisations IAM pour permettre à un autre utilisateur, outre le propriétaire de la zone, d'ajouter ou de supprimer des registres dans la zone. Par exemple, un propriétaire de zone peut ajouter une clé KSK et activer la signature, et peut également être responsable de la rotation des clés. Toutefois, une autre personne peut être responsable de l'utilisation d'autres registres pour la zone hébergée. Pour consulter un exemple de politique IAM, consultez [Exemples d'autorisations pour un propriétaire d'enregistrement de domaine](access-control-managing-permissions.md#example-permissions-record-owner).
+ Pour vérifier si le TLD prend en charge le protocole DNSSEC, consultez. [Domaines que vous pouvez vous enregistrer avec Amazon Route 53](registrar-tld-list.md)

**Topics**
+ [Activation de la signature DNSSEC et établissement d'une chaîne d'approbation](dns-configuring-dnssec-enable-signing.md)
+ [Désactivation de la signature DNSSEC](dns-configuring-dnssec-disable.md)
+ [Utilisation des clés gérées par le client pour DNSSEC](dns-configuring-dnssec-cmk-requirements.md)
+ [Utilisation de clés de signature () KSKs](dns-configuring-dnssec-ksk.md)
+ [Gestion des clés KMS et ZSK dans Route 53](dns-configuring-dnssec-zsk-management.md)
+ [Preuves DNSSEC d'inexistence dans Route 53](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [Résolution des problèmes de signature DNSSEC](dns-configuring-dnssec-troubleshoot.md)

# Activation de la signature DNSSEC et établissement d'une chaîne d'approbation
<a name="dns-configuring-dnssec-enable-signing"></a>

****  
Les étapes progressives s'appliquent au propriétaire de la zone hébergée et au responsable de la zone parent. Il peut s'agir de la même personne, mais si ce n'est pas le cas, le propriétaire de la zone doit en informer le responsable de la zone parent et collaborer avec celui-ci.

Nous vous recommandons de suivre les étapes décrites dans cet article pour signer et inclure votre zone dans la chaîne d'approbation. Les étapes suivantes réduiront le risque d'onboarding sur le protocole DNSSEC (Domain Name System Security Extensions).

**Note**  
Assurez-vous de lire les prérequis avant de vous lancer dans [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md).

Trois étapes permettent d'activer la signature DNSSEC, comme décrit dans les sections suivantes. 

**Topics**
+ [Étape 1 : Préparer l'activation de la signature DNSSEC](#dns-configuring-dnssec-enable-signing-step-1)
+ [Étape 2 : Activer la signature DNSSEC et créer une clé KSK](#dns-configuring-dnssec-enable)
+ [Étape 3 : Établir une chaîne d'approbation](#dns-configuring-dnssec-chain-of-trust)

## Étape 1 : Préparer l'activation de la signature DNSSEC
<a name="dns-configuring-dnssec-enable-signing-step-1"></a>

Les étapes de préparation vous aident à réduire le risque d'onboarding à DNSSEC en contrôlant la disponibilité de la zone et en réduisant les temps d'attente entre l'activation de la signature et l'insertion du registre Delegation Signer (DS).

**Pour se préparer à l'activation de la signature DNSSEC**

1. Contrôlez la disponibilité de la zone.

   Vous pouvez contrôler la zone de disponibilité des noms de domaine. Cela peut vous aider à résoudre tous les problèmes pouvant justifier un retour à l'étape précédente après avoir activé la signature DNSSEC. Vous pouvez contrôler les noms de domaine ayant le plus de trafic à l'aide de la journalisation des requêtes. Pour plus d'informations sur la configuration de la journalisation des requêtes, consultez [Surveillance d'Amazon Route 53](monitoring-overview.md).

   Vous pouvez effectuer la surveillance via un script shell ou via un service tiers. Il ne devrait toutefois pas s'agir du seul signal permettant de déterminer si une restauration est nécessaire. Vous recevrez peut-être également des commentaires de vos clients en raison de l'indisponibilité d'un domaine.

1. Réduisez la TTL maximale de la zone.

   La TTL maximale de la zone est le registre TTL le plus long de la zone. Dans l'exemple de zone ci-dessous, la TTL maximale de la zone est de 1 jour (86 400 secondes).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)

   La réduction de la TTL maximale de la zone permettra de réduire le temps d'attente entre l'activation de la signature et l'insertion du registre Delegation Signer (DS). Nous vous recommandons de réduire la TTL maximale de la zone à 1 heure (3 600 secondes). Cela vous permet de revenir en arrière après seulement une heure si un résolveur rencontre des problèmes avec la mise en cache des registres signés.

   **Restauration :** annulez les modifications TTL.

1. Réduisez le champ SOA TTL and SOA minimum (Valeur TTL SOA et SOA minimale).

   Le champ SOA minimum (Valeur SOA minimale) est le dernier champ des données de registre SOA. Dans l'exemple de registre SOA suivant, le champ Minimum (Minimal) comporte une valeur de 5 minutes (300 secondes).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)

   Le champ SOA TTL and SOA minimum (Valeur TTL SOA et SOA minimale) détermine pendant combien de temps les résolveurs mémorisent les réponses négatives. Une fois que vous avez activé la signature, les serveurs de noms Route 53 commencent à renvoyer des registres NSEC pour obtenir des réponses négatives. NSEC contient des informations que les résolveurs peuvent utiliser pour synthétiser une réponse négative. Si vous devez revenir en arrière, car les informations NSEC ont amené un résolveur à supposer une réponse négative pour un nom, il suffit d'attendre le maximum du champ SOA TTL and SOA minimum (Valeur TTL SOA et SOA minimale) pour que le résolveur arrête l'hypothèse.

   **Restauration :** annulez les modifications de la source de noms (SOA, Start of Authority).

1. Assurez-vous que les modifications du champ TTL and SOA minimum (Valeur TTL et SOA minimale) sont appliquées.

   Utilisez-le [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)pour vous assurer que les modifications que vous avez apportées jusqu'à présent ont été propagées à tous les serveurs DNS Route 53.

## Étape 2 : Activer la signature DNSSEC et créer une clé KSK
<a name="dns-configuring-dnssec-enable"></a>

Vous pouvez activer la signature DNSSEC et créer une clé de signature par clé (KSK) en utilisant AWS CLI ou sur la console Route 53.
+ [INTERFACE DE LIGNE DE COMMANDE (CLI)](#dnssec_CLI)
+ [Console](#dnssec_console)

Lorsque vous fournissez ou créez une clé KMS, plusieurs exigences s'appliquent. Pour de plus amples informations, veuillez consulter [Utilisation des clés gérées par le client pour DNSSEC](dns-configuring-dnssec-cmk-requirements.md).

------
#### [ CLI ]

Vous pouvez utiliser une clé que vous possédez déjà ou en créer une en exécutant une commande AWS CLI telle que la suivante, en utilisant vos propres valeurs pour `hostedzone_id`, `cmk_arn`, `ksk_name` et `unique_string` (pour rendre la demande unique) :

```
aws --region us-east-1 route53 create-key-signing-key \
			--hosted-zone-id $hostedzone_id \
			--key-management-service-arn $cmk_arn --name $ksk_name \
			--status ACTIVE \
			--caller-reference $unique_string
```

Pour plus d'informations sur les clés gérées par le client, consultez [Utilisation des clés gérées par le client pour DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Consultez également [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html).

Pour activer la signature DNSSEC, exécutez une AWS CLI commande comme celle-ci, en utilisant votre propre valeur pour : `hostedzone_id`

```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
			--hosted-zone-id $hostedzone_id
```

Pour plus d'informations, consultez [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)et [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html).

------
#### [ Console ]<a name="dns-configuring-dnssec-enable-procedure"></a>

**Pour activer la signature DNSSEC et créer une clé KSK**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones (Zones hébergées)**, puis choisissez une zone hébergée pour laquelle vous souhaitez activer la signature DNSSEC.

1. Dans l'onglet **DNSSEC signing (Signature DNSSEC)**, choisissez **Enable DNSSEC signing (Activer la signature DNSSEC)**.
**Note**  
Si l'option de cette section est **Disable DNSSEC signing (Désactiver la signature DNSSEC)**, vous avez déjà réalisé la première étape de l'activation de la signature DNSSEC. Assurez-vous d'établir une chaîne d'approbation pour la zone hébergée pour DNSSEC, ou assurez-vous qu'il en existe déjà une. Ensuite, vous avez terminé. Pour de plus amples informations, veuillez consulter [Étape 3 : Établir une chaîne d'approbation](#dns-configuring-dnssec-chain-of-trust).

1. Dans **Key-signing key (KSK) creation [Création d'une clé de signature de clé (KSK)]**, choisissez **Create new KSK (Créer une clé KSK)** et sous **Provide KSK name (Fournir un nom de clé KSK)**, entrez un nom pour la clé KSK que Route 53 créera pour vous. Le nom peut contenir des chiffres, des lettres et des traits de soulignement (\$1). Il doit être unique.

1. Sous **Customer managed CMK (Clé CMK gérée par le client)**, choisissez la clé gérée par le client à utiliser par Route 53 lorsqu'il crée la clé KSK pour vous. Vous pouvez utiliser une clé gérée par le client existante qui s'applique à la signature DNSSEC, ou créer une nouvelle clé gérée par le client.

   Lorsque vous fournissez ou créez une clé gérée par le client, plusieurs exigences s'appliquent. Pour plus d'informations, consultez [Utilisation des clés gérées par le client pour DNSSEC](dns-configuring-dnssec-cmk-requirements.md).

1. Saisissez l'alias d'une clé gérée par le client existante. Si vous souhaitez utiliser une nouvelle clé gérée par le client, saisissez un alias pour la clé gérée par le client et Route 53 en créera un pour vous.
**Note**  
Si vous choisissez que Route 53 crée une clé gérée par le client, sachez que des frais distincts s'appliquent pour chaque clé gérée par le client. Pour plus d'informations, consultez [Tarification d'AWS Key Management Service](https://aws.amazon.com/kms/pricing/).

1. Choisissez **Enable DNSSEC signing (Activer la signature DNSSEC)**.

------

**Une fois que vous avez activé la signature de zone, suivez les étapes ci-après** (que vous utilisiez la console ou la CLI) :

1. Assurez-vous que la signature de zone est effective.

   Si vous l'avez utilisé AWS CLI, vous pouvez utiliser l'identifiant d'opération indiqué dans la sortie de l'`EnableHostedZoneDNSSEC()`appel pour exécuter [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) ou [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)pour vous assurer que tous les serveurs DNS Route 53 signent les réponses (status =`INSYNC`).

1. Attendez au moins la TTL maximale de la zone précédente.

   Attendez que les résolveurs vident tous les registres non signés de leur cache. Pour ce faire, vous devez attendre au moins la TTL maximale de la zone précédente. Dans la zone `example.com` ci-dessus, le temps d'attente serait de 1 jour.

1. Contrôlez les rapports des problèmes de clients.

   Une fois que vous avez activé la signature de zone, vos clients remarqueront peut-être des problèmes liés aux périphériques réseau et aux résolveurs. La période de surveillance recommandée est de 2 semaines.

   Voici des exemples de problèmes que vous pourriez constater :
   + Certains périphériques réseau peuvent limiter la taille de la réponse DNS à moins de 512 octets, ce qui est trop petit pour certaines réponses signées. Ces périphériques réseau doivent être reconfigurés pour autoriser des tailles plus grandes de réponses DNS.
   + Certains périphériques réseau effectuent une inspection approfondie des réponses DNS et suppriment certains registres incompréhensibles, comme ceux utilisés pour DNSSEC. Ces périphériques doivent être reconfigurés.
   + Les résolveurs de certains clients affirment qu'ils peuvent accepter une réponse UDP plus grande que celle prise en charge par leur réseau. Vous pouvez tester la capacité de votre réseau et configurer vos résolveurs de manière appropriée. Pour plus d'informations, consultez [Serveur de test de taille de réponse DNS](https://www.dns-oarc.net/oarc/services/replysizetest/).

**Annulation :** appelez [DisableHostedZoneDNSSEC puis annulez](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) les étapes. [Étape 1 : Préparer l'activation de la signature DNSSEC](#dns-configuring-dnssec-enable-signing-step-1)

## Étape 3 : Établir une chaîne d'approbation
<a name="dns-configuring-dnssec-chain-of-trust"></a>

Après avoir activé la signature DNSSEC pour une zone hébergée dans Route 53, établissez une chaîne d'approbation pour la zone hébergée pour terminer la configuration de votre signature DNSSEC. Pour ce faire, créez un registre Delegation Signer dans la zone hébergée *parent*, pour votre zone hébergée, à l'aide des informations fournies par Route 53. Selon l'emplacement dans lequel votre domaine est membre, ajoutez le registre à la zone hébergée parent dans Route 53 ou dans un autre bureau d'enregistrement de domaine.<a name="dns-configuring-dnssec-chain-of-trust-procedure"></a>

**Pour établir une chaîne d'approbation pour la signature DNSSEC**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones (Zones hébergées)**, puis choisissez une zone hébergée pour laquelle vous souhaitez établir une chaîne d'approbation DNSSEC. *Vous devez d'abord activer la signature DNSSEC.*

1. Dans l'onglet **DNSSEC signing (Signature DNSSEC)**, sous **DNSSEC signing (Signature DNSSEC)**, choisissez **View information to create DS record (Afficher les informations pour créer un registre DS)**.
**Note**  
Si vous ne voyez pas **View information to create DS record (Afficher les informations pour créer un registre DS)** dans cette section, vous devez activer la signature DNSSEC avant d'établir la chaîne d'approbation. Choisissez **Enable DNSSEC signing (Activer la signature DNSSEC)** et effectuez les étapes, comme décrit dans [Étape 2 : Activer la signature DNSSEC et créer une clé KSK](#dns-configuring-dnssec-enable), puis revenez à ces étapes pour établir la chaîne d'approbation.

1. Sous **Establish a chain of trust (Établir une chaîne d'approbation)**, choisissez **Route 53 registrar (Bureau d'enregistrement Route 53)** ou **Another domain registrar (Autre bureau d'enregistrement de domaine)**, en fonction de l'emplacement dans lequel votre domaine est membre.

1. Utiliser les valeurs fournies à partir de l'étape 3 pour créer un registre DS pour la zone hébergée parent dans Route 53. Si votre domaine n'est pas hébergé sur Route 53, utilisez les valeurs fournies pour créer un registre DS sur le site Web de votre bureau d'enregistrement de domaines. 

   Établissez une chaîne de confiance pour la zone parent :
   + Si votre domaine est géré via Route 53, procédez comme suit :

     Assurez-vous de configurer l'algorithme de signature (ECDSAP256SHA256 et le type 13) et l'algorithme de synthèse (SHA-256 et type 2) corrects. 

     Si Route 53 est votre bureau d'enregistrement, procédez comme suit dans la console Route 53 :

     1. Notez les valeurs **Key type (Type de clé)**, **Signing algorithm (Algorithme de signature)** et **Public key (Clé publique)**. Dans le panneau de navigation, choisissez **Registered domains (Domaines membres)**.

     1. Sélectionnez un domaine, puis, dans l'onglet **Clés DNSSEC**, choisissez **Ajouter** une clé.

     1. Dans la boîte de dialogue **Manage DNSSEC keys (Gérer les clés DNSSEC)**, choisissez le **Key type (Type de clé)** et l'**Algorithm (Algorithme)** appropriés au **Route 53 registrar (Bureau d'enregistrement Route 53)** dans les menus déroulants.

     1. Copiez la **Public key (Clé publique)** pour le bureau d'enregistrement Route 53. Dans la boîte de dialogue **Manage DNSSEC keys (Gérer les clés DNSSEC)**, collez la valeur dans la zone **Public key (Clé publique)**.

     1. Choisissez **Add (Ajouter)**.

         Route 53 ajoute le registre DS à la zone parent à partir de la clé publique. Par exemple, si votre domaine est `example.com`, le registre DS est ajouté à la zone DNS .com.
   + Si votre domaine est géré sur un autre registre, suivez les instructions de la section **Autre bureau d'enregistrement de domaines**.

     Pour vous assurer que les étapes suivantes se déroulent correctement, présentez une TTL DS faible à la zone parent. Nous vous recommandons de définir la TTL DS sur 5 minutes (300 secondes) pour une récupération plus rapide si vous devez annuler vos modifications.
     + Établissez une chaîne de confiance pour la zone enfant :

       Si votre zone parent est administrée par un autre registre, contactez votre bureau d'enregistrement pour présenter le registre DS de votre zone. En règle générale, vous ne pourrez pas ajuster la TTL du registre DS.
     + Si votre zone parent est hébergée sur Route 53, contactez le propriétaire de la zone parent pour présenter le registre DS de votre zone. 

       Fournissez `$ds_record_value` au propriétaire de la zone parent. Vous pouvez l'obtenir en cliquant sur **Afficher les informations pour créer un enregistrement DS** dans la console et en copiant le champ d'**enregistrement DS**, ou en appelant l'API [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) et en récupérant la valeur du champ « » : DSRecord

       ```
       aws --region us-east-1 route53 get-dnssec 
                   --hosted-zone-id $hostedzone_id
       ```

       Le propriétaire de la zone parent peut insérer le registre via la console Route 53 ou la CLI.
       +  Pour insérer l'enregistrement DS à l'aide de AWS CLI, le propriétaire de la zone parent crée et nomme un fichier JSON similaire à l'exemple suivant. Le propriétaire de la zone parent peut nommer le fichier de manière semblable : `inserting_ds.json`. 

         ```
         {
             "HostedZoneId": "$parent_zone_id",
             "ChangeBatch": {
                 "Comment": "Inserting DS for zone $zone_name",
                 "Changes": [
                     {
                         "Action": "UPSERT",
                         "ResourceRecordSet": {
                             "Name": "$zone_name",
                             "Type": "DS",
                             "TTL": 300,
                             "ResourceRecords": [
                                 {
                                     "Value": "$ds_record_value"
                                 }
                             ]
                         }
                     }
                 ]
             }
         }
         ```

         Ensuite, exécutez la commande suivante :

         ```
         aws --region us-east-1 route53 change-resource-record-sets 
                     --cli-input-json file://inserting_ds.json
         ```
       + Pour insérer le registre DS à l'aide de la console, 

         Ouvrez la console Route 53 à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

         Dans le panneau de navigation, choisissez **Hosted zones (Zones hébergées)**, le nom de votre zone hébergée, puis le bouton **Create record (Créer un registre)**. Assurez-vous de choisir le routage simple pour la **Routing policy(Politique de routage)**.

         Dans le champ **Nom de l'enregistrement**, entrez le même nom que le`$zone_name`, sélectionnez DS dans le menu déroulant **Type d'enregistrement**, entrez la valeur de `$ds_record_value` dans le champ **Valeur**, puis choisissez **Créer des enregistrements**.

   **Restauration :** supprimez le DS de la zone parent, attendez la TTL DS, puis annulez les étapes d'établissement de l'approbation. Si la zone parent est hébergée sur Route 53, le propriétaire de la zone parent peut passer `Action` de `UPSERT` à `DELETE` dans le fichier JSON, puis réexécuter l'exemple de CLI ci-dessus.

1. Attendez que les mises à jour se propagent, en fonction de la TTL pour vos registres de domaine.

   Si la zone parent est sur le service DNS Route 53, le propriétaire de la zone parent peut confirmer la propagation complète via l'[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API.

   Sinon, vous pouvez rechercher périodiquement le registre DS dans la zone parent, puis attendre ensuite 10 minutes de plus pour augmenter la probabilité de propagation complète de l'insertion du registre DS. Notez que certains bureaux d'enregistrement ont planifié l'insertion de DS, par exemple une fois par jour.

Lorsque vous présentez le registre Delegation Signer (DS) dans la zone parent, les résolveurs validés qui ont récupéré le DS commenceront à valider les réponses à partir de la zone.

Pour vous assurer que les étapes d'établissement de l'approbation se déroulent correctement, renseignez les informations suivantes :

1. Trouvez la TTL NS maximale.

   2 jeux de registres NS sont associés à vos zones :
   + Registre NS de délégation : il s'agit du registre NS de votre zone détenu par la zone parent. Pour le trouver, exécutez les commandes Unix suivantes (si votre zone est exemple.com, la zone parent est com) :

     `dig -t NS com`

     Choisissez l'un des registres NS, puis exécutez les éléments suivants :

     `dig @one of the NS records of your parent zone -t NS example.com`

     Par exemple :

     `dig @b.gtld-servers.net. -t NS example.com`
   + Registre NS dans la zone : il s'agit du registre NS de votre zone. Pour le trouver, exécutez la commande Unix suivante :

     `dig @one of the NS records of your zone -t NS example.com`

     Par exemple :

     `dig @ns-0000.awsdns-00.co.uk. -t NS example.com`

     Notez la TTL maximale pour les deux zones.

1. Attendez la TTL NS maximale.

   Avant l'insertion de DS, les résolveurs reçoivent une réponse signée, mais ne valident pas la signature. Lorsque le registre DS est inséré, les résolveurs ne le verront pas avant l'expiration du registre NS de la zone. Lorsque les résolveurs extraient à nouveau le registre NS, le registre DS est également renvoyé.

   Si votre client exécute un résolveur sur un hôte dont l'horloge n'est pas synchronisée, assurez-vous que l'horloge n'avance pas ni ne recule de 1 heure de l'heure correcte.

   Une fois cette étape terminée, tous les résolveurs compatibles avec DNSSEC valideront votre zone.

1. Observez la résolution des noms.

   Vous devez noter qu'il n'existe aucun problème avec les résolveurs qui valident votre zone. Assurez-vous également de prendre en compte le temps nécessaire à vos clients pour vous signaler les problèmes.

   Nous vous recommandons d'effectuer la surveillance pendant 2 semaines au maximum.

1. (Facultatif) Allongez le DS et le NS. TTLs

   Si la configuration vous convient, vous pouvez enregistrer les modifications de TTL et de SOA que vous avez apportées. Notez que Route 53 limite la TTL à une semaine pour les zones signées. Pour de plus amples informations, veuillez consulter [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md).

   Si vous pouvez modifier la TTL DS, nous vous recommandons de la définir sur 1 heure.

# Désactivation de la signature DNSSEC
<a name="dns-configuring-dnssec-disable"></a>

Les étapes de désactivation de la signature DNSSEC dans Route 53 varient en fonction de la chaîne d'approbation dont votre zone hébergée fait partie. 

Par exemple, il est possible que votre zone hébergée dispose d'une zone parent dotée d'un registre Delegation Signer (DS), ce qui constitue une partie d'une chaîne d'approbation. Il est également possible que votre zone hébergée soit elle-même une zone parent pour les zones enfant qui ont activé la signature DNSSEC, ce qui constitue une autre partie de la chaîne d'approbation. Étudiez et déterminez la chaîne d'approbation complète de votre zone hébergée avant de désactiver la signature DNSSEC.

La chaîne d'approbation de votre zone hébergée qui active la signature DNSSEC doit être soigneusement annulée lorsque vous désactivez la signature. Pour supprimer votre zone hébergée de la chaîne d'approbation, supprimez tous les registres DS en place pour la chaîne d'approbation qui inclut cette zone hébergée. Cela signifie que vous devez effectuer les tâches suivantes, dans l'ordre :

1. Supprimez tous les registres DS que cette zone hébergée possède pour les zones enfant qui font partie d'une chaîne d'approbation.

1. Supprimez le registre DS de la zone parent. Ignorez cette étape si vous disposez d'une île d'approbation (aucun registre DS dans la zone parent et aucun registre DS pour les zones enfant dans cette zone). 

1. Si vous ne parvenez pas à supprimer des enregistrements DS, afin de supprimer la zone de la chaîne d'approbation, supprimez les enregistrements NS de la zone parent. Pour de plus amples informations, veuillez consulter [Ajout ou modification de serveurs de noms et d'enregistrements de type glue pour un domaine](domain-name-servers-glue-records.md).

Les étapes progressives suivantes vous permettent de contrôler le caractère effectif des différentes étapes afin d'éviter les problèmes de disponibilité DNS dans votre zone.

**Pour désactiver la signature DNSSEC**

1. Contrôlez la disponibilité de la zone.

   Vous pouvez contrôler la zone de disponibilité des noms de domaine. Cela peut vous aider à résoudre tous les problèmes pouvant justifier un retour à l'étape précédente après avoir activé la signature DNSSEC. Vous pouvez contrôler les noms de domaine ayant le plus de trafic à l'aide de la journalisation des requêtes. Pour plus d'informations sur la configuration de la journalisation des requêtes, consultez [Surveillance d'Amazon Route 53](monitoring-overview.md).

   La surveillance peut être effectuée via un script shell ou via un service payant. Il ne devrait toutefois pas s'agir du seul signal permettant de déterminer si une restauration est nécessaire. Vous recevrez peut-être également des commentaires de vos clients en raison de l'indisponibilité d'un domaine.

1. Trouvez la TTL DS actuelle.

   Pour ce faire, exécutez la commande Unix suivante :

   `dig -t DS example.com example.com`

1. Trouvez la TTL NS maximale.

   2 jeux de registres NS sont associés à vos zones :
   + Registre NS de délégation : il s'agit du registre NS de votre zone détenu par la zone parent. Pour le trouver, exécutez les commandes Unix suivantes :

     Commencez par trouver le NS de votre zone parent (si votre zone est exemple.com, la zone parent est com) :

     `dig -t NS com`

     Choisissez l'un des registres NS, puis exécutez les éléments suivants :

     `dig @one of the NS records of your parent zone -t NS example.com`

     Par exemple :

     `dig @b.gtld-servers.net. -t NS example.com`
   + Registre NS dans la zone : il s'agit du registre NS de votre zone. Pour le trouver, exécutez la commande Unix suivante :

     `dig @one of the NS records of your zone -t NS example.com`

     Par exemple :

     `dig @ns-0000.awsdns-00.co.uk. -t NS example.com`

     Notez la TTL maximale pour les deux zones.

1. Supprimez le registre DS de la zone parent. 

   Contactez le propriétaire de la zone parent pour supprimer le registre DS.

   **Restauration :** réinsérez l'enregistrement DS, vérifiez que l'insertion de DS est effective et attendez la TTL NS (et non DS) maximale avant que tous les résolveurs recommencent la validation.

1. Vérifiez que la suppression de DS est effective.

   Si la zone parent est sur le service DNS Route 53, le propriétaire de la zone parent peut confirmer la propagation complète via l'[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API.

   Sinon, vous pouvez rechercher périodiquement le registre DS dans la zone parent, puis attendre ensuite 10 minutes de plus pour augmenter la probabilité de propagation complète de la suppression du registre DS. Notez que certains bureaux d'enregistrement ont planifié la suppression de DS, par exemple une fois par jour.

1. Attendez la TTL DS.

   Attendez que tous les résolveurs aient expiré le registre DS de leurs caches.

1. Désactivez la signature DNSSEC et la clé de signature de clé (KSK).
   + [INTERFACE DE LIGNE DE COMMANDE (CLI)](#CLI_dnssec_disable)
   + [Console](#console_dnssec_disable)

------
#### [ CLI ]

   Appelez [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) et. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs

   Par exemple :

   ```
   aws --region us-east-1 route53 disable-hosted-zone-dnssec \
               --hosted-zone-id $hostedzone_id
   
   aws --region us-east-1 route53 deactivate-key-signing-key \
               --hosted-zone-id $hostedzone_id --name $ksk_name
   ```

------
#### [ Console ]

   **Pour désactiver la signature DNSSEC**

   1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

   1. Dans le panneau de navigation, choisissez **Hosted zones (Zones hébergées)**, puis choisissez une zone hébergée pour laquelle vous souhaitez désactiver la signature DNSSEC.

   1. Dans l'onglet **DNSSEC signing (Signature DNSSEC)**, choisissez **Disable DNSSEC signing (Désactiver la signature DNSSEC)**.

   1. Sur la page **Disable DNSSEC signing (Désactiver la signature DNSSEC)**, choisissez l'une des options suivantes, selon votre scénario pour la zone pour laquelle vous désactivez la signature DNSSEC.
      + **Parent zone only (Zone parent uniquement)** : cette zone comporte une zone parent avec un registre DS. Dans ce scénario, vous devez supprimer le registre DS de la zone parent.
      + **Child zones only (Zones enfants uniquement)** : cette zone comporte un registre DS pour une chaîne d'approbation avec une ou plusieurs zones enfants. Dans ce scénario, vous devez supprimer les registres DS de la zone.
      + **Parent and child zones (Zones parent et enfants)** : cette zone comporte à la fois un registre DS pour une chaîne d'approbation avec une ou plusieurs zones enfants *et* une zone parent avec un registre DS. Dans ce scénario, procédez comme suit, dans l'ordre :

        1. Supprimez les registres DS de la zone.

        1. Supprimez le registre DS de la zone parent.

        Si vous disposez d'une île d'approbation, vous pouvez ignorer cette étape.

   1. Déterminez la TTL pour chaque registre DS que vous supprimez à l'étape 4. Assurez-vous que la période TTL la plus longue a expiré.

   1. Cochez cette case pour confirmer que vous avez effectué les étapes dans l'ordre indiqué.

   1. Saisissez *disable* dans le champ, comme illustré, puis choisissez **Disable (Désactiver)**.

   **Pour désactiver la clé de signature de clé (KSK)**

   1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

   1. Dans le panneau de navigation, choisissez **Hosted zones (Zones hébergées)**, puis choisissez une zone hébergée pour laquelle vous souhaitez désactiver la la clé de signature de clé (KSK).

   1. **Dans la section **Clés de signature par clé (KSKs)**, choisissez le KSK que vous souhaitez désactiver, puis sous **Actions**, choisissez **Modifier le KSK, définissez le statut du KSK** **sur **Inactif**, puis sélectionnez Enregistrer le KSK**.**

------

   **Annulation :** appel [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)et [EnableHostedZone APIsDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html).

   Par exemple :

   ```
   aws --region us-east-1 route53 activate-key-signing-key \
               --hosted-zone-id $hostedzone_id --name $ksk_name
   
   aws --region us-east-1 route53 enable-hosted-zone-dnssec \
               --hosted-zone-id $hostedzone_id
   ```

1. Confirmez que la désactivation de la signature de la zone est effective.

   Utilisez l'identifiant de l'`EnableHostedZoneDNSSEC()`appel pour exécuter [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)afin de vous assurer que tous les serveurs DNS Route 53 ont cessé de signer les réponses (status =`INSYNC`).

1. Observez la résolution des noms.

   Vous devez observer qu'aucun problème n'entraîne la validation de votre zone par les résolveurs. Prévoyez 1 à 2 semaines pour prendre en compte le temps nécessaire à vos clients pour vous signaler les problèmes.

1. (Facultatif) Nettoyez.

   Si vous ne réactivez pas la signature, vous pouvez effectuer le nettoyage [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)et supprimer la clé gérée KSKs par le client correspondante afin de réduire les coûts.

# Utilisation des clés gérées par le client pour DNSSEC
<a name="dns-configuring-dnssec-cmk-requirements"></a>

Lorsque vous activez la signature DNSSEC dans Amazon Route 53, Route 53 crée une clé KSK pour vous. Pour créer un KSK, Route 53 doit utiliser une clé gérée par le client AWS Key Management Service qui prend en charge le protocole DNSSEC. Cette section décrit les détails et les exigences relatifs à la clé gérée par le client à connaître lorsque vous utilisez DNSSEC.

Gardez à l'esprit ce qui suit lorsque vous utilisez les clés gérées par le client pour DNSSEC :
+ La clé gérée par le client que vous utilisez avec la signature DNSSEC doit se trouver dans la région USA Est (Virginie du Nord). 
+ La clé gérée par le client doit être un [clé asymétrique gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) dotée d'une [spécification de clé ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). Ces clés gérées par le client sont uniquement utilisées aux fins de la signature et de la vérification. Pour obtenir de l'aide sur la création d'une clé asymétrique gérée par le client, consultez la section [Création de clés asymétriques gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) dans le guide du AWS Key Management Service développeur. Pour obtenir de l'aide pour trouver la configuration cryptographique d'une clé gérée par le client existante, consultez la section [Affichage de la configuration cryptographique des clés gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) dans le Guide du AWS Key Management Service développeur.
+ Si vous créez vous-même une clé gérée par le client à utiliser avec DNSSEC dans Route 53, vous devez inclure des instructions de politique de clé spécifiques qui confèrent à Route 53 les autorisations requises. Route 53 doit pouvoir accéder à votre clé gérée par le client afin de pouvoir créer une clé KSK pour vous. Pour de plus amples informations, veuillez consulter [Autorisations de clé gérées par le client Route 53 requises pour la signature DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
+ Route 53 peut créer une clé gérée par le client que vous pouvez utiliser AWS KMS pour la signature DNSSEC sans autorisations supplémentaires AWS KMS . Toutefois, vous devez disposer d'autorisations spécifiques si vous souhaitez modifier la clé après sa création. Les autorisations spécifiques dont vous devez disposer sont les suivantes : `kms:UpdateKeyDescription`, `kms:UpdateAlias` et `kms:PutKeyPolicy`.
+ Vous devez savoir que des frais distincts s'appliquent pour chaque clé gérée par le client que vous possédez, que vous créiez la clé gérée par le client ou que Route 53 la crée pour vous. Pour en savoir plus, consultez [Pricing AWS Key Management Service](https://aws.amazon.com/kms/pricing/) (Tarification).

# Utilisation de clés de signature () KSKs
<a name="dns-configuring-dnssec-ksk"></a>

Lorsque vous activez la signature DNSSEC, Route 53 crée une clé KSK pour vous. Vous pouvez en avoir jusqu'à deux KSKs par zone hébergée dans Route 53. Après avoir activé la signature DNSSEC, vous pouvez ajouter, supprimer ou modifier votre. KSKs

Tenez compte des points suivants lorsque vous travaillez avec votre KSKs :
+ Avant de pouvoir supprimer une clé KSK, vous devez modifier la clé KSK pour définir son statut sur **Inactive** (Inactif). 
+ Lorsque la signature DNSSEC est activée pour une zone hébergée, Route 53 limite la TTL à une semaine. Si vous définissez une TTL de plus d'une semaine pour les registres dans la zone hébergée, vous n'obtenez pas d'erreur, mais Route 53 applique une TTL d'une semaine.
+ Pour éviter une panne de zone et éviter que votre domaine ne devienne indisponible, vous devez rapidement corriger et résoudre les erreurs DNSSEC. Nous vous recommandons vivement de configurer une CloudWatch alarme qui vous avertira chaque fois qu'une `DNSSECInternalFailure` `DNSSECKeySigningKeysNeedingAction` erreur est détectée. Pour de plus amples informations, veuillez consulter [Surveillance des zones hébergées à l'aide d'Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Les opérations KSK décrites dans cette section vous permettent de faire pivoter celles de KSKs votre zone. Pour plus d'informations et un step-by-step exemple, consultez la section *Rotation des clés DNSSEC* dans le billet de blog [Configuration de la signature et de la validation DNSSEC avec Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/).

Pour travailler avec KSKs dans le AWS Management Console, suivez les instructions des sections suivantes.

## Ajout d'une clé KSK
<a name="dns-configuring-dnssec-ksk-add-ksk"></a>

Lorsque vous activez la signature DNSSEC, Route 53 crée une clé KSK pour vous. Vous pouvez également les ajouter KSKs séparément. Vous pouvez en avoir jusqu'à deux KSKs par zone hébergée dans Route 53. 

Lorsque vous créez un KSK, vous devez fournir ou demander à Route 53 de créer une clé gérée par le client à utiliser avec le KSK. Lorsque vous fournissez ou créez une clé gérée par le client, plusieurs exigences s'appliquent. Pour de plus amples informations, veuillez consulter [Utilisation des clés gérées par le client pour DNSSEC](dns-configuring-dnssec-cmk-requirements.md).

Procédez comme suit pour ajouter une clé KSK dans la AWS Management Console.<a name="dns-configuring-dnssec-ksk-add-ksk-procedure"></a>

**Pour ajouter une clé KSK**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones ** (Zones hébergées), puis choisissez une zone hébergée.

1. **Dans l'onglet **Signature DNSSEC**, sous Clés de **signature par clé (KSKs)**, choisissez **Passer à l'affichage avancé**, puis, sous **Actions**, choisissez Ajouter un KSK.**

1. Sous **KSK (Clé KSK)**, saisissez un nom pour la clé KSK que Route 53 créera pour vous. Le nom peut contenir des chiffres, des lettres et des traits de soulignement (\$1). Il doit être unique.

1. Entrez l'alias d'une clé gérée par le client qui s'applique à la signature DNSSEC, ou entrez un alias pour une nouvelle clé gérée par le client que Route 53 créera pour vous.
**Note**  
Si vous choisissez que Route 53 crée une clé gérée par le client, sachez que des frais distincts s'appliquent pour chaque clé gérée par le client. Pour en savoir plus, consultez [Pricing AWS Key Management Service](https://aws.amazon.com/kms/pricing/) (Tarification).

1. Choisissez **Create KSK**(Créer une clé KSK).

## Modification d'une clé KSK
<a name="dns-configuring-dnssec-ksk-edit-ksk"></a>

Vous pouvez modifier le statut d'une clé KSK sur **Active (Actif)** ou **Inactive (Inactif**). Lorsqu'une clé KSK est active, Route 53 l'utilise aux fins de la signature DNSSEC. Avant de pouvoir supprimer une clé KSK, vous devez modifier la clé KSK pour définir son statut sur **Inactive (Inactif)**.

Procédez comme suit pour modifier une clé KSK dans la AWS Management Console.<a name="dns-configuring-dnssec-ksk-edit-ksk-procedure"></a>

**Pour modifier une clé KSK**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones ** (Zones hébergées), puis choisissez une zone hébergée.

1. **Dans l'onglet **Signature DNSSEC**, sous Clés de **signature par clé (KSKs)**, choisissez **Passer à l'affichage avancé**, puis, sous **Actions**, choisissez Modifier le KSK.**

1. Effectuez les mises à jour souhaitées sur la clé KSK, puis choisissez **Save (Enregistrer)**.

## Suppression d'une clé KSK
<a name="dns-configuring-dnssec-ksk-delete-ksk"></a>

Avant de pouvoir supprimer une clé KSK, vous devez modifier la clé KSK pour définir son statut sur **Inactive (Inactif)**. 

Vous pouvez supprimer une clé KSK aux fins de la routine de rotation des clés. Il est recommandé de périodiquement effectuer la rotation des clés de chiffrement. Votre organisation peut disposer d'instructions standard concernant la fréquence de rotation des clés. 

Procédez comme suit pour supprimer une clé KSK dans la AWS Management Console.<a name="dns-configuring-dnssec-ksk-delete-ksk-procedure"></a>

**Pour supprimer une clé KSK**

1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. Dans le panneau de navigation, choisissez **Hosted zones ** (Zones hébergées), puis choisissez une zone hébergée.

1. **Dans l'onglet **Signature DNSSEC**, sous Clés de **signature par clé (KSKs)**, choisissez **Passer à l'affichage avancé**, puis sous **Actions**, choisissez Supprimer le KSK.**

1. Suivez les instructions pour confirmer la suppression de la clé KSK.

# Gestion des clés KMS et ZSK dans Route 53
<a name="dns-configuring-dnssec-zsk-management"></a>

Cette section décrit la pratique actuelle utilisée par Route 53 pour vos zones activées de signature DNSSEC.

**Note**  
Route 53 utilise la règle suivante qui peut changer. Tout changement futur ne réduira pas la posture de sécurité de votre zone ou de Route 53.

**Comment Route 53 utilise les informations AWS KMS associées à votre KSK**  
Dans DNSSEC, le KSK est utilisé pour générer la signature d'enregistrement de ressources (RRSIG) pour le jeu d'enregistrements de ressources DNSKEY. Tous `ACTIVE` KSKs sont utilisés dans la génération RRSIG. Route 53 génère un RRSIG en appelant l'`Sign` AWS KMS API sur la clé KMS associée. Pour plus d'informations, consultez [Sign (Signer)](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) dans le *AWS KMS Guide de l'API*. Ils RRSIGs ne sont pas pris en compte dans le calcul de la limite d'enregistrement des ressources de la zone.  
RRSIG a une expiration. Pour éviter qu'ils RRSIGs n'expirent, RRSIGs ils sont rafraîchis régulièrement en les régénérant tous les un à sept jours.  
Ils RRSIGs sont également actualisés chaque fois que vous appelez l'un des numéros suivants APIs :  
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Chaque fois que Route 53 effectue une actualisation, nous en générons 15 RRSIGs pour couvrir les prochains jours au cas où la clé KMS associée deviendrait inaccessible. Pour l'estimation des coûts des clés KMS, vous pouvez supposer une actualisation régulière une fois par jour. Une clé KMS peut devenir inaccessible en raison de modifications involontaires apportées à la politique de clé KMS. La clé KMS inaccessible définira l'état du KSK associé à `ACTION_NEEDED`. Nous vous recommandons vivement de surveiller cette condition en configurant une CloudWatch alarme chaque fois qu'une `DNSSECKeySigningKeysNeedingAction` erreur est détectée, car la validation des résolveurs commencera à échouer aux recherches après l'expiration du dernier RRSIG. Pour de plus amples informations, veuillez consulter [Surveillance des zones hébergées à l'aide d'Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).

**Comment Route 53 gère la ZSK de votre zone**  
Chaque nouvelle zone hébergée avec la signature DNSSEC activée aura une `ACTIVE` clé de signature de zone (ZSK). La ZSK est générée séparément pour chaque zone hébergée et appartient à Route 53. L'algorithme clé actuel est ECDSAP256SHA256.  
Nous commencerons à effectuer une rotation ZSK régulière sur la zone dans les 7 à 30 jours suivant le début de la signature. Actuellement, Route 53 utilise la méthode Pre-Publish Key Rollover (Renouvellement de la clé de signature de la zone de pré-publication). Pour plus d'informations, veuillez consulter[Pre-Publish Zone Signing Key Rollover (Renouvellement de la clé de signature de la zone de pré-publication)](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). Cette méthode va introduire un autre ZSK dans la zone. La rotation sera répétée tous les 7 à 30 jours.  
La Route 53 suspendra la rotation de la ZSK si l'un des KSK de la zone est en `ACTION_NEEDED` état, car Route 53 ne sera pas en mesure de régénérer les ensembles d'enregistrements de ressources RRSIGs pour DNSKEY afin de tenir compte des modifications apportées au ZSK de la zone. La rotation ZSK reprend automatiquement une fois que la condition est supprimée.

# Preuves DNSSEC d'inexistence dans Route 53
<a name="dns-configuring-dnssec-proof-of-nonexistence"></a>

**Note**  
Route 53 utilise la règle suivante qui peut changer. Tout changement futur ne réduira pas la posture de sécurité de votre zone ou de Route 53.

Il existe trois types de preuves d'inexistence dans DNSSEC :
+ Preuve d'inexistence d'un registre correspondant au nom de la requête.
+ Preuve d'inexistence d'un type correspondant au type de la requête.
+ Preuve d'existence d'un registre joker utilisé pour générer le registre en réponse.

Route 53 implémente la preuve d'inexistence d'un registre correspondant au nom de la requête à l'aide de la méthode BL. Pour plus d'informations, consultez [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). C'est une méthode qui produit une représentation compacte de la preuve et empêche la marche en zone.

Dans les cas où un enregistrement correspond au nom de la requête mais pas au type de requête (par exemple pour une requête pour web.example). com/AAAA but there is only web.example.com/Apresent), nous renvoyons un enregistrement NSEC (next secure) minimal contenant tous les types d'enregistrements de ressources pris en charge.

Lorsque Route 53 synthétise une réponse à partir d'un registre joker, la réponse n'est pas accompagnée d'un enregistrement sécurisé suivant, ou d'un registre NSEC pour le caractère générique. Un tel registre NSEC est utilisé dans certaines implémentations, généralement celles effectuant une signature hors ligne, pour empêcher la réutilisation des signatures d'enregistrement de ressources (RRSIG) de la réponse pour usurper une réponse différente. Route 53 utilise la signature en ligne pour les enregistrements non DNSKey afin de générer des informations RRSIGs spécifiques à la réponse qui ne peuvent pas être réutilisées pour une autre réponse.

# Résolution des problèmes de signature DNSSEC
<a name="dns-configuring-dnssec-troubleshoot"></a>

Les informations contenues dans cette section peuvent vous aider à résoudre les problèmes liés à la signature DNSSEC, notamment à l'activation, à la désactivation et à vos clés de signature par clé (). KSKs

Activation de la signature DNSSEC  
Assurez-vous d'avoir lu les prérequis dans [Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md) avant de commencer activer la signature DNSSEC.

Désactivation de la signature DNSSEC  
Afin de désactiver la signature DNSSEC en toute sécurité, Route 53 vérifiera si la zone cible se trouve dans la chaîne d'approbation. Il vérifie si le parent de la zone cible possède des enregistrements NS de la zone cible et des enregistrements DS de la zone cible. Si la zone cible ne peut pas être résolue publiquement, par exemple si vous recevez une réponse SERVFAIL lors d'une requête pour NS et DS, Route 53 ne peut pas déterminer s'il est prudent de désactiver la signature DNSSEC. Vous pouvez contacter votre zone parent pour résoudre ces problèmes et réessayer de désactiver la signature DNSSEC ultérieurement.

Le statut de la clé KSK est **Action needed (Action requise)**  
Un KSK peut changer son statut en **Action nécessaire** (ou `ACTION_NEEDED` en [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)statut), lorsque Route 53 DNSSEC perd l'accès à un correspondant AWS KMS key (en raison d'une modification des autorisations ou AWS KMS key d'une suppression).  
Si le statut d'un KSK est **Action needed (Action requise)**, cela signifie qu'il finira par provoquer une panne de zone pour les clients utilisant des résolveurs de validation DNSSEC et que vous devez agir rapidement pour éviter qu'une zone de production ne devienne impossible à résoudre.  
Pour corriger le problème, assurez-vous que la clé gérée par le client sur laquelle votre clé KSK est basée est activée et qu'elle dispose des autorisations appropriées. Pour plus d'informations sur les autorisations requises, consultez [Autorisations de clé gérées par le client Route 53 requises pour la signature DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).  
Après avoir corrigé le KSK, réactivez-le à l'aide de la console ou du AWS CLI, comme décrit dans[Étape 2 : Activer la signature DNSSEC et créer une clé KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable).  
Pour éviter que ce problème ne se reproduise à l'avenir, pensez à ajouter une Amazon CloudWatch métrique pour suivre l'état du KSK, comme suggéré dans[Configuration de la signature DNSSEC dans Amazon Route 53](dns-configuring-dnssec.md).

Le statut de la clé KSK est **Internal failure (Échec interne)**  
Lorsqu'un KSK présente un état de **défaillance interne** (ou `INTERNAL_FAILURE` un [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)état), vous ne pouvez pas travailler avec d'autres entités DNSSEC tant que le problème n'est pas résolu. Vous devez prendre des mesures avant de pouvoir utiliser la signature DNSSEC, y compris avant d'utiliser cette clé KSK ou votre autre clé KSK.  
Pour corriger le problème, essayez à nouveau d'activer ou de désactiver la clé KSK.  
 [Pour corriger le problème lorsque vous travaillez avec le APIs, essayez d'activer la signature ([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) ou de désactiver la signature (DisableHostedZoneDNSSEC).](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)  
Il est important que vous corrigiez rapidement les problèmes **Internal failure** (Échec interne). Vous ne pouvez pas apporter d'autres modifications à la zone hébergée tant que vous n'avez pas corrigé le problème, à l'exception des opérations visant à résoudre le problème **Internal failure (Échec interne)**.

# Utilisation AWS Cloud Map pour créer des dossiers et des bilans de santé
<a name="autonaming"></a>

Si vous souhaitez acheminer le trafic Internet ou le trafic interne d'un VPC Amazon vers des composants d'application ou des microservices, vous pouvez utiliser AWS Cloud Map pour créer automatiquement des registres et, éventuellement, des surveillances d'états. Pour plus d’informations, consultez le [Manuel du développeur AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/).

# Contraintes et comportements DNS
<a name="DNSBehavior"></a>

La messagerie DNS est soumise à des facteurs qui ont une influence sur la façon dont vous créez et utilisez les zones hébergées et les enregistrements. Cette section explique ces facteurs.

## Taille de réponse maximale
<a name="MaxSize"></a>

Pour respecter les normes DNS, la taille des réponses envoyées via UDP est limitée à 512 octets. Les réponses qui dépassent 512 octets sont tronquées et le résolveur doit émettre à nouveau la demande via TCP. Si le résolveur prend en charge EDNS0 (comme défini dans [RFC 2671](https://tools.ietf.org/html/rfc2671)) et informe Amazon Route 53 de l'option EDNS0, Route 53 autorise les réponses d'une taille maximale de 4 096 octets via UDP, sans troncature.

## Traitement de la section relative à l'autorité
<a name="AuthSectionProcessing"></a>

Pour les requêtes réussies, Route 53 ajoute les registres de serveur de noms (NS) de la zone hébergée appropriée à la section Authority (Autorité) de la réponse DNS. Pour les noms introuvables (réponses NXDOMAIN), Route 53 ajoute le registre de source de noms (SOA) (comme défini dans [RFC 1035](https://tools.ietf.org/html/rfc1035)) de la zone hébergée appropriée à la section Authority (Autorité) de la réponse DNS.

## Traitement de la section supplémentaire
<a name="SectionProcessing"></a>

Route 53 ajoute des registres à la section Additional (Supplémentaire). Si les enregistrements sont connus et appropriés, le service ajoute des enregistrements A ou AAAA à toutes les cibles d'un enregistrement MX, CNAME, NS ou SRV cité dans la section relative à la réponse. Pour obtenir plus d'informations sur ces types d'enregistrements DNS, consultez [Types d'enregistrements DNS pris en charge](ResourceRecordTypes.md).

# Rubriques en relation
<a name="dns-configuring-related-topics"></a>

Pour plus d'informations sur le transfert de l'enregistrement de domaine (et pas uniquement de l'hébergement DNS) vers Route 53, consultez les rubriques suivantes :
+ [Liste de contrôle préalable au transfert pour les transferts de domaines](domain-transfer-checklist.md)— Complétez cette liste de contrôle avant de transférer l'enregistrement de domaine afin d'éviter les échecs de transfert courants.
+ [Transfert d'un enregistrement de domaine vers Amazon Route 53](domain-transfer-to-route-53.md)— Step-by-step processus de transfert de l'enregistrement de domaine d'un autre bureau d'enregistrement vers Route 53.
+ [Transfert de domaines](domain-transfer.md)— Vue d'ensemble de toutes les options de transfert de domaine, y compris les transferts entre AWS comptes.