Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Configurazione della firma DNSSEC in Amazon Route 53 La firma DNSSEC (Domain Name System Security Extensions) consente ai resolver DNS di verificare che una risposta DNS proviene da Amazon Route 53 e non è stata manomessa. Quando si utilizza la firma DNSSEC, ogni risposta per una zona ospitata viene firmata utilizzando la crittografia a chiave pubblica. Per una panoramica di DNSSEC, consulta la sezione DNSSEC di [AWS re:Invent 2021 - Amazon Route](https://www.youtube.com/watch?v=77V23phAaAE) 53: A year in review. In questo capitolo, spieghiamo come abilitare la firma DNSSEC per Route 53, come utilizzare le chiavi di firma dei tasti () e come risolvere i problemi. KSKs Puoi lavorare con DNSSEC accedendo o programmaticamente con l'API. Console di gestione AWS Per ulteriori informazioni sull'utilizzo della CLI o sull'utilizzo SDKs di Route 53, vedere. [Configura Amazon Route 53](setting-up-route-53.md) Prima di abilitare la firma DNSSEC, tieni presente quanto segue: + Per evitare interruzioni di una zona e che il dominio diventi indisponibile, è necessario risolvere rapidamente gli errori DNSSEC. Ti consigliamo vivamente di impostare un CloudWatch allarme che ti avvisi ogni volta che viene rilevato un `DNSSECKeySigningKeysNeedingAction` errore `DNSSECInternalFailure` or. Per ulteriori informazioni, consulta [Monitoraggio delle zone ospitate tramite Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + Esistono due tipi di chiavi in DNSSEC: una chiave di firma delle chiavi (KSK) e una chiave di firma della zona (ZSK). Nella firma DNSSEC di Route 53, ogni KSK è basata su una [chiave asimmetrica gestita dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) nella AWS KMS di tua proprietà. Sei responsabile della gestione KSK, che include la rotazione se necessario. La gestione ZSK viene eseguita da Route 53. + Quando abiliti la firma DNSSEC per una zona ospitata, Route 53 limita la durata (TTL, Time to Live) a una settimana. Se si imposta un TTL di più di una settimana per i record nella zona ospitata, non viene visualizzato alcun errore. Tuttavia, Route 53 applica un TTL di una settimana per i record. I record con un TTL inferiore a una settimana e i record in altre zone ospitate che non dispongono della firma DNSSEC abilitata non sono interessati. + Quando utilizzi la firma DNSSEC, le configurazioni multivendor non sono supportate. Se hai configurato dei server dei nomi white-label (noti anche come server dei nomi vanity o server dei nomi privati), assicurati che siano forniti da un unico provider DNS. + Alcuni provider DNS non supportano i record Delegation Signer (DS) nei loro DNS autorevoli. Se la tua zona principale è ospitata da un provider DNS che non supporta le query DS (senza impostare un flag AA nella risposta alla query DS), quando abiliti DNSSEC nella relativa zona figlio, la zona figlio non potrà essere risolta. Assicurati che il tuo provider DNS supporti i record DS. + Può essere utile impostare le autorizzazioni IAM per consentire a un altro utente, oltre al proprietario della zona, di aggiungere o rimuovere record nella zona. Ad esempio, il proprietario di una zona può aggiungere una KSK e abilitare la firma e potrebbe anche essere responsabile della rotazione delle chiavi. Tuttavia, qualcun altro potrebbe essere responsabile dell'utilizzo di altri record per la zona ospitata. Per un esempio di policy IAM, consultare [Autorizzazioni di esempio per il proprietario di un record di dominio](access-control-managing-permissions.md#example-permissions-record-owner). + Per verificare se il TLD supporta DNSSEC, consulta. [Domini che è possibile registrare con Amazon Route 53](registrar-tld-list.md) **Topics** + [Abilitazione della firma DNSSEC e creazione di una catena di attendibilità](dns-configuring-dnssec-enable-signing.md) + [Disabilitazione della firma DNSSEC](dns-configuring-dnssec-disable.md) + [Utilizzo delle chiavi gestite dal cliente per DNSSEC](dns-configuring-dnssec-cmk-requirements.md) + [Utilizzo delle chiavi per la firma dei tasti () KSKs](dns-configuring-dnssec-ksk.md) + [Chiave KMS e gestione ZSK in Route 53](dns-configuring-dnssec-zsk-management.md) + [Prove DNSSEC dell'inesistenza in Route 53](dns-configuring-dnssec-proof-of-nonexistence.md) + [Risoluzione dei problemi relativi alla firma DNSSEC](dns-configuring-dnssec-troubleshoot.md) # Abilitazione della firma DNSSEC e creazione di una catena di attendibilità **** I passaggi incrementali si applicano al proprietario della zona ospitata e al manutentore della zona padre. Questa può essere la stessa persona, ma qualora non fosse cos', il proprietario della zona dovrebbe notificare e lavorare con il manutentore della zona padre. Ti suggeriamo di seguire i passaggi di questo articolo per far firmare e includere la tua zona nella catena di fiducia. I seguenti passaggi ridurranno al minimo il rischio di onboarding su DNSSEC. **Nota** Assicurati di leggere i prerequisiti prima di iniziare in [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md). Per abilitare la firma DNSSEC, è necessario seguire tre fasi, come descritto nelle sezioni seguenti. **Topics** + [Fase 1: preparazione per l'abilitazione della firma DNSSEC](#dns-configuring-dnssec-enable-signing-step-1) + [Fase 2: abilitazione della firma DNSSEC e creazione di una KSK](#dns-configuring-dnssec-enable) + [Fase 3: come stabilire una catena di attendibilità](#dns-configuring-dnssec-chain-of-trust) ## Fase 1: preparazione per l'abilitazione della firma DNSSEC Le fasi di preparazione consentono di ridurre al minimo il rischio di onboarding su DNSSEC monitorando la disponibilità della zona e riducendo i tempi di attesa tra l'abilitazione della firma e l'inserimento del registro Delegation Signer (DS). **Per preparare l'abilitazione della firma DNSSEC** 1. Monitora la disponibilità della zona. È possibile monitorare la zona per verificare la disponibilità dei nomi di dominio. Questo può aiutarti a risolvere eventuali problemi che potrebbero giustificare un ripristino dello stato precedente dopo aver abilitato la firma DNSSEC. È possibile monitorare i nomi di dominio con la maggior parte del traffico utilizzando la registrazione delle query. Per ulteriori informazioni su come impostare la registrazione delle query, consulta [Monitoraggio di Amazon Route 53](monitoring-overview.md). Il monitoraggio può essere effettuato tramite uno script di shell o un servizio di terze parti. Tuttavia, non dovrebbe essere l'unico segnale per determinare se sia necessario un ripristino dello stato precedente. Inoltre, potresti ricevere feedback dai tuoi clienti a causa della mancata disponibilità di un dominio. 1. Abbassa il TTL massimo della zona. Il TTL massimo della zona è il registro TTL più lungo della zona. Nella seguente zona di esempio, il TTL massimo della zona è 1 giorno (86.400 secondi). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) L'abbassamento del TTL massimo della zona contribuirà a ridurre il tempo di attesa tra l'abilitazione della firma e l'inserimento del registro Delegation Signer (DS). Ti suggeriamo di abbassare il TTL massimo della zona a 1 ora (3.600 secondi). Ciò permette di eseguire il ripristino allo stato precedente dopo appena un'ora, se un resolver ha problemi con la memorizzazione nella cache dei registri firmati. **Ripristino dello stato precedente**: annulla le modifiche TTL. 1. Abbassa il campo minimo SOA TTL e SOA. Il campo minimo SOA è l'ultimo campo nei dati del registro SOA. Nel seguente registro SOA di esempio, il campo minimo ha il valore di 5 minuti (300 secondi). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) Il campo minimo SOA TTL e SOA determina per quanto tempo i resolver ricordano le risposte negative. Dopo aver abilitato la firma, i server dei nomi Route 53 iniziano a restituire i registri NSEC per le risposte negative. L'NSEC contiene informazioni che i resolver potrebbero utilizzare per sintetizzare una risposta negativa. Se è necessario eseguire il ripristino dello stato precedente a causa di informazioni NSEC che hanno causato l'assunzione di una risposta negativa per un nome da parte di un resolver, è sufficiente attendere il massimo del campo SOA TTL e il campo minimo SOA affinché il resolver interrompa l'assunzione. **Ripristino dello stato precedente:** annulla le modifiche SOA. 1. Assicurati che le modifiche ai campi minimi TTL e SOA siano efficaci. Utilizzalo [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)per assicurarti che le modifiche apportate finora siano state propagate a tutti i server DNS di Route 53. ## Fase 2: abilitazione della firma DNSSEC e creazione di una KSK È possibile abilitare la firma DNSSEC e creare una chiave di firma delle chiavi (KSK) utilizzando AWS CLI o sulla console Route 53. + [CLI](#dnssec_CLI) + [Console](#dnssec_console) Quando fornisci o crei una chiave KMS, esistono diversi requisiti. Per ulteriori informazioni, consulta [Utilizzo delle chiavi gestite dal cliente per DNSSEC](dns-configuring-dnssec-cmk-requirements.md). ------ #### [ CLI ] Puoi usare una chiave già esistente, oppure crearne una eseguendo un comando AWS CLI come il seguente usando i propri valori per `hostedzone_id`, `cmk_arn`, `ksk_name`, e `unique_string` (per rendere unica la richiesta): ``` 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 ``` Per ulteriori informazioni sulle chiavi gestite dal cliente, consulta [Utilizzo delle chiavi gestite dal cliente per DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Consulta anche [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html). Per abilitare la firma DNSSEC, esegui un AWS CLI comando come il seguente, utilizzando il tuo valore per: `hostedzone_id` ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` [Per ulteriori informazioni, vedere [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)e EnableHostedZone DNSSEC.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) ------ #### [ Console ] **Come abilitare la firma DNSSEC e creare una KSK** 1. Accedi Console di gestione AWS e apri la console Route 53 all'indirizzo. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione scegli **Zone ospitate** e seleziona una zona ospitata per la quale desideri abilitare la firma DNSSEC. 1. Nella scheda **Firma DNSSEC**, scegli **Abilita firma DNSSEC**. **Nota** Se l'opzione in questa sezione è **Disabilita firma DNSSEC**, allora la fase iniziale dell'abilitazione della firma DNSSEC è già stata completata. Assicurati di stabilire, o che esista già, una catena di attendibilità per la zona ospitata per DNSSEC. Per ulteriori informazioni, consulta [Fase 3: come stabilire una catena di attendibilità](#dns-configuring-dnssec-chain-of-trust). 1. Nella sezione **Key-signing key (KSK) creation** (Creazione di chiave di firma chiave (KSK)), scegli **Create new KSK** (Crea una nuova KSK), e sotto **Provide KSK name** Fornisci il nome KSK), inserisci un nome per il KSK che Route 53 creerà per te. I nomi possono contenere solo lettere, numeri e caratteri di sottolineatura (\$1). Deve essere univoco. 1. In **CMK gestita dal cliente**, scegli la chiave gestita dal cliente per Route 53 da utilizzare quando crea la KSK. È possibile utilizzare una chiave gestita dal cliente esistente che si applica alla firma DNSSEC oppure creare una nuova chiave gestita dal cliente. Quando fornisci o crei una chiave gestita dal cliente, esistono diversi requisiti da rispettare. Per ulteriori informazioni, consulta [Utilizzo delle chiavi gestite dal cliente per DNSSEC](dns-configuring-dnssec-cmk-requirements.md). 1. Specifica l'alias per una chiave gestita dal cliente esistente. Se desideri utilizzare una nuova chiave gestita dal cliente, inserisci un alias per la chiave gestita dal cliente e Route 53 ne creerà una automaticamente. **Nota** Se scegli di fare in modo che Route 53 crei una chiave gestita dal cliente, tieni presente che si applicano addebiti separati per ogni chiave gestita dal cliente. Per ulteriori informazioni, consulta [Prezzi di AWS Key Management Service](https://aws.amazon.com/kms/pricing/). 1. Scegli **Abilita firma DNSSEC**. ------ **Dopo aver abilitato la firma della zona, completa i seguenti passagi:** (che tu utilizzi la console o la CLI): 1. Assicurati che la firma della zona sia efficace. Se lo hai utilizzato AWS CLI, puoi utilizzare l'ID dell'operazione dall'output della `EnableHostedZoneDNSSEC()` chiamata per eseguire [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) o [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)per assicurarti che tutti i server DNS di Route 53 firmino le risposte (status =). `INSYNC` 1. Attendi almeno il TTL massimo della zona precedente. Attendi che i resolver svuotino tutti i registri non firmati dalla cache. Per raggiungere questo obiettivo è necessario attendere almeno il TTL massimo della zona precedente. Nella zona `example.com` sopra, il tempo di attesa sarebbe di 1 giorno. 1. Monitoraggio della presenza di segnalazioni di problemi dei clienti. Dopo aver abilitato la firma della zona, i clienti potrebbero iniziare a vedere dei problemi relativi ai dispositivi di rete e ai resolver. Il periodo di monitoraggio suggerito è di 2 settimane. Di seguito sono riportati esempi dei problemi che potresti incontrare: + Alcuni dispositivi di rete potrebbero limitare le dimensioni della risposta DNS a meno di 512 byte, il che è troppo poco per alcune risposte firmate. Questi dispositivi di rete devono essere riconfigurati per permettere dimensioni di risposta DNS più grandi. + Alcuni dispositivi di rete eseguono un'ispezione approfondita sulle risposte DNS e ne eliminano alcuni registri che non capisce, come quelli usati per DNSSEC. Questi dispositivi devono essere riconfigurati. + Alcuni resolver di clienti attestano di poter accettare una risposta UDP più ampia, rispetto a quella supportata dalla rete. È possibile testare le funzionalità di rete e configurare i resolver in modo appropriato. Per ulteriori informazioni, consulta [Server di test delle dimensioni delle risposte DNS](https://www.dns-oarc.net/oarc/services/replysizetest/). **Rollback:** chiama [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html), quindi ripristina i passaggi. [Fase 1: preparazione per l'abilitazione della firma DNSSEC](#dns-configuring-dnssec-enable-signing-step-1) ## Fase 3: come stabilire una catena di attendibilità Dopo aver abilitato la firma DNSSEC per una zona ospitata in Route 53, stabilisci una catena di attendibilità per la zona ospitata per completare la configurazione della firma DNSSEC. A tale scopo è possibile creare un record Delegation Signer (DS) nella zona ospitata *padre*, per la zona ospitata, utilizzando le informazioni fornite da Route 53. A seconda della posizione in cui il dominio è registrato, aggiungi il record alla zona ospitata padre in Route 53 o in un altro registrar di dominio. **Come stabilire una catena di attendibilità per la firma DNSSEC** 1. Accedi Console di gestione AWS e apri la console Route 53 all'indirizzo. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione scegli **Zone ospitate** e seleziona una zona ospitata per la quale stabilire una catena di attendibilità di DNSSEC. *È necessario abilitare prima la firma DNSSEC.* 1. Nella scheda **Firma DNSSEC**, in **Firma DNSSEC**, scegli **Visualizza informazioni per creare record DS**. **Nota** Se l'opzione **Visualizza le informazioni per creare un record DS** non viene visualizzata in questa sezione, prima di stabilire la catena di attendibilità è necessario abilitare la firma DNSSEC. Scegli **Enable DNSSEC signing** (Abilita firma DNSSEC) e completa le fasi come descritte in [Fase 2: abilitazione della firma DNSSEC e creazione di una KSK](#dns-configuring-dnssec-enable), quindi torna a queste fasi per stabilire la catena di attendibilità. 1. In **Stabilisci una catena di attendibilità**, scegli **Registrar Route 53** o **Un altro registrar di dominio**, a seconda di dove è registrato il tuo dominio. 1. Usa i valori forniti dalla fase 3 per creare un registro DS per la zona ospitata padre in Route 53. Se il tuo dominio non è ospitato su Route 53, utilizza i valori forniti per creare un registro DS sul sito Web del registrar di domini. Stabilisci una catena di fiducia per la zona principale: + Se il tuo dominio è gestito tramite Route 53, procedi nel seguente modo: Assicurati di configurare l'algoritmo di firma (ECDSAP256SHA256 e tipo 13) e l'algoritmo digest (SHA-256 e tipo 2) corretti. Se Route 53 è il tuo registrar, procedi come segue nella console Route 53: 1. Prendi nota dei valori di **Tipo di chiave**,**Algoritmo di firma** e **Chiave pubblica**. Nel riquadro di navigazione seleziona **Registered domains (Domini registrati)**. 1. **Seleziona un dominio, quindi, nella scheda **Chiavi DNSSEC, scegli Aggiungi chiave**.** 1. Nella finestra di dialogo **Manage DNSSEC keys** (Gestisci le chiavi DNSSEC), scegli l'opzione appropriata di **Key type** (Tipo di chiave) e **Algorithm** (Algoritmo) per **Route 53 registrar** (Registrar Route 53) dai menu a discesa. 1. Copia la **chiave pubblica** per il registrar Route 53. Nella finestra di dialogo **Manage DNSSEC keys** (Gestisci chiavi DNSSEC), incolla il valore nella casella **Public key** (Chiave pubblica). 1. Scegliere **Aggiungi**. Route 53 aggiungerà il record DS alla zona padre dalla chiave pubblica. Ad esempio, se il dominio è `example.com`, il record DS viene aggiunto alla zona DNS .com. + Se il tuo dominio è gestito su un altro registro, segui le istruzioni nella sezione **Un altro registrar di domini**. Per assicurarti che i passaggi seguenti procedano senza intoppi, introduci un DS TTL basso nella zona padre. Qualora sia necessario ripristinare lo stato precedente delle modifiche, per un ripristino più rapido, noi suggeriamo di impostare DS TTL su 5 minuti (300 secondi). + Stabilisci una catena di fiducia per la zona riservata ai minori: Se la tua zona padre è amministrata da un altro registro, contatta il registrar per introdurre il registro DS per la tua zona. In genere non è possibile regolare il TTL del registro DS. + Se la tua zona padre è ospitata su Route 53, contatta il proprietario della zona padre per introdurre il registro DS per la tua zona. Fornisci il `$ds_record_value` al proprietario della zona padre. Puoi ottenerla facendo clic su **Visualizza informazioni per creare il record DS** nella console e copiando il campo del **record DS**, oppure chiamando l'API [GetDNSsec](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) e recuperando il valore del campo '': DSRecord ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` Il proprietario della zona padre può inserire il registro cord tramite la console Route 53 o la CLI. + Per inserire il record DS utilizzando AWS CLI, il proprietario della zona principale crea e nomina un file JSON simile all'esempio seguente. Il proprietario della zona padre potrebbe nominare il file in modo simile a questo: `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" } ] } } ] } } ``` Quindi, esegui il comando riportato di seguito: ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + Per inserire il registro cord DS utilizzando la console, Apri la console Route 53 all'indirizzo [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). Nel pannello di navigazione, scegli **Hosted zones** (Zone ospitate), il nome della tua zona ospitata e quindi cliccare il pulsante **Create record** (Crea registro). In **Routing policy** (Policy di routing), assicurati di scegliere il routing semplice. Nel campo **Nome del record**, inserisci lo stesso nome di`$zone_name`, seleziona DS dal menu a discesa **Tipo di record**, inserisci il valore di `$ds_record_value` nel campo **Valore** e scegli **Crea** record. **Ripristino dello stato precedente:** rimuovi il DS dalla zona padre, attendi il DS TTL e quindi esegui il ripristino dello stato precedente dei passaggi per stabilire l'attendibilità. Se la zona padre è ospitata su Route 53, il proprietario della zona padre può modificare l'`Action` da `UPSERT` a`DELETE` nel file JSON ed esegui nuovamente l'interfaccia CLI di esempio sopra. 1. Attendi la propagazione degli aggiornamenti in base al TTL per i record di dominio. Se la zona principale si trova sul servizio DNS Route 53, il proprietario della zona principale può confermare la propagazione completa tramite l'API. [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) In caso contrario, è possibile sondare periodicamente la zona padre per verificare la presenza del registro DS, quindi attendere altri 10 minuti dopo per aumentare la probabilità che l'inserimento del registro DS venga completamente propagato. Si noti che alcuni registrar hanno pianificato l'inserimento di DS, ad esempio una volta al giorno. Quando si introduce il registro Delegation Signer (DS) nella zona padre, i resolver convalidati che hanno raccolto il DS inizieranno a convalidare le risposte dalla zona. Per assicurarti che i passaggi per stabilire l'attendibilità procedano senza intoppi, completa quanto segue: 1. Trova il massimo NS TTL. Sono disponibili 2 set di registri NS associati alle zone: + Registro NS delegation: questo è il registro NS per la tua zona detenuto dalla zona padre. Puoi trovarlo eseguendo i seguenti comandi Unix (se la tua zona è example.com, la zona padre è com): `dig -t NS com` Seleziona uno dei registri NS e quindi esegui quanto segue: `dig @one of the NS records of your parent zone -t NS example.com` Ad esempio: `dig @b.gtld-servers.net. -t NS example.com` + Il registro NS nella zona: questo è il registro NS nella tua zona. Per aggiungerlo, puoi eseguire il comando Unix seguente: `dig @one of the NS records of your zone -t NS example.com` Ad esempio: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Nota il TTL massimo per entrambe le zone. 1. Attendi il massimo NS TTL. Prima dell'inserimento del DS, i resolver ricevono una risposta firmata, ma non convalidano la firma. Quando il registro DS viene inserito, i resolver non lo vedono fino alla scadenza del registri NS per la zona. Quando i resolver recupererà nuovamente il registro NS, verrà restituito anche il registro DS. Se il cliente sta eseguendo un resolver su un host con un clock non sincronizzato, assicurati che quest'ultimo sia entro 1 ora dall'ora corretta. Dopo aver completato questo passaggio, tutti i resolver compatibili con DNSSEC convalideranno la tua zona. 1. Osserva la risoluzione dei nomi. Dovresti osservare che non ci sono problemi con i resolver che convalidano la tua zona. Assicurati di tenere conto anche del tempo necessario ai tuoi clienti per segnalarti i problemi. Noi suggeriamo di monitorare fino a 2 settimane. 1. (Facoltativo) Allunga DS e NS. TTLs Se sei soddisfatto della configurazione, puoi salvare le modifiche apportate a TTL e SOA. Nota che Route 53 limita il TTL a 1 settimana, per le zone firmate. Per ulteriori informazioni, consulta [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md). Se è possibile modificare il DS TTL, suggeriamo di impostarlo su 1 ora. # Disabilitazione della firma DNSSEC I passaggi per disabilitare l'accesso DNSSEC nella Route 53 variano a seconda della catena di attendibilità di cui fa parte la zona ospitata. Ad esempio, la zona ospitata potrebbe avere una zona padre con un record Delegation Signer (DS) come parte di una catena di attendibilità. La zona ospitata potrebbe anche essere essa stessa una zona padre per le zone figlio che hanno abilitato la firma DNSSEC, che è un'altra parte della catena di attendibilità. Esamina e determina l'intera catena di attendibilità per la zona ospitata prima di eseguire la procedura per disattivare la firma DNSSEC. La catena di attendibilità per la zona ospitata che abilita la firma DNSSEC deve essere annullata con attenzione quando si disabilita la firma. Per rimuovere la zona ospitata dalla catena di attendibilità, rimuovi tutti i record DS esistenti per la catena di attendibilità che include questa zona ospitata. Ciò significa che è necessario completare le operazioni seguenti nell'ordine: 1. Rimuovi tutti i record DS presenti in questa zona ospitata per le zone figlio che fanno parte di una catena di attendibilità. 1. Rimuovi il registro DS della zona padre. Se disponi di un'isola di attendibilità (dove non ci sono registri DS nella zona padre e nessun registro DS per le zone figlio), puoi ignorare questo passaggio. 1. Se non riesci a rimuovere i record DS, per rimuovere la zona dalla catena di attendibilità, rimuovi i record NS dalla zona padre. Per ulteriori informazioni, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md). I seguenti passaggi incrementali ti permettono di monitorare l'efficacia dei singoli passaggi per evitare problemi di disponibilità DNS nella tua zona. **Come disabilitare la firma DNSSEC** 1. Monitora la disponibilità della zona. È possibile monitorare la zona per verificare la disponibilità dei nomi di dominio. Questo può aiutarti a risolvere eventuali problemi che potrebbero giustificare un ripristino dello stato precedente dopo aver abilitato la firma DNSSEC. È possibile monitorare i nomi di dominio con la maggior parte del traffico utilizzando la registrazione delle query. Per ulteriori informazioni su come impostare la registrazione delle query, consulta [Monitoraggio di Amazon Route 53](monitoring-overview.md). Il monitoraggio può essere effettuato tramite uno script di shell o tramite un servizio a pagamento. Tuttavia, non dovrebbe essere l'unico segnale per determinare se sia necessario un ripristino dello stato precedente. Inoltre, potresti ricevere feedback dai tuoi clienti a causa della mancata disponibilità di un dominio. 1. Trova l'attuale DS TTL. Puoi trovare il DS TTL eseguendo il seguente comando Unix: `dig -t DS example.com example.com` 1. Trova il massimo NS TTL. Sono disponibili 2 set di registri NS associati alle zone: + Registro NS delegation: questo è il registro NS per la tua zona detenuto dalla zona padre. Puoi modificare questo comportamento eseguendo il seguente comando Unix: Per prima cosa trova il NS della tua zona padre (se la tua zona è example.com, la zona padre è com): `dig -t NS com` Seleziona uno dei registri NS e quindi esegui quanto segue: `dig @one of the NS records of your parent zone -t NS example.com` Ad esempio: `dig @b.gtld-servers.net. -t NS example.com` + Il registro NS nella zona: questo è il registro NS nella tua zona. Per aggiungerlo, puoi eseguire il comando Unix seguente: `dig @one of the NS records of your zone -t NS example.com` Ad esempio: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Nota il TTL massimo per entrambe le zone. 1. Rimuovi il registro DS della zona padre. Contatta il proprietario della zona padre per rimuovere il registro DS. **Ripristino dello stato precedente:** reinserisci il record DS, conferma che l'inserimento DS è efficace e attendi l'NS TTL massimo (non DS) prima che tutti i resolver ricomincino a convalidare. 1. Conferma che la rimozione del DS è efficace. Se la zona principale si trova sul servizio DNS Route 53, il proprietario della zona principale può confermare la propagazione completa tramite l'API. [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) In caso contrario, è possibile sondare periodicamente la zona padre per verificare la presenza del registro DS, quindi attendere altri 10 minuti per aumentare la probabilità che la rimozione del registro DS venga completamente propagata. Nota che alcuni registrar hanno pianificato la rimozione del DS, ad esempio una volta al giorno. 1. Aspetta il DS TTL. Attendere che tutti i resolver non siano scaduti il registro DS dalle loro cache. 1. Disabilita la firma DNSSEC e disattiva la chiave di firma chiave (KSK) . + [CLI](#CLI_dnssec_disable) + [Console](#console_dnssec_disable) ------ #### [ CLI ] Chiama [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) e. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs Esempio: ``` 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 ] **Come disabilitare la firma DNSSEC** 1. Accedi a Console di gestione AWS e apri la console Route 53 all'indirizzo. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione scegli **Zone ospitate** e seleziona una zona ospitata per la quale desideri disabilitare la firma DNSSEC. 1. Nella scheda **Firma DNSSEC**, scegli **Disabilita firma DNSSEC**. 1. Nella pagina **Disabilita firma DNSSEC** seleziona una delle seguenti opzioni, a seconda dello scenario per la zona per cui disattivi la firma DNSSEC. + **Solo zona padre**: questa zona ha una zona padre con un record DS. In questo scenario, è necessario rimuovere il record DS della zona padre. + **Solo zone figlio**: questa zona ha un record DS per una catena di attendibilità con una o più zone figlio. In questo scenario, è necessario rimuovere il record DS della zona. + **Zone padre e figlio**: questa zona ha sia un record DS per una catena di attendibilità con una o più zone figlio *e* una zona padre con un record DS. Per questo scenario, completa le operazioni seguenti nell'ordine riportato: 1. Rimuovi i record DS della zona. 1. Rimuovi i record DS della zona padre. Se possiedi un'isola di fiducia, puoi ignorare questa fase. 1. Determina il TTL per ogni registro DS che rimuovi nella fase 4 e, prima di continuare, assicurati che il periodo TTL più lungo sia scaduto. 1. Seleziona la casella di controllo per confermare di aver seguito i passi nell'ordine. 1. Digita *disable* nel campo, come riportato, quindi scegli **Disabilita**. **Come disattivare la chiave di firma chiave (KSK)** 1. Accedi Console di gestione AWS e apri la console Route 53 all'indirizzo [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. Nel pannello di navigazione scegli **Hosted zones** (Zone ospitate) e seleziona una zona ospitata per la quale desideri disabilitare la firma DNSSEC. 1. **Nella sezione **Chiavi di firma con chiave (KSKs)**, scegli il KSK che desideri disattivare e, in **Azioni**, scegli **Modifica KSK, imposta lo stato KSK** **su **Inattivo**, quindi scegli Salva KSK**.** ------ **[ActivateKeySigningKeyEnableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)[Rollback: chiamata e DNSSEC.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)** APIs Esempio: ``` 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. Conferma che la disattivazione della firma della zona è efficace. Usa l'ID della `EnableHostedZoneDNSSEC()` chiamata da eseguire [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)per assicurarti che tutti i server DNS di Route 53 abbiano smesso di firmare le risposte (status =). `INSYNC` 1. Osserva la risoluzione dei nomi. Dovresti osservare che non ci sono problemi che causano i resolver da convalidare la tua zona. Attendi 1-2 settimane, per tenere conto anche del tempo necessario ai tuoi clienti per segnalarti i problemi. 1. (Facoltativo) Pulizia. Se non riabiliterai la firma, puoi ripulire il processo [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)ed eliminare KSKs la corrispondente chiave gestita dal cliente per risparmiare sui costi. # Utilizzo delle chiavi gestite dal cliente per DNSSEC Quando abiliti l'accesso DNSSEC in Amazon Route 53, Route 53 crea una chiave per l'identificazione delle chiavi (KSK) per tuo conto. Per creare un KSK, Route 53 deve utilizzare una chiave gestita dal cliente AWS Key Management Service che supporti DNSSEC. In questa sezione vengono descritti i dettagli e i requisiti per la chiave gestita dal cliente che sono utili quando si lavora con il protocollo DNSSEC. Quando utilizzi chiavi gestite dal cliente per DNSSEC, tieni presente quanto segue: + La chiave gestita dal cliente utilizzata con la firma DNSSEC deve trovarsi nella regione Stati Uniti orientali (Virginia settentrionale). + La chiave gestita dal cliente deve essere una [chiave asimmetrica gestita dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) con una [specifica della chiave ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). Queste chiavi gestite dal cliente vengono utilizzate solo per la firma e la verifica. Per informazioni sulla creazione di una chiave gestita dal cliente asimmetrica, consulta [Creazione di chiavi gestite dal cliente asimmetriche](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) nella Guida per gli sviluppatori. AWS Key Management Service Per informazioni su come trovare la configurazione crittografica di una chiave gestita dal cliente esistente, consulta [Visualizzazione della configurazione crittografica delle chiavi gestite dal cliente nella Guida per gli sviluppatori](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html). AWS Key Management Service + Se crei personalmente una chiave gestita dal cliente da utilizzare con DNSSEC in Route 53, è necessario includere le istruzioni di policy specifiche della chiave che concedano a Route 53 le autorizzazioni richieste. Perché possa creare una KSK per tuo conto, Route 53 deve poter accedere alla chiave gestita dal cliente. Per ulteriori informazioni, consulta [Autorizzazioni delle chiavi gestite dal cliente di Route 53 richieste per la firma DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). + Route 53 può creare una chiave gestita dal cliente AWS KMS da utilizzare con la firma DNSSEC senza autorizzazioni aggiuntive. AWS KMS Tuttavia, se desideri modificare la chiave dopo la sua creazione è necessario disporre di autorizzazioni specifiche. Le autorizzazioni specifiche che è necessario avere sono: `kms:UpdateKeyDescription`, `kms:UpdateAlias` e `kms:PutKeyPolicy`. + Tieni presente che si applicano addebiti separati per ogni chiave gestita dal cliente di cui disponi, indipendentemente dal fatto che tu crei la chiave gestita dal cliente o che Route 53 la crei per te. Per ulteriori informazioni, consultare [Prezzi di AWS Key Management Service](https://aws.amazon.com/kms/pricing/). # Utilizzo delle chiavi per la firma dei tasti () KSKs Quando abiliti la firma DNSSEC, Route 53 crea una chiave per la firma delle chiavi (KSK) per tuo conto. Puoi averne fino a due KSKs per zona ospitata in Route 53. Dopo aver abilitato la firma DNSSEC, puoi aggiungere, rimuovere o modificare il tuo. KSKs Tieni presente quanto segue quando lavori con: KSKs + Prima di poter eliminare una KSK, è necessario modificare la KSK per impostarne lo stato su **Inattivo**. + Quando la firma DNSSEC è abilitata per una zona ospitata, Route 53 limita il TTL a una settimana. Se imposti un TTL per i record nella zona ospitata su più di una settimana, non viene visualizzato un errore ma Route 53 applica un TTL di una settimana. + Per evitare interruzioni di una zona e che il dominio diventi indisponibile, è necessario risolvere rapidamente gli errori DNSSEC. Ti consigliamo vivamente di impostare un CloudWatch allarme che ti avvisi ogni volta che viene rilevato un `DNSSECKeySigningKeysNeedingAction` errore `DNSSECInternalFailure` or. Per ulteriori informazioni, consulta [Monitoraggio delle zone ospitate tramite Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + Le operazioni KSK descritte in questa sezione consentono di ruotare le zone. KSKs Per ulteriori informazioni e un step-by-step esempio, consulta *DNSSEC Key Rotation* nel post del blog [Configurazione della firma e della convalida DNSSEC](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) con Amazon Route 53. Per utilizzare in Console di gestione AWS, segui le indicazioni riportate KSKs nelle sezioni seguenti. ## Aggiunta di una chiave di firma delle chiavi (KSK) Quando abiliti la firma DNSSEC, Route 53 crea una chiave per la firma delle chiavi (KSK) per tuo conto. È possibile aggiungere anche KSKs separatamente. Puoi averne fino a due KSKs per zona ospitata in Route 53. Quando si crea un KSK, è necessario fornire o richiedere a Route 53 di creare una chiave gestita dal cliente da utilizzare con il KSK. Quando fornisci o crei una chiave gestita dal cliente, esistono diversi requisiti da rispettare. Per ulteriori informazioni, consulta [Utilizzo delle chiavi gestite dal cliente per DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Completa queste fasi per aggiungere una KSK nella Console di gestione AWS. **Come aggiungere una KSK** 1. Accedi a Console di gestione AWS e apri la console Route 53 all'indirizzo. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione scegli **Zone ospitate** e seleziona una zona ospitata. 1. **Nella scheda **Firma DNSSEC**, in **Chiavi di firma a chiave (KSKs)**, scegli **Passa alla visualizzazione avanzata**, quindi, in **Azioni**, scegli Aggiungi KSK.** 1. In **KSK**, inserisci un nome per la KSK che Route 53 creerà per te. I nomi possono contenere solo lettere, numeri e caratteri di sottolineatura (\$1). Deve essere univoco. 1. Inserisci l'alias per una chiave gestita dal cliente che si applica alla firma DNSSEC o inserisci un alias per una nuova chiave gestita dal cliente che Route 53 creerà per te. **Nota** Se scegli di fare in modo che Route 53 crei una chiave gestita dal cliente, tieni presente che si applicano addebiti separati per ogni chiave gestita dal cliente. Per ulteriori informazioni, consultare [Prezzi di AWS Key Management Service](https://aws.amazon.com/kms/pricing/). 1. Scegli **Crea KSK**. ## Modifica di una chiave di firma delle chiavi (KSK) È possibile modificare lo stato di una KSK in modo che sia **Attiva** o **Inattiva**. Quando una KSK è attiva, Route 53 la utilizza per la firma DNSSEC. Prima di poter eliminare una KSK, è necessario modificare la KSK per impostarne lo stato su **Inattivo**. Completa queste fasi per aggiungere una KSK nella Console di gestione AWS. **Come modificare una KSK** 1. Accedi Console di gestione AWS e apri la console Route 53 all'indirizzo. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione scegli **Zone ospitate** e seleziona una zona ospitata. 1. **Nella scheda **Firma DNSSEC**, in **Chiavi di firma a chiave (KSKs)**, scegli **Passa alla visualizzazione avanzata**, quindi, in **Azioni**, scegli Modifica KSK.** 1. Apporta gli aggiornamenti desiderati alla KSK, quindi scegli **Salva**. ## Eliminazione di una chiave di firma delle chiavi (KSK) Prima di poter eliminare una KSK, è necessario modificare la KSK per impostarne lo stato su **Inattivo**. Uno dei motivi per cui potresti eliminare un KSK è come parte della rotazione delle chiavi di routine. Una best practice consiste nel ruotare periodicamente le chiavi di crittografia. È possibile che l'organizzazione disponga di indicazioni standard per quanto spesso ruotare le chiavi. Completa queste fasi per eliminare una KSK nella Console di gestione AWS. **Come eliminare una KSK** 1. Accedi a Console di gestione AWS e apri la console Route 53 all'indirizzo. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione scegli **Zone ospitate** e seleziona una zona ospitata. 1. **Nella scheda **Firma DNSSEC**, in **Chiavi di firma a chiave (KSKs)**, scegli **Passa alla visualizzazione avanzata**, quindi in **Azioni**, scegli Elimina KSK.** 1. Segui le istruzioni per confermare l'eliminazione della KSK. # Chiave KMS e gestione ZSK in Route 53 Questa sezione descrive la pratica corrente utilizzata da Route 53 per le zone abilitate per la firma DNSSEC. **Nota** Route 53 utilizza la seguente regola, che potrebbe essere modificata. Qualsiasi modifica futura non ridurrà la posizione di sicurezza della tua zona o di Route 53. **In che modo Route 53 utilizza il codice associato al tuo KSK AWS KMS ** In DNSSEC, la KSK viene utilizzata per generare la firma del registro della risorsa (RRSIG) per il set di registri della risorsa DNSKEY. Tutti `ACTIVE` KSKs sono utilizzati nella generazione RRSIG. Route 53 genera un RRSIG chiamando l'`Sign` AWS KMS API sulla chiave KMS associata. Per ulteriori informazioni, consulta la sezione [Firma](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) nella *Guida di riferimento dell'API AWS KMS *. Questi RRSIGs non vengono conteggiati ai fini del limite stabilito per il record di risorse della zona. Il RRSIG ha una scadenza. Per RRSIGs evitare che scadano, RRSIGs vengono rinfrescati regolarmente rigenerandoli ogni uno-sette giorni. RRSIGs Vengono inoltre aggiornati ogni volta che si chiama uno di questi: 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) Ogni volta che Route 53 esegue un aggiornamento, ne generiamo 15 RRSIGs per coprire i prossimi giorni nel caso in cui la chiave KMS associata diventi inaccessibile. Per stimare il costo delle chiavi KMS, è possibile presumere un aggiornamento regolare una volta al giorno. Una chiave KMS potrebbe diventare inaccessibile in seguito a modifiche involontarie alla policy della chiave KMS. Una chiave KMS inaccessibile imposta lo stato della KSK associata su `ACTION_NEEDED`. Ti consigliamo vivamente di monitorare questa condizione impostando un CloudWatch allarme ogni volta che viene rilevato un `DNSSECKeySigningKeysNeedingAction` errore, perché i resolver di convalida inizieranno a fallire le ricerche dopo la scadenza dell'ultimo RRSIG. Per ulteriori informazioni, consulta [Monitoraggio delle zone ospitate tramite Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). **Modalità di gestione della ZSK della zona da parte di Route 53** Ogni nuova zona ospitata con firma DNSSEC abilitata avrà una chiave di firma zona (ZSK) `ACTIVE`. La ZSK viene generata separatamente per ogni zona ospitata ed è di proprietà di Route 53. L'algoritmo chiave corrente è. ECDSAP256 SHA256 Inizieremo a eseguire regolarmente la rotazione ZSK sulla zona entro 7-30 giorni dall'inizio della firma. Attualmente, Route 53 utilizza il metodo di sostituzione periodica delle chiavi previa pubblicazione. Per ulteriori informazioni, consulta la sezione [Sostituzione periodica delle chiavi previa pubblicazione](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). Questo metodo introduce un'altra ZSK nella zona. La rotazione viene ripetuta ogni 7-30 giorni. Route 53 sospenderà la rotazione ZSK se uno dei KSK della zona è in `ACTION_NEEDED` stato, perché Route 53 non sarà in grado di rigenerare i set di record di risorse RRSIGs per DNSKEY per tenere conto delle modifiche nello ZSK della zona. La rotazione ZSK riprende automaticamente dopo che la condizione è stata risolta. # Prove DNSSEC dell'inesistenza in Route 53 **Nota** Route 53 utilizza la seguente regola, che potrebbe essere modificata. Qualsiasi modifica futura non ridurrà la posizione di sicurezza della tua zona o di Route 53. In DNSSEC sono disponibili tre tipi di prova dell'inesistenza: + Prova dell'inesistenza di un registro corrispondente al nome della query. + Prova dell'inesistenza di un registro corrispondente al tipo di query. + Prova dell'esistenza di un registro jolly utilizzato per generare il registro in risposta. Route 53 implementa la prova dell'inesistenza di un registro corrispondente al nome della query utilizzando il metodo BL. Per ulteriori informazioni, consulta la sezione [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). È un metodo che produce una rappresentazione compatta della prova e impedisce l'ingresso nella zona. Nei casi in cui esiste un record che corrisponde al nome della query ma non al tipo di query (ad esempio, l'interrogazione per web.example). com/AAAA but there is only web.example.com/Apresent), restituiamo un record NSEC (next secure) minimo contenente tutti i tipi di record di risorse supportati. Quando Route 53 sintetizza una risposta da un registro con caratteri jolly, la risposta non sarà accompagnata da un successivo registro sicuro, o record NSEC per il carattere jolly. Tale registro NSEC viene utilizzato in alcune implementazioni, in genere quelle che eseguono la firma non in linea, per impedire che le firme dei registri della risorsa (RRSIG) nella risposta vengano riutilizzate per falsificare una risposta diversa. Route 53 utilizza la firma online per i record non DNSKey per generare una risposta RRSIGs specifica che non può essere riutilizzata per una risposta diversa. # Risoluzione dei problemi relativi alla firma DNSSEC Le informazioni contenute in questa sezione possono aiutarti a risolvere i problemi relativi alla firma DNSSEC, tra cui l'attivazione, la disabilitazione e l'utilizzo delle chiavi di firma delle chiavi (). KSKs Abilitazione di DNSSEC Prima di iniziare ad abilitare la firma DNSSEC, assicurati di aver letto i prerequisiti riportati in [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md). Disabilitazione di DNSSEC Per disabilitare in modo sicuro il DNSSEC, Route 53 verificherà se la zona di destinazione si trova nella catena di attendibilità. Verifica se l'elemento padre della zona di destinazione ha dei record NS e dei record DS della zona di destinazione. Se la zona di destinazione non è risolvibile pubblicamente, ad esempio se riceve una risposta SERVFAIL durante l'interrogazione di NS e DS, Route 53 non sarà in grado di determinare se è sicuro disabilitare DNSSEC. Puoi contattare la tua zona principale per risolvere questi problemi e riprovare a disabilitare il DNSSEC in un secondo momento. Lo stato della KSK è **Operazione necessaria** Un KSK può cambiare il suo stato in **Azione necessaria** (o `ACTION_NEEDED` in uno [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)stato) quando Route 53 DNSSEC perde l'accesso a un server corrispondente AWS KMS key (a causa di una modifica delle autorizzazioni o dell'eliminazione). AWS KMS key Se lo stato di una KSK è **Action needed** (Azione richiesta), significa che alla fine causerà un'interruzione della zona per i client che utilizzano i resolver di convalida DNSSEC e tu dovrai agire rapidamente per evitare che una zona di produzione diventi irrisolvibile. Per risolvere il problema, assicurati che la chiave gestita dal cliente su cui si basa la tua KSK sia abilitata e abbia le corrette autorizzazioni. Per ulteriori informazioni sulle autorizzazioni richieste, consulta [Autorizzazioni delle chiavi gestite dal cliente di Route 53 richieste per la firma DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). Dopo aver corretto il KSK, attivalo nuovamente utilizzando la console o il AWS CLI, come descritto in. [Fase 2: abilitazione della firma DNSSEC e creazione di una KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable) Per evitare che questo problema si verifichi in futuro, prendi in considerazione l'aggiunta di una Amazon CloudWatch metrica per tracciare lo stato del KSK, come suggerito in. [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md) Lo stato della KSK è **Errore interno** Quando un KSK presenta lo stato di **errore interno** (o `INTERNAL_FAILURE` in uno [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)stato), non è possibile lavorare con nessun'altra entità DNSSEC finché il problema non viene risolto. È necessario intervenire prima di poter utilizzare la firma DNSSEC, incluso l'utilizzo di questa KSK o di un'altra KSK. Per risolvere il problema, prova nuovamente ad attivare o disattivare la KSK. [Per risolvere il problema quando lavori con APIs, prova ad abilitare la firma ([EnableHostedZoneDNSSEC) o disabilitare la firma (DNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)). DisableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) È importante correggere i problemi **Errore interno**quanto prima. Non è possibile apportare altre modifiche alla zona ospitata fino a quando non si corregge il problema, ad eccezione delle operazioni per risolvere **Errore interno**.