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 de la signature DNSSEC dans Amazon Route 53 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 **** 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 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 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 ] **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 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. **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 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 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 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 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. **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 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. **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 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. **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 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 **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 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)**.