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 di Amazon Route 53 come servizio DNS Puoi utilizzare Amazon Route 53 come servizio DNS per il dominio, ad esempio esempio.com. Se Route 53 è il tuo servizio DNS, instrada il traffico Internet al tuo sito Web traducendo i nomi dominio brevi, ad esempio www.esempio.com, in indirizzi IP numerici come 192.0.2.1, che i computer utilizzano per connettersi tra loro. Quando un utente digita il tuo nome dominio in un browser oppure invia un'e-mail, una query DNS viene inoltrata a Route 53, che risponde con il valore appropriato. Ad esempio, Route 53 potrebbe rispondere con l'indirizzo IP del server Web per esempio.com. **Hosting DNS vs. registrazione del dominio** Questo capitolo tratta l'utilizzo di Route 53 solo per l'hosting *DNS*. Ciò significa che la registrazione del dominio rimane presso il registrar attuale e continuerai a pagarlo per il rinnovo del dominio. Route 53 gestirà solo le tue impostazioni DNS e gestirà le query DNS per il tuo dominio. Se desideri trasferire la registrazione del tuo dominio anche su Route 53 (facendo di Route 53 sia il registrar che il servizio DNS), consulta e. [Lista di controllo prima del trasferimento per i trasferimenti di dominio](domain-transfer-checklist.md) [Trasferimento della registrazione per un dominio ad Amazon Route 53](domain-transfer-to-route-53.md) In questo capitolo verrà illustrato come configurare Route 53 per instradare il traffico Internet in modo corretto. Spiegheremo inoltre come migrare il servizio DNS a Route 53 se si sta utilizzando un altro servizio DNS e come utilizzare Route 53 come servizio DNS per un nuovo dominio. **Topics** + [Rendere Amazon Route 53 il servizio DNS per un dominio esistente](MigratingDNS.md) + [Configurazione del routing DNS per un nuovo dominio](dns-configuring-new-domain.md) + [Routing del traffico alle risorse](dns-routing-traffic-to-resources.md) + [Utilizzo delle zone ospitate](hosted-zones-working-with.md) + [Utilizzo dei record](rrsets-working-with.md) + [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md) + [Utilizzo AWS Cloud Map per creare record e controlli sanitari](autonaming.md) + [Comportamenti e limitazioni di DNS](DNSBehavior.md) + [Argomenti correlati](dns-configuring-related-topics.md) # Rendere Amazon Route 53 il servizio DNS per un dominio esistente Se stai trasferendo una o più registrazioni di dominio a Route 53 e al momento utilizzi un registrar del dominio che non offre un servizio DNS pagato, devi migrare il servizio DNS prima di migrare il dominio. In caso contrario, il registrar smetterà di fornire il servizio DNS durante il trasferimento dei domini e i siti Web e le applicazioni associate diventeranno non disponibili su Internet. Puoi migrare il servizio DNS anche dal registrar corrente a un altro fornitore di servizi DNS. Non è necessario utilizzare Route 53 come provider del servizio DNS per i domini registrati con Route 53. Il processo dipende dall'utilizzo o meno del dominio: + Se il dominio attualmente riceve traffico, ad esempio se gli utenti utilizzano il nome di dominio per navigare in un sito Web o accedere a un'applicazione Web, consulta [Rendere Route 53 il servizio DNS per un dominio in uso](migrate-dns-domain-in-use.md). + Se il dominio non riceve traffico (o riceve pochissimo traffico), consulta [Rendere Route 53 il servizio DNS per un dominio non attivo](migrate-dns-domain-inactive.md). Per entrambe le opzioni, il tuo dominio dovrebbe rimanere disponibile durante l'intero processo di migrazione. Tuttavia, nell'improbabile caso in cui ci siano problemi, la prima opzione ti consente di eseguire il rollback della migrazione in modo rapido. Con la seconda opzione, il tuo dominio potrebbe non essere disponibile per un paio di giorni. Se desideri metterti in contatto con un esperto di AWS, visita l'[assistenza alle vendite](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs). # Rendere Route 53 il servizio DNS per un dominio in uso Se desideri eseguire la migrazione del servizio DNS ad Amazon Route 53 per un dominio che attualmente riceve traffico, ad esempio se gli utenti utilizzano il nome di dominio per navigare in un sito Web o accedere a un'applicazione Web, esegui le procedure descritte in questa sezione. **Topics** + [Fase 1: ottieni la tua attuale configurazione DNS dal fornitore di servizi DNS attuale (facoltativo ma consigliato)](#migrate-dns-get-zone-file) + [Fase 2: crea una zona ospitata](#migrate-dns-create-hosted-zone) + [Fase 3: crea i record](#migrate-dns-create-records) + [Fase 4: riduzione delle impostazioni TTL](#migrate-dns-lower-ttl) + [Fase 5: (Se è stato configurato DNSSEC) Rimozione del record DS dalla zona padre](#migrate-remove-ds) + [Fase 6: Attendi la scadenza del vecchio TTL](#migrate-dns-wait-for-ttl) + [Fase 7: Aggiornamento dei record NS per utilizzare i server dei nomi di Route 53](#migrate-dns-change-name-servers-with-provider) + [Fase 8: Monitoraggio del traffico per il dominio](#migrate-dns-monitor-traffic) + [Fase 9: modifica il TTL per il record NS riportandolo a un valore superiore](#migrate-dns-change-ttl-back) + [Fase 10: Trasferimento della registrazione del dominio ad Amazon Route 53](#migrate-dns-transfer-domain-registration) + [Fase 11: Riabilitazione della firma DNSSEC (se necessario)](#migrate-dns-re-enable-dnssec) ## Fase 1: ottieni la tua attuale configurazione DNS dal fornitore di servizi DNS attuale (facoltativo ma consigliato) Quando esegui la migrazione del servizio DNS da un altro provider a Route 53, riproduci la configurazione DNS corrente in Route 53. In Route 53, è necessario creare una zona ospitata con lo stesso nome di dominio e creare i record nella zona ospitata. Ogni record indica il modo in cui desideri instradare il traffico per un determinato nome di dominio o di sottodominio. Ad esempio, quando qualcuno inserisce il tuo nome di dominio in un browser Web, desideri che il traffico venga indirizzato a un server Web nel tuo data center, a un'istanza Amazon EC2, a CloudFront una distribuzione o a qualche altra posizione? Il processo che usi dipende dalla complessità della tua attuale configurazione DNS: + **Se la tua attuale configurazione DNS è semplice**: se stai instradando il traffico Internet per pochi sottodomini a un piccolo numero di risorse, come server Web o bucket Amazon S3, puoi creare manualmente alcuni record nella console Route 53. + **Se la configurazione DNS corrente è più complessa e desideri solo riprodurre la configurazione corrente**: puoi semplificare la migrazione se puoi ottenere un file di zona dal provider di servizi DNS corrente e importare il file di zona in Route 53. (Non tutti i fornitori di servizi DNS offrono i file di zona.) Quando importi un file di zona, Route 53 riproduce automaticamente la configurazione esistente creando i record corrispondenti nella tua zona ospitata. Prova a chiedere al servizio clienti del tuo attuale fornitore di servizi DNS come ottenere un *file di zona* o un *elenco di record*. Per informazioni sul formato richiesto per il file di zona, consulta [Creazione di record mediante importazione di un file di zona](resource-record-sets-creating-import.md). + **Se la tua attuale configurazione DNS è più complessa e sei interessato alle caratteristiche di routing di Route 53**: esamina la seguente documentazione per vedere se desideri utilizzare le funzionalità di Route 53 che non sono disponibili da altri fornitori di servizi DNS. In questo caso, puoi creare record manualmente oppure importare un file di zona e quindi creare o aggiornare i record più tardi: + [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md)spiega i vantaggi dei record di alias Route 53, che indirizzano il traffico verso alcune AWS risorse, come CloudFront distribuzioni e bucket Amazon S3, gratuitamente. + [Scegliere una policy di routing](routing-policy.md) spiega le opzioni di routing di Route 53, ad esempio routing in base alla posizione degli utenti, routing in base alla latenza tra gli utenti e le risorse, routing in base all'integrità delle risorse e routing alle risorse in base ai pesi specificati. **Nota** Puoi anche importare un file di zona e successivamente modificare la configurazione per usufruire dei record alias e di policy di routing complesse. Se non sei in grado di ottenere un file di zona o se desideri creare manualmente record in Route 53, i record che molto probabilmente dovrai migrare includono i seguenti: + **Record A (Indirizzo)**: associa un nome di dominio o un nome di sottodominio all' IPv4 indirizzo (ad esempio, 192.0.2.3) della risorsa corrispondente + **Record AAAA (Indirizzo)**: associano un nome di dominio o un nome di sottodominio all' IPv6 indirizzo (ad esempio, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) della risorsa corrispondente + **Record di server di posta (MX)**: instradano il traffico ai server di posta + **Record CNAME**: reinstradano il traffico per un nome di dominio (esempio.net) a un altro nome di dominio (esempio.com) + **Record per altri tipi di record DNS supportati**: per un elenco dei tipi di record supportati, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). ## Fase 2: crea una zona ospitata Per indicare ad Amazon Route 53 come desideri instradare il traffico per il tuo dominio, crea una zona ospitata che ha lo stesso nome del tuo dominio, quindi crea i record nella zona ospitata. **Importante** Puoi creare una zona ospitata solo per un dominio che si dispone dell'autorizzazione per amministrare. Normalmente, questo significa che sei proprietario del dominio, ma potresti anche sviluppare un'applicazione per il registrant del dominio. Quando si crea una zona ospitata, Route 53 crea automaticamente un record di server di nomi (NS) e un record di origine di autorità (SOA) per la zona. Il record NS identifica il nome dei quattro server dei nomi che Route 53 ha associato alla tua zona ospitata. Per rendere Route 53 il servizio DNS per il tuo dominio, devi aggiornare la registrazione per il dominio in modo da utilizzare questi quattro server dei nomi. **Importante** Non creare ulteriori record di server dei nomi (NS) o origine di autorità (SOA) e non eliminare i record SOA e NS esistenti. **Come creare una zona ospitata** 1. Accedi Console di gestione AWS e [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)apri la console Route 53 all'indirizzo. 1. Se sei nuovo di Route 53, scegli **Nozioni di base**in **Gestione DNS** e scegli **Crea zone ospitate**. Se stai già utilizzando Route 53, scegli **Zone ospitate** nel pannello di navigazione, quindi scegli **Crea zone ospitate**. 1. Nel riquadro **Crea zona ospitata**, inserisci un nome di dominio e, facoltativamente, un commento. Per ulteriori informazioni su un'impostazione, apri il pannello della guida sul lato destro. Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). 1. Per **Tipo**, accetta il valore di default di **Zona ospitata pubblica**. 1. Scegli **Crea zona ospitata**. ## Fase 3: crea i record Una volta creata una zona ospitata, è necessario creare record nella stessa che definiscono il punto in cui si desidera instradare il traffico per un dominio (esempio.com) o sottodominio (www.esempio.com). Ad esempio, se desideri instradare il traffico per esempio.com e www.esempio.com a un server Web su un'istanza Amazon EC2, devi creare due record, uno denominato esempio.com e l'altro denominato www.esempio.com. In ogni record, è necessario specificare l'indirizzo IP per l'istanza EC2. Puoi creare record in diversi modi: **Importa un file di zona** Questo è il metodo più semplice se hai ottenuto un file di zona dal servizio DNS corrente in [Fase 1: ottieni la tua attuale configurazione DNS dal fornitore di servizi DNS attuale (facoltativo ma consigliato)](#migrate-dns-get-zone-file). Amazon Route 53 non è in grado di prevedere quando creare record alias o utilizzare tipi di routing speciali, ad esempio ponderati o di failover. Di conseguenza, se importi un file di zona, Route 53 crea record DNS standard mediante la policy di routing semplice. Per ulteriori informazioni, consulta [Creazione di record mediante importazione di un file di zona](resource-record-sets-creating-import.md). **Crea record individualmente nella console** Se non hai ottenuto un file di zona e desideri creare solo pochi record con una policy di routing semplice per iniziare, puoi creare i record nella console Route 53. Puoi creare sia record alias che non alias. Per ulteriori informazioni, consulta i seguenti argomenti: + [Scegliere una policy di routing](routing-policy.md) + [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md) + [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md) **Crea record a livello programmatico** È possibile creare record utilizzando uno dei AWS SDKs AWS CLI, o AWS Tools for Windows PowerShell. Per ulteriori informazioni, consulta la [documentazione di AWS](https://docs.aws.amazon.com/). Se utilizzi un linguaggio di programmazione che AWS non fornisce un SDK per, puoi anche utilizzare l'API Route 53. Per ulteriori informazioni, consulta il [riferimento API di Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/). ## Fase 4: riduzione delle impostazioni TTL L'impostazione TTL (time-to-live) per un record consente di specificare il periodo di tempo per cui desideri che il resolver DNS memorizzi nella cache i record e utilizzi le informazioni memorizzate nella cache. Quando il TTL scade, un resolver invia un'altra query al fornitore di servizi DNS per un dominio per ottenere le informazioni più recenti. L'impostazione TTL tipica per il record NS è 172800 secondi, o due giorni. Il record NS elenca i server dei nomi che il Domain Name System (DNS) può utilizzare per ottenere informazioni su come instradare il traffico per il tuo dominio. Abbassando il valore TTL per il record NS, sia con il tuo provider del servizio DNS corrente sia con Amazon Route 53, riduci i tempi di inattività per il dominio se rilevi un problema durante la migrazione del DNS a Route 53. Se non riduci il TTL, il tuo dominio potrebbe essere non disponibile su Internet per un massimo di due giorni in caso di problemi. **Nota** Alcuni risolutori completi possono memorizzare nella cache il TTL del record NS del server autorevole padre, per cui è necessario anche ridurre il TTL dei record NS registrati sul server DNS autorevole padre. È consigliabile modificare il TTL nei seguenti record NS: + Nel record NS nella zona ospitata per l'attuale fornitore di servizi DNS. (Il tuo attuale fornitore potrebbe utilizzare una terminologia diversa). + Nel record NS nella zona ospitata creata in [Fase 2: crea una zona ospitata](#migrate-dns-create-hosted-zone). **Per ridurre il TTL nel record NS con l'attuale fornitore di servizi DNS** + Utilizza il metodo fornito dall'attuale fornitore di servizi DNS per il dominio per modificare il valore TTL per il record NS nella zona ospitata per il tuo dominio. **Come ridurre l'impostazione TTL sul record NS in una zona ospitata di Route 53** 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. Seleziona **Hosted Zones (Zone ospitate)** nel pannello di navigazione. 1. Scegli il nome della zona ospitata. 1. Scegli il record NS, quindi **Modifica**. 1. Modifica il valore di **TTL (secondi)**. È consigliabile specificare un valore compreso tra 60 secondi e 900 secondi (15 minuti). 1. Scegli **Save changes** (Salva modifiche). ## Fase 5: (Se è stato configurato DNSSEC) Rimozione del record DS dalla zona padre Se hai configurato DNSSEC per il dominio, prima di eseguire la migrazione del dominio a Route 53 rimuovi il record Delegation Signer (DS) dalla zona padre. Se la zona padre è ospitata tramite Route 53 o un altro registrar, contattalo per rimuovere il record DS. Poiché al momento non è possibile abilitare la firma DNSSEC su due provider, è necessario rimuovere qualsiasi DS o DNSKEYs disattivare DNSSEC. Questo segnala temporaneamente ai resolver DNS di disabilitare la convalida DNSSEC. Nella [Fase 11](#migrate-dns-re-enable-dnssec), potrai riabilitare la convalida DNSSEC, se lo desideri, dopo aver completato la transizione a Route 53. Per ulteriori informazioni, consulta [Eliminazione di chiavi pubbliche per un dominio](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys). ## Fase 6: Attendi la scadenza del vecchio TTL Se il dominio è in uso, per esempio se gli utenti utilizzano il nome di dominio per navigare in un sito Web o accedere a un'applicazione Web, allora i resolver DNS hanno memorizzato nella cache i nomi del server dei nomi che sono stati fornito dal tuo provider di servizi DNS corrente. Un resolver DNS che ha memorizzato nella cache tali informazioni da pochi minuti, le salverà per quasi due giorni aggiuntivi. Per garantire che la migrazione del servizio DNS a Route 53 avvenga in una sola volta, attendi due giorni dopo aver abbassato il TTL. Dopo che il TTL di due giorni scade e i resolver richiedono i server di nomi per il tuo dominio, i resolver otterranno i server dei nomi attuali e il nuovo TTL che hai specificato in [Fase 4: riduzione delle impostazioni TTL](#migrate-dns-lower-ttl). ## Fase 7: Aggiornamento dei record NS per utilizzare i server dei nomi di Route 53 Per iniziare a utilizzare Amazon Route 53 come servizio DNS per un dominio, utilizzare il metodo fornito dal provider di servizi DNS corrente per sostituire i server dei nomi correnti nel record NS con i server dei nomi Route 53. **Nota** Quando si aggiorna il record NS con il provider di servizi DNS corrente per utilizzare i server dei nomi di Route 53, si sta aggiornando la configurazione DNS per il dominio. (Ciò è paragonabile all'aggiornamento del record NS nella zona ospitata Route 53 per un dominio, tranne che stai aggiornando l'impostazione con il servizio DNS da cui stai effettuando la migrazione.) **Come aggiornare il record NS nel registrar, o nella zona padre, per utilizzare i server dei nomi di Route 53** 1. Nella console Route 53, ottieni i server dei nomi per la tua zona ospitata: 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**. 1. Nella pagina **Zone ospitate**, scegli il nome per la zona ospitata applicabile. 1. Prendi nota dei quattro nomi indicati per **Server dei nomi** nella sezione **Dettagli della zona ospitata**. 1. Utilizza il metodo che viene fornito dall'attuale servizio DNS per il dominio per aggiornare il record NS per la zona ospitata. Se il dominio è registrato con Route 53, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md). Il processo dipende dal fatto che il servizio DNS corrente ti consenta o meno di eliminare i server dei nomi: **Se si è in grado di eliminare i nomi dei server** + Annota i server dei nomi correnti nel record NS per la zona ospitata. Se hai bisogno di ripristinare l'attuale configurazione DNS, questi sono i server che dovrai specificare. + Elimina gli attuali server dei nomi dal record NS. + Aggiorna il record NS con i nomi di tutti e quattro i server dei nomi di Route 53 ottenuti nella fase 1 di questa procedura. **Nota** Al termine, i soli server dei nomi nel record NS saranno i quattro server dei nomi di Route 53. **Se puoi eliminare i nomi dei server** + Scegli la possibilità di utilizzare i server dei nomi personalizzati. + Aggiungi tutti e quattro i server dei nomi di Route 53 ottenuti nella fase 1 di questa procedura. ## Fase 8: Monitoraggio del traffico per il dominio Monitora il traffico per il dominio, tra cui il traffico di applicazioni e siti Web o e-mail: + **Se il traffico rallenta o si interrompe**: utilizza il metodo fornito dal servizio DNS precedente per modificare i server di nomi per il dominio e riportarli ai precedenti server di nomi. Questi sono i server dei nomi che avevi annotato nella fase 7 di [Come aggiornare il record NS nel registrar, o nella zona padre, per utilizzare i server dei nomi di Route 53](#migrate-dns-change-name-servers-with-provider-procedure). Stabilisci quindi ciò che non ha funzionato. + **Se il traffico non è influenzato**: passa a [Fase 9: modifica il TTL per il record NS riportandolo a un valore superiore](#migrate-dns-change-ttl-back). ## Fase 9: modifica il TTL per il record NS riportandolo a un valore superiore Nella zona ospitata di Amazon Route 53 per il dominio, cambia il valore TTL per il record NS con un valore più tipico, per esempio, 172.800 secondi (due giorni). Questo migliora la latenza per gli utenti, perché non dovranno aspettare, come spesso accade per resolver DNS, per inviare una query per i server dei nomi per il tuo dominio. **Come modificare il valore TTL per il record NS nella zona ospitata di Route 53** 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. Seleziona **Hosted Zones (Zone ospitate)** nel pannello di navigazione. 1. Scegli il nome della zona ospitata. 1. Nell'elenco dei record per la zona ospitata, scegli il record NS. 1. Scegli **Modifica**. 1. Modifica **TTL (secondi)** nel numero di secondi in cui desideri che il resolver DNS memorizzi i nomi dei server dei nomi per il tuo dominio. Consigliamo un valore di 172800 secondi. 1. Scegli **Save changes** (Salva modifiche). ## Fase 10: Trasferimento della registrazione del dominio ad Amazon Route 53 Ora che hai trasferito il servizio DNS per un dominio ad Amazon Route 53, puoi facoltativamente trasferire la registrazione per il dominio a Route 53. Per ulteriori informazioni, consulta [Trasferimento della registrazione per un dominio ad Amazon Route 53](domain-transfer-to-route-53.md). ## Fase 11: Riabilitazione della firma DNSSEC (se necessario) Ora che hai trasferito il servizio DNS per un dominio ad Amazon Route 53, puoi riabilitare la firma DNSSEC. L'abilitazione della firma DNSSEC prevede due fasi: + Passaggio 1: abilita la firma DNSSEC per Route 53 e richiedi che Route 53 crei una chiave di firma delle chiavi (KSK) basata su una chiave gestita dal cliente (). AWS Key Management Service AWS KMS + Fase 2: Creazione di una catena di attendibilità per la zona ospitata aggiungendo un record Delegation Signer (DS) alla zona padre, in modo che le risposte DNS possano essere autenticate con firme crittografiche attendibili. Per istruzioni, consulta [Abilitazione della firma DNSSEC e creazione di una catena di attendibilità](dns-configuring-dnssec-enable-signing.md). # Rendere Route 53 il servizio DNS per un dominio non attivo Se desideri eseguire la migrazione del servizio DNS a Amazon Route 53 per un dominio che non riceve ancora traffico (o che ne riceve pochissimo), esegui le procedure descritte in questa sezione. **Topics** + [Fase 1: ottieni la tua attuale configurazione DNS dal fornitore di servizi DNS attuale (domini inattivi)](#migrate-dns-get-zone-file-domain-inactive) + [Fase 2: crea una zona ospitata (domini inattivi)](#migrate-dns-create-hosted-zone-domain-inactive) + [Fase 3: crea i record (domini inattivi)](#migrate-dns-create-records-domain-inactive) + [Fase 4: Aggiornamento della registrazione del dominio per utilizzare server di nomi di Amazon Route 53 (domini inattivi)](#migrate-dns-update-domain-inactive) ## Fase 1: ottieni la tua attuale configurazione DNS dal fornitore di servizi DNS attuale (domini inattivi) Quando esegui la migrazione del servizio DNS da un altro provider a Route 53, riproduci la configurazione DNS corrente in Route 53. In Route 53, è necessario creare una zona ospitata con lo stesso nome di dominio e creare i record nella zona ospitata. Ogni record indica il modo in cui desideri instradare il traffico per un determinato nome di dominio o di sottodominio. Ad esempio, quando qualcuno inserisce il tuo nome di dominio in un browser Web, desideri che il traffico venga indirizzato a un server Web nel tuo data center, a un'istanza Amazon EC2, a CloudFront una distribuzione o a qualche altra posizione? Il processo che usi dipende dalla complessità della tua attuale configurazione DNS: + **Se la tua attuale configurazione DNS è semplice**: se stai instradando il traffico Internet per pochi sottodomini a un piccolo numero di risorse, come server Web o bucket Amazon S3, puoi creare manualmente alcuni record nella console Route 53. + **Se la configurazione DNS corrente è più complessa e desideri solo riprodurre la configurazione corrente**: puoi semplificare la migrazione se puoi ottenere un file di zona dal provider di servizi DNS corrente e importare il file di zona in Route 53. (Non tutti i fornitori di servizi DNS offrono i file di zona.) Quando importi un file di zona, Route 53 riproduce automaticamente la configurazione esistente creando i record corrispondenti nella tua zona ospitata. Prova a chiedere al servizio clienti del tuo attuale fornitore di servizi DNS come ottenere un *file di zona* o un *elenco di record*. Per informazioni sul formato richiesto per il file di zona, consulta [Creazione di record mediante importazione di un file di zona](resource-record-sets-creating-import.md). + **Se la tua attuale configurazione DNS è più complessa e sei interessato alle caratteristiche di routing di Route 53**: esamina la seguente documentazione per vedere se desideri utilizzare le funzionalità di Route 53 che non sono disponibili da altri fornitori di servizi DNS. In questo caso, puoi creare record manualmente oppure importare un file di zona e quindi creare o aggiornare i record più tardi: + [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md)spiega i vantaggi dei record di alias Route 53, che indirizzano il traffico verso alcune AWS risorse, come CloudFront distribuzioni e bucket Amazon S3, gratuitamente. + [Scegliere una policy di routing](routing-policy.md) spiega le opzioni di routing di Route 53, ad esempio routing in base alla posizione degli utenti, routing in base alla latenza tra gli utenti e le risorse, routing in base all'integrità delle risorse e routing alle risorse in base ai pesi specificati. **Nota** Puoi anche importare un file di zona e successivamente modificare la configurazione per usufruire dei record alias e di policy di routing complesse. Se non sei in grado di ottenere un file di zona o se desideri creare manualmente record in Route 53, i record che molto probabilmente dovrai migrare includono i seguenti: + **Record A (Indirizzo)**: associa un nome di dominio o un nome di sottodominio all' IPv4 indirizzo (ad esempio, 192.0.2.3) della risorsa corrispondente + **Record AAAA (Indirizzo)**: associano un nome di dominio o un nome di sottodominio all' IPv6 indirizzo (ad esempio, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) della risorsa corrispondente + **Record di server di posta (MX)**: instradano il traffico ai server di posta + **Record CNAME**: reinstradano il traffico per un nome di dominio (esempio.net) a un altro nome di dominio (esempio.com) + **Record per altri tipi di record DNS supportati**: per un elenco dei tipi di record supportati, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). ## Fase 2: crea una zona ospitata (domini inattivi) Per indicare ad Amazon Route 53 come desideri instradare il traffico per il tuo dominio, crea una zona ospitata che ha lo stesso nome del tuo dominio, quindi crea i record nella zona ospitata. **Importante** Puoi creare una zona ospitata solo per un dominio che si dispone dell'autorizzazione per amministrare. Normalmente, questo significa che sei proprietario del dominio, ma potresti anche sviluppare un'applicazione per il registrant del dominio. Quando si crea una zona ospitata, Route 53 crea automaticamente un record di server di nomi (NS) e un record di origine di autorità (SOA) per la zona. Il record NS identifica il nome dei quattro server dei nomi che Route 53 ha associato alla tua zona ospitata. Per rendere Route 53 il servizio DNS per il tuo dominio, devi aggiornare la registrazione per il dominio in modo da utilizzare questi quattro server dei nomi. **Importante** Non creare ulteriori record di server dei nomi (NS) o origine di autorità (SOA) e non eliminare i record SOA e NS esistenti. **Come creare una zona ospitata** 1. Accedi Console di gestione AWS e [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)apri la console Route 53 all'indirizzo. 1. I nuovi utenti di Route 53 possono consultare **Nozioni di base**. Se stai già utilizzando Route 53, scegli **Zone ospitate** nel pannello di navigazione. 1. Scegli **Crea zona ospitata**. 1. Nel riquadro **Crea zona ospitata**, inserisci un nome di dominio e, facoltativamente, un commento. Per ulteriori informazioni su un'impostazione, posiziona il puntatore del mouse sulla rispettiva etichetta per visualizzare una descrizione. Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). 1. Per **Tipo di record**, accetta il valore di default di **Zona ospitata pubblica**. 1. Scegli **Crea zona ospitata**. ## Fase 3: crea i record (domini inattivi) Una volta creata una zona ospitata, è necessario creare record nella stessa che definiscono il punto in cui si desidera instradare il traffico per un dominio (esempio.com) o sottodominio (www.esempio.com). Ad esempio, se desideri instradare il traffico per esempio.com e www.esempio.com a un server Web su un'istanza Amazon EC2, devi creare due record, uno denominato esempio.com e l'altro denominato www.esempio.com. In ogni record, è necessario specificare l'indirizzo IP per l'istanza EC2. Puoi creare record in diversi modi: **Importa un file di zona** Questo è il metodo più semplice se hai ottenuto un file di zona dal servizio DNS corrente in [Fase 1: ottieni la tua attuale configurazione DNS dal fornitore di servizi DNS attuale (domini inattivi)](#migrate-dns-get-zone-file-domain-inactive). Amazon Route 53 non è in grado di prevedere quando creare record alias o utilizzare tipi di routing speciali, ad esempio ponderati o di failover. Di conseguenza, se importi un file di zona, Route 53 crea record DNS standard mediante la policy di routing semplice. Per ulteriori informazioni, consulta [Creazione di record mediante importazione di un file di zona](resource-record-sets-creating-import.md). **Crea record individualmente nella console** Se non hai ottenuto un file di zona e desideri creare solo pochi record con una policy di routing semplice per iniziare, puoi creare i record nella console Route 53. Puoi creare sia record alias che non alias. Per ulteriori informazioni, consulta i seguenti argomenti: + [Scegliere una policy di routing](routing-policy.md) + [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md) + [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md) **Crea record a livello programmatico** È possibile creare record utilizzando uno dei AWS SDKs AWS CLI, o AWS Tools for Windows PowerShell. Per ulteriori informazioni, consulta la [documentazione di AWS](https://docs.aws.amazon.com/). Se utilizzi un linguaggio di programmazione che AWS non fornisce un SDK per, puoi anche utilizzare l'API Route 53. Per ulteriori informazioni, consulta il [riferimento API di Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/). ## Fase 4: Aggiornamento della registrazione del dominio per utilizzare server di nomi di Amazon Route 53 (domini inattivi) Una volta completata la creazione di record per il dominio, è possibile modificare il servizio DNS per il dominio a Amazon Route 53. Esegui la seguente procedura per aggiornare le impostazioni con il registrar del dominio. **Per aggiornare i server dei nomi per il dominio** 1. Nella console Route 53, recupera i server dei nomi per la tua zona ospitata Route 53 1. 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**. 1. Nella pagina **Zone ospitate**, scegli il pulsante di opzione (non il nome) per la zona ospitata, quindi seleziona **Visualizza dettagli**. 1. Nella pagina dei dettagli della zona ospitata, scegli **Dettagli della zona ospitata**. 1. Prendi nota dei quattro server indicati per **Server dei nomi**. 1. Utilizza il metodo fornito dal registrar del dominio per modificare i server dei nomi affinché il dominio utilizzi i quattro server dei nomi Route 53 ottenuti nella fase 2 di questa procedura. Se il dominio è registrato con Route 53, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md). # Configurazione del routing DNS per un nuovo dominio **Un nuovo dominio acquistato da Route 53** Quando record un dominio con Route 53, Route 53 diventa automaticamente il servizio DNS per il dominio. Route 53 crea una zona ospitata con lo stesso nome del nome di dominio, assegna quattro server alla zona ospitata e aggiorna il dominio in modo da utilizzare tali server dei nomi. **Un nuovo dominio acquistato da un altro registrar** Quando acquisti un dominio da un altro registrar, ad esempio, poiché il dominio di primo livello (TLD) non è offerto da Route 53, hai due opzioni: + **Usa Route 53 solo per l'hosting DNS:** mantieni il tuo registrar attuale ma delega la gestione del DNS a Route 53. Segui la procedura riportata di seguito per creare una zona ospitata e aggiornare i name server del registrar. + **Trasferisci la registrazione del dominio su Route 53: imposta** Route 53 come registrar e servizio DNS. Vedi [Lista di controllo prima del trasferimento per i trasferimenti di dominio](domain-transfer-checklist.md) per i prerequisiti e il processo [Trasferimento della registrazione per un dominio ad Amazon Route 53](domain-transfer-to-route-53.md) di trasferimento. Per ulteriori informazioni sul TLDs supporto offerto da Route 53, vedere[Domini che è possibile registrare con Amazon Route 53](registrar-tld-list.md). Segui queste istruzioni per creare una zona ospitata pubblica e poi usa i name server creati con il registrar: **Per creare una zona ospitata per un dominio diverso da Route 53** 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 quindi **Crea zona ospitata**. 1. Per il **nome**, inserisci il nome del dominio per cui desideri creare una zona ospitata, ad esempio una descrizione opzionale`example.com`, scegli **Zona ospitata pubblica** e quindi **Crea zona ospitata**. 1. Dopo aver creato la zona ospitata, annota i quattro record del name server (NS) che sono stati creati. Ciascuno inizierà con «ns-». Nel registrar del dominio, inserisci i name server indicati in alto per delegare la gestione del dominio alla tua zona ospitata su Route 53. **Instrada il traffico DNS** Per specificare come si desidera che Route 53 instradi il traffico Internet per il dominio, crea i record nella zona ospitata. Ad esempio, se desideri indirizzare le richieste per example.com a un server Web in esecuzione su un' EC2 istanza Amazon, crei un record nella zona ospitata da example.com e specifichi l'indirizzo IP elastico per l'istanza. EC2 Per ulteriori informazioni, consulta i seguenti argomenti: + Per informazioni su come creare record nella propria zona ospitata, consultare [Utilizzo dei record](rrsets-working-with.md). + Per informazioni su come indirizzare il traffico verso risorse selezionate AWS , consulta. [Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md) + Per ulteriori informazioni sul funzionamento di questo DNS, consultare [In che modo il traffico Internet viene instradato al tuo sito o applicazione Web](welcome-dns-service.md). + Per verificare la reposizione del DNS, consulta. [Verifica delle risposte DNS da Route 53](dns-test.md) # Routing del traffico alle risorse Quando gli utenti richiedono il tuo sito Web o la tua applicazione Web, ad esempio inserendo il nome del tuo dominio in un browser Web, Amazon Route 53 aiuta a instradare gli utenti alle tue risorse, come un bucket Amazon S3 o un server Web nel tuo data center. Per configurare Route 53 in modo che instradi il traffico verso le tue risorse, completa le seguenti operazioni: 1. Crea una zona ospitata. Puoi creare una zona ospitata pubblica o privata: **Zona ospitata pubblica** Crea una zona ospitata pubblica se desideri instradare il traffico Internet verso le tue risorse, ad esempio per consentire ai clienti di visualizzare il sito Web dell'azienda che stai ospitando su istanze EC2. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate pubbliche](AboutHZWorkingWith.md). **Zona ospitata privata** Crea una zona ospitata privata se desideri instradare il traffico all'interno di un Amazon VPC. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate private](hosted-zones-private.md). 1. Crea record nella zona ospitata. I record definiscono dove desideri instradare il traffico per ciascun nome di dominio o nome di sottodominio. Ad esempio, per instradare il traffico per www.esempio.com a un server Web nel tuo data center, in genere crei un record www.esempio.com nella zona ospitata esempio.com. Per ulteriori informazioni, consulta i seguenti argomenti: + [Utilizzo dei record](rrsets-working-with.md) + [Routing del traffico per sottodomini](dns-routing-traffic-for-subdomains.md) + [Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md) # Routing del traffico per sottodomini Quando desideri instradare il traffico verso le risorse per un sottodominio, ad esempio acme.esempio.com o zenith.esempio.com, hai due opzioni: **Creazione di record nella zona ospitata per il dominio** Di solito, per instradare il traffico per un sottodominio, crei un record nella zona ospitata con lo stesso nome del dominio. Ad esempio, per instradare il traffico Internet per acme.esempio.com a un server Web nel data center, crei un record di nome acme.esempio.com nella zona ospitata esempio.com. Per ulteriori informazioni, vedere l'argomento [Utilizzo dei record](rrsets-working-with.md) e i relativi sottoargomenti. **Creazione di una zona ospitata per il sottodominio e creazione di record nella nuova zona ospitata** Puoi anche creare una zona ospitata per il sottodominio. L'utilizzo di una zona ospitata separata per instradare il traffico Internet per un sottodominio è anche noto come "delega di responsabilità per un sottodominio a una zona ospitata", "delega di un sottodominio ad altri server dei nomi" o combinazioni simili di termini. Ecco una panoramica di come funziona: 1. Crea una zona ospitata con lo stesso nome del sottodominio di cui desideri instradare il traffico, ad esempio acme.esempio.com. 1. Quindi puoi creare record nella nuova zona ospitata che definiscono il modo in cui desideri instradare il traffico per il sottodominio (acme.esempio.com) e i relativi sottodomini, ad esempio backend.acme.esempio.com. 1. Ottieni i server dei nomi che sono stati assegnati da Route 53 alla nuova zona ospitata al momento della creazione. 1. Si crea un nuovo record NS nella zona ospitata per il dominio (example.com). Il nome del record NS deve essere il nome del sottodominio (acme.example.com) e specificate i quattro name server che avete ottenuto nel passaggio 3 come valori del record. Quando utilizzi una zona ospitata separata per instradare il traffico per un sottodominio, puoi utilizzare le autorizzazioni IAM per limitare l'accesso alla zona ospitata per il sottodominio. Se disponi di sottodomini multipli gestiti da diversi gruppi, la creazione di una zona ospitata per ciascun sottodominio può notevolmente ridurre il numero di persone che devono avere l'accesso ai record nella zona ospitata per quel dominio. Per implementare questo processo di delega, sono necessarie le seguenti autorizzazioni IAM. Per ulteriori informazioni sulle politiche IAM di Route 53, consulta[Identity and Access Management in Amazon Route 53](security-iam.md): **Account principale (possiede example.com)** L'utente o il ruolo necessita delle autorizzazioni per modificare i record nella zona ospitata del dominio principale: **Account per bambini (crea acme.example.com)** L'utente o il ruolo necessita delle autorizzazioni per creare e gestire la zona ospitata dal sottodominio: L'utilizzo di una zona ospitata separata per un sottodominio ti consente inoltre di usare servizi DNS diversi per il dominio e il sottodominio. Per ulteriori informazioni, consulta [Utilizzo di Amazon Route 53 come servizio DNS per i sottodomini senza migrare il dominio padre](creating-migrating.md). C'è un piccolo impatto sulle prestazioni su questa configurazione per la prima query DNS da ciascun resolver DNS. Il resolver deve ottenere le informazioni dalla zona ospitata per il dominio radice e quindi ottenere le informazioni dalla zona ospitata per il sottodominio. Dopo la prima query DNS per un sottodominio, il resolver memorizza le informazioni nella cache e non deve ottenerle di nuovo finché il TTL non scade e un altro client richiede il sottodominio da quel resolver. Per ulteriori informazioni, consulta [TTL (secondi)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) nella sezione [Di seguito sono descritti i valori che devi specificare durante la creazione o la modifica di record di Amazon Route 53.](resource-record-sets-values.md). **Topics** + [Creazione di un'altra zona ospitata per instradare il traffico per un sottodominio](#dns-routing-traffic-for-subdomains-new-hosted-zone) + [Routing del traffico per ulteriori livelli di sottodomini](#dns-routing-traffic-for-sub-subdomains) ## Creazione di un'altra zona ospitata per instradare il traffico per un sottodominio Un modo per instradare il traffico per un sottodominio consiste nel creare una zona ospitata per il sottodominio e quindi creare record per il sottodominio nella nuova zona ospitata. (L'opzione più comune è quella di creare record per il sottodominio nella zona ospitata per il dominio.) **Nota** Questa procedura mostra come delegare un sottodominio a Route 53. È inoltre possibile delegare un sottodominio ad altri servizi DNS creando record NS che puntano invece ai name server di tali servizi. Ecco una panoramica del processo: 1. Creare una zona ospitata per il sottodominio. Per ulteriori informazioni, consulta [Creazione di una nuova zona ospitata per un sottodominio](#dns-routing-traffic-for-subdomains-creating-hosted-zone). 1. Aggiungere record alla zona ospitata per il sottodominio. Se la zona ospitata per il dominio contiene record appartenenti alla zona ospitata per il sottodominio, duplicare quei record nella zona ospitata per il sottodominio. Per ulteriori informazioni, consulta [Creazione di record nella zona ospitata per il sottodominio](#dns-routing-traffic-for-subdomains-creating-records) 1. Creare un record NS per il sottodominio nella zona ospitata per il dominio, che delega la responsabilità per il sottodominio al server dei nomi della nuova zona ospitata. Se la zona ospitata per il dominio contiene record appartenenti alla zona ospitata per il sottodominio, eliminare i record dalla zona ospitata per il dominio. (Nel passaggio 2 sono state create copie nella zona ospitata per il sottodominio.) Per ulteriori informazioni, consulta [Aggiornamento della zona ospitata per il dominio](#dns-routing-traffic-for-subdomains-delegating-responsibility). ### Creazione di una nuova zona ospitata per un sottodominio Per creare una zona ospitata per un sottodominio utilizzando la console Route 53, esegui la procedura seguente. **Per creare una zona ospitata per un sottodominio (console)** 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. I nuovi utenti di Route 53 possono consultare **Nozioni di base**. Se stai già utilizzando Route 53, scegli **Zone ospitate** nel pannello di navigazione. 1. Scegli **Crea zona ospitata**. 1. Nel riquadro di destra, inserire il nome del sottodominio, ad esempio acme.esempio.com. Facoltativamente, è anche possibile inserire un commento. Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). 1. Per **Tipo**, accetta il valore di default di **Zona ospitata pubblica**. 1. Nella parte inferiore al riquadro di destra, scegli **Crea zona ospitata**. ### Creazione di record nella zona ospitata per il sottodominio Per definire il modo in cui desideri che Route 53 instradi il traffico per il sottodominio (acme.esempio.com) e per i suoi sottodomini (backend.acme.esempio.com), crea record nella zona ospitata per il sottodominio. Tieni presente quanto segue in merito alla creazione di record nella zona ospitata per il sottodominio: + Non creare ulteriori record di server dei nomi (NS) o di origine di autorità (SOA) nella zona ospitata per il sottodominio e non eliminare i record SOA e NS esistenti. + Crea tutti i record per il sottodominio nella zona ospitata per il sottodominio. Ad esempio, se disponi di zone ospitate per il dominio esempio.com e apex.esempio.com, crea tutti i record per il sottodominio acme.esempio.com nella zona ospitata di acme.esempio.com. Questo include record come backend.acme.esempio.com e beta.backend.acme.esempio.com. + Se la zona ospitata per il dominio (esempio.com) contiene già record che appartengono alla zona ospitata per il sottodominio (acme.esempio.com), duplica quei record nella zona ospitata per il sottodominio. Nell'ultima fase del processo, elimina successivamente i record duplicati della zona ospitata per il dominio. **Importante** Se disponi di alcuni record per il sottodominio sia nella zona ospitata per il dominio sia nella zona ospitata per sottodominio, il comportamento di DNS sarà incoerente. Il comportamento dipenderà dai server dei nomi memorizzati nella cache da un resolver DNS, dai server dei nomi per la zona ospitata del dominio (esempio.com) o dai server dei nomi per la zona ospitata del sottodominio (acme.esempio.com). In alcuni casi, Route 53 restituirà NXDOMAIN (dominio inesistente) se il record esiste, ma non nella zona ospitata alla quale il resolver DNS sta inviando la query. Per ulteriori informazioni, consulta [Utilizzo dei record](rrsets-working-with.md). ### Aggiornamento della zona ospitata per il dominio Quando crei una zona ospitata, Route 53 assegna automaticamente quattro server dei nomi alla zona. Il record NS per una zona ospitata identifica i server dei nomi che rispondono alle query DNS per il dominio o il sottodominio. Per iniziare a utilizzare i record nella zona ospitata per il sottodominio per instradare il traffico Internet, crea un nuovo record NS nella zona ospitata per il dominio (esempio.com) e assegnale il nome del sottodominio (acme.esempio.com). Per il valore del record NS, specifica i nomi dei server dei nomi della zona ospitata per il sottodominio. Ecco cosa succede quando Route 53 riceve una query DNS da un resolver DNS per il sottodominio acme.esempio.com o uno dei suoi sottodomini: 1. Route 53 esegue una ricerca nella zona ospitata per il dominio (esempio.com) e trova il record NS per il sottodominio (acme.esempio.com). 1. Route 53 ottiene i server dei nomi dal record NS di acme.esempio.com nella zona ospitata per il dominio, esempio.com e restituisce quei server dei nomi al resolver DNS. 1. Il resolver invia di nuovo la query per acme.esempio.com ai server dei nomi per la zona ospitata acme.esempio.com. 1. Route 53 risponde alla query utilizzando un record nella zona ospitata acme.esempio.com. Per configurare Route 53 affinché instradi il traffico per il sottodominio utilizzando la zona ospitata per il sottodominio e per eliminare eventuali record duplicati della zona ospitata per il dominio, completa la procedura seguente: **Come configurare Route 53 in modo che utilizzi la zona ospitata per il sottodominio (console)** 1. Nella console Route 53, ottenere i server dei nomi per la zona ospitata per il sottodominio: 1. Nel pannello di navigazione, scegli **Zone ospitate**. 1. Nella pagina **Zone ospitate**, scegli il nome per la zona ospitata per il sottodominio. 1. Nel riquadro a destra, copia i nomi dei quattro server elencati per **Server dei nomi** nella sezione **Dettagli delle zone ospitate**. 1. Scegliere il nome della zona ospitata per il dominio (esempio.com), non per il sottodominio. 1. Scegli **Crea record**. 1. Scegli **Routing semplice**, quindi scegli **Successivo**. 1. Scegli **Define simple record (Definisci record semplice)**. 1. Specifica i seguenti valori: **Name** Inserisci il nome del sottodominio (ad esempio,`acme.example.com`). Deve corrispondere esattamente al nome della zona ospitata dal sottodominio che hai creato. **Valore/instradamento traffico a** Scegli **Indirizzo IP o un altro valore a seconda del tipo di record** e incolla i nomi dei server dei nomi copiati nella fase 1. **Tipo di record** Sceglie **NS - Server di nomi per una zona ospitata**. **TTL (secondi)** Modificare in un valore più comune per un record NS, ad esempio 172.800 secondi. 1. Scegli **Definisci record semplice** e scegli **Crea record**. 1. Se la zona ospitata per il dominio contiene record che sono stati ricreati nella zona ospitata per il sottodominio, eliminare quei record dalla zona ospitata per il dominio. Per ulteriori informazioni, consulta [Eliminazione di record](resource-record-sets-deleting.md). Al termine, tutti i record per il sottodominio devono essere nella zona ospitata per il sottodominio. ## Routing del traffico per ulteriori livelli di sottodomini Puoi instradare il traffico a un sottodominio di un sottodominio, come backend.acme.esempio.com, nello stesso modo in cui instradi il traffico a un sottodominio, ad esempio acme.esempio.com. O crei record nella zona ospitata per il dominio, o crei una zona ospitata per il sottodominio di livello inferiore, per poi creare record in quella nuova zona ospitata. Se scegli di creare una zona ospitata separata per il sottodominio di livello inferiore, crea il record NS per il sottodominio di livello inferiore nella zona ospitata per il sottodominio che si trova più vicino di un livello al nome di dominio. Questo contribuisce a garantire il corretto instradamento del traffico alle tue risorse. Ad esempio, supponi di voler instradare il traffico per i seguenti sottodomini: + subdomain1.esempio.com + subdomain2.subdomain1.esempio.com Per utilizzare un'altra zona ospitata per instradare il traffico per subdomain2.subdomain1.esempio.com, procedi nel seguente modo: 1. Crea una zona ospitata con il nome named subdomain2.subdomain1.esempio.com. 1. Crea record nella zona ospitata subdomain2.subdomain1.esempio.com. Per ulteriori informazioni, consulta [Creazione di record nella zona ospitata per il sottodominio](#dns-routing-traffic-for-subdomains-creating-records). 1. Copia i nomi dei server dei nomi per la zona ospitata subdomain2.subdomain1.esempio.com. 1. Nella zona ospitata subdomain1.esempio.com, crea un record NS di nome subdomain2.subdomain1.esempio.com e incolla i nomi dei server dei nomi per la zona ospitata subdomain2.subdomain1.esempio.com. Inoltre, elimina qualsiasi record duplicato di subdomain1.esempio.com. Per ulteriori informazioni, consulta [Aggiornamento della zona ospitata per il dominio](#dns-routing-traffic-for-subdomains-delegating-responsibility). Dopo aver creato il record NS, Route 53 inizia a usare la zona ospitata subdomain2.subdomain1.esempio.com per instradare il traffico per il sottodominio subdomain2.subdomain1.esempio.com. # Utilizzo delle zone ospitate Una zona ospitata è un container di record e i record contengono informazioni relative alle modalità con cui desideri instradare il traffico per un dominio specifico (come esempio.com) e i suoi sottodomini (come acme.esempio.com, zenith.esempio.com). Una zona ospitata e il dominio corrispondente hanno lo stesso nome. Esistono due tipi di zone ospitate: + *Zone ospitate pubbliche* contengono record che specificano come instradare il traffico su Internet. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate pubbliche](AboutHZWorkingWith.md). + *Zone ospitate private* contengono record che specificano come instradare il traffico in un VPC Amazon. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate private](hosted-zones-private.md). # Utilizzo delle zone ospitate pubbliche Una zona ospitata pubblica è un container che detiene informazioni relative alle modalità con cui desideri instradare il traffico su Internet per un dominio specifico (come esempio.com) e i suoi sottodomini (come acme.esempio.com, zenith.esempio.com). Puoi ottenere una zona ospitata pubblica in uno dei seguenti modi: + Quando record il dominio con Route 53 creiamo automaticamente una zona ospitata per tuo conto. + Quando trasferisci il servizio DNS per un dominio esistente su Route 53, inizi creando una zona ospitata per il dominio. Per ulteriori informazioni, consulta [Rendere Amazon Route 53 il servizio DNS per un dominio esistenteRendere il Route 53 il servizio DNS per un dominio esistente](MigratingDNS.md). In entrambi i casi, crei i record nella zona ospitata per specificare come desideri instradare il traffico per i domini e i sottodomini. Ad esempio, potresti creare un record per indirizzare il traffico di www.example.com verso una CloudFront distribuzione o un server Web nel tuo data center. Per ulteriori informazioni sul record, consulta [Utilizzo dei record](rrsets-working-with.md). In questo argomento viene descritto come utilizzare la console Amazon Route 53 per creare, elencare ed eliminare zone ospitate pubbliche. **Nota** Puoi anche utilizzare una zona ospitata *privata* Route 53 per indirizzare il traffico all'interno di una o più VPCs zone create con il servizio Amazon VPC. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate private](hosted-zones-private.md). **Topics** + [Considerazioni sull'utilizzo delle zone ospitate pubbliche](hosted-zone-public-considerations.md) + [Creazione di una zona ospitata pubblica](CreatingHostedZone.md) + [Ottenere i server di nomi per una zona ospitata pubblica](GetInfoAboutHostedZone.md) + [Elencare le zone ospitate pubbliche](ListInfoOnHostedZone.md) + [Visualizzazione dei parametri delle query DNS per una zone ospitata pubblica](hosted-zone-public-viewing-query-metrics.md) + [Eliminazione di una zona ospitata pubblica](DeleteHostedZone.md) + [Verifica delle risposte DNS da Route 53](dns-test.md) + [Configurazione dei server di nomi white label](white-label-name-servers.md) + [Record NS e SOA creati da Amazon Route 53 per una zona ospitata pubblica](SOA-NSrecords.md) + [Abilitare il ripristino accelerato per la gestione dei record DNS pubblici](accelerated-recovery.md) # Considerazioni sull'utilizzo delle zone ospitate pubbliche Tieni in considerazione le seguenti informazioni quando lavori con zone ospitate pubbliche: **Record NS e SOA** Quando crei una zona ospitata, Amazon Route 53 crea automaticamente un record di server di nomi (NS) e un record di origine di autorità (SOA) per la zona. Il record NS identifica i quattro server di nomi che fornisci al tuo registrar o al servizio DNS in modo che le query DNS vengono instradate ai server dei nomi Route 53. Per ulteriori informazioni sui record NS e SOA, consulta [Record NS e SOA creati da Amazon Route 53 per una zona ospitata pubblica](SOA-NSrecords.md). **Più zone ospitate con lo stesso nome** Puoi creare più di una zona ospitata con lo stesso nome e aggiungere record diversi a ciascuna zona. Route 53 assegna quattro server dei nomi a ogni zona ospitata e i server dei nomi sono diversi per ciascuna di esse. Quando aggiorni i record dei server dei nomi del tuo registrar, fai attenzione a utilizzare i server di nomi per la corretta zona ospitata, ovvero quella che contiene i record che desideri siano utilizzati da Route 53 per rispondere alle query per il tuo dominio. Route 53 non restituisce mai valori per i record in altre zone ospitate che hanno lo stesso nome. **Set di deleghe riutilizzabili** Per impostazione predefinita, Route 53 assegna un insieme univoco di quattro server dei nomi (noti collettivamente come set di delega) per ogni zona ospitata creata. Se desideri creare un numero elevato di zona ospitata, puoi creare un set di delega riutilizzabile in modo programmatico. I set di delega riutilizzabili non sono disponibili nella console Route 53. Quindi, potrai creare zone ospitate a livello di codice e assegnare lo stesso set di delega riutilizzabile (ovvero gli stessi quattro server di nomi) a ciascuna zona ospitata. I set di delega riutilizzabili semplificano la migrazione del servizio DNS a Route 53 perché è possibile impostare il registrar del nome di dominio in modo che siano utilizzati gli stessi quattro server dei nomi per tutti i domini per cui desideri che Route 53 sia il servizio DNS. Per ulteriori informazioni, [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)consulta *Amazon Route 53 API Reference*. # Creazione di una zona ospitata pubblica Una zona ospitata pubblica è un container che detiene informazioni relative alle modalità con cui desideri instradare il traffico su Internet per un dominio specifico (come esempio.com) e i suoi sottodomini (come acme.esempio.com, zenith.esempio.com). Dopo aver creato una zona ospitata, puoi creare i record che specificano come desideri instradare il traffico per i domini e i sottodomini. **Restrizioni** Tieni presente le seguenti restrizioni per la creazione di zone ospitate con Route 53. Puoi creare una zona ospitata solo per un dominio che si dispone dell'autorizzazione per amministrare. Normalmente, questo significa che sei proprietario del dominio, ma potresti anche sviluppare un'applicazione per il registrant del dominio. È possibile creare zone ospitate solo per domini e sottodomini. Route 53 non supporta l'hosting di domini di primo livello (TLD) come. `.com` **Come creare una zona ospitata pubblica mediante la console Route 53** 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. Se non hai esperienza con Route 53, scegli **Nozioni di base** in **Gestione DNS**. Se stai già utilizzando Route 53, scegli **Zone ospitate** nel pannello di navigazione. 1. Scegli **Crea zona ospitata**. 1. Nel riquadro **Create zona ospitata (Crea zona ospitata)**, inserisci il nome del dominio su cui desideri instradare il traffico. Facoltativamente, è anche possibile inserire un commento. Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). 1. Per **Tipo**, accetta il valore di default di **Public Hosted Zone (Zona ospitata pubblica)**. 1. Scegli **Create** (Crea). 1. Crea record che specificano il modo in cui desideri instradare il traffico per il dominio e i sottodomini. Per ulteriori informazioni, consulta [Utilizzo dei record](rrsets-working-with.md). 1. Per utilizzare i record nella nuova zona ospitata per instradare il traffico per il tuo dominio, consulta l'argomento relativo: + Se stai utilizzando Route 53 come servizio DNS per un dominio registrato con un altro registrar di dominio, consulta [Rendere Amazon Route 53 il servizio DNS per un dominio esistenteRendere il Route 53 il servizio DNS per un dominio esistente](MigratingDNS.md). + Se il dominio è registrato con Route 53, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md). # Ottenere i server di nomi per una zona ospitata pubblica È possibile ottenere i server dei nomi per una zona ospitata pubblica se si desidera modificare il servizio DNS per la registrazione del dominio. Per informazioni su come modificare il servizio DNS, consulta [Rendere Amazon Route 53 il servizio DNS per un dominio esistenteRendere il Route 53 il servizio DNS per un dominio esistente](MigratingDNS.md). **Nota** Alcuni registrar consentono di specificare i server di nomi solo utilizzando gli indirizzi IP e non consentono di specificare nomi di dominio completi. Se il registrar richiede l'utilizzo di indirizzi IP, puoi ottenere gli indirizzi IP per i tuoi server di nomi utilizzando l'utility dig (per Mac, Unix o Linux) o l'utility nslookup (per Windows). Solo raramente modifichiamo gli indirizzi IP dei server di nomi; se è necessario modificare gli indirizzi IP, ti invieremo una notifica in anticipo. **Come ottenere i server dei nomi per una zona ospitata tramite la console Route 53** 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**. 1. Nella pagina **Zone ospitate**, scegli il pulsante di opzione (non il nome) per la zona ospitata, quindi seleziona **Visualizza dettagli**. 1. Nella pagina dei dettagli della zona ospitata, scegli **Dettagli della zona ospitata**. 1. Prendi nota dei quattro server indicati per **Server dei nomi**. # Elencare le zone ospitate pubbliche Puoi utilizzare la console Amazon Route 53 per elencare tutte le zone ospitate che hai creato con l' AWS account corrente. Per informazioni su come elencare le zone ospitate utilizzando l'API Route 53, [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)consulta *Amazon Route 53 API Reference*. **Per elencare le zone ospitate pubbliche associate a un AWS account utilizzando la console Route 53** 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**. La pagina mostra un elenco delle zone ospitate associate all' AWS account con cui hai attualmente effettuato l'accesso. 1. Per filtrare le zone ospitate, utilizza la barra di ricerca situata nella parte superiore della tabella. Cerca comportamento varia a seconda che la zona ospitata zone contiene fino a 2.000 record o più di 2.000 record: **Fino a 2.000 zone ospitate** + Per visualizzare i record con valori specifici, fai clic sulla barra di ricerca, scegli una proprietà dall'elenco a discesa e immetti un valore. È inoltre possibile immettere un valore direttamente nella barra di ricerca e premere Invio. Ad esempio, per visualizzare le zone ospitate con un nome che inizia con **abc**, immetti quel valore nella barra di ricerca e premi Invio. + Per visualizzare solo le zone ospitate con lo stesso tipo di zona ospitata, seleziona il tipo dall'elenco a discesa e immetti il tipo. **Più di 2.000 zone ospitate** + È possibile cercare le proprietà in base al nome di dominio esatto, a tutte le proprietà e al tipo. + Ricerca utilizzando il nome di dominio esatto per risultati di ricerca più rapidi. # Visualizzazione dei parametri delle query DNS per una zone ospitata pubblica Puoi visualizzare il numero totale di query DNS a cui Route 53 risponde per una determinata zona ospitata pubblica o una combinazione di zone ospitate pubbliche. Le metriche vengono visualizzate in CloudWatch, il che consente di visualizzare un grafico, scegliere il periodo di tempo che si desidera visualizzare e personalizzare le metriche in molti altri modi. Puoi anche creare allarmi e configurare notifiche, in modo da ricevere una notifica quando il numero di query DNS in un periodo di tempo specificato supera o scende al di sotto di un livello specificato. **Nota** Route 53 invia automaticamente il numero di query DNS a tutte CloudWatch le zone pubbliche ospitate, quindi non è necessario configurare nulla prima di poter visualizzare le metriche delle query. Non sono previsti costi per i parametri delle query DNS. **Quali query DNS vengono conteggiate?** I parametri includono solo le query inoltrate dai resolver DNS a Route 53. Se un resolver DNS ha già memorizzato nella cache la risposta a una query (ad esempio l'indirizzo IP per un load balancer per esempio.com), il resolver continuerà a restituire la risposta memorizzata nella cache senza inoltrare le query a Route 53 finché il TTL per il record corrispondente non scade. In base al numero di query DNS inviate per un nome di dominio (esempio.com) o di sottodominio (www.esempio.com), che gli utenti usano, e in base al TTL per il record, i parametri delle query DNS potrebbero contenere informazioni su una sola query rispetto a diverse migliaia di query che vengono inviate ai resolver DNS. Per ulteriori informazioni sul funzionamento di DNS, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). **Quando iniziano a comparire in CloudWatch i parametri di query per una zona ospitata?** Dopo aver creato una zona ospitata, possono passare diverse ore prima che la zona ospitata possa comparire in CloudWatch. Inoltre, è necessario inviare una query DNS per un record nella zona ospitata affinché ci siano dati da visualizzare. **I parametri sono disponibili solo negli Stati Uniti orientali (Virginia settentrionale)** Per ottenere i parametri nella console, occorre specificare Stati Uniti orientali (Virginia settentrionale) per la regione. Per ottenere le metriche utilizzando la AWS CLI, devi lasciare AWS la Regione non specificata o `us-east-1` specificarla come Regione. Se scegli qualsiasi altra regione, i parametri di Route 53 non saranno disponibili. **CloudWatch metrica e dimensione per le query DNS** Per informazioni sulla CloudWatch metrica e sulla dimensione per le query DNS, consulta. [Monitoraggio delle zone ospitate tramite Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md) Per informazioni sui CloudWatch parametri, consulta [Using Amazon CloudWatch metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) nella *Amazon CloudWatch User* Guide. **Ottenere più dati dettagliati relativi alle query DNS** Per ottenere informazioni più dettagliate su ogni query DNS a cui Route 53 risponde, inclusi i seguenti riportati di seguito, puoi configurare la registrazione delle query: + Dominio o sottodominio richiesto + Data e ora della richiesta + Tipo di record DNS (ad esempio A o AAAA) + Edge location Route 53 che ha risposto alla query DNS + Codice di risposta DNS, ad esempio `NoError` o `ServFail` Per ulteriori informazioni, consulta [Registrazione delle query DNS pubbliche](query-logs.md). **Come ottenere parametri delle query DNS** Poco dopo aver creato una zona ospitata, Amazon Route 53 inizia a inviare metriche e dimensioni una volta al minuto a CloudWatch. Puoi utilizzare le seguenti procedure per visualizzare i parametri sulla CloudWatch console o visualizzarli utilizzando AWS Command Line Interface ()AWS CLI. **Topics** + [Visualizzazione delle metriche delle query DNS per una zona ospitata pubblica nella console CloudWatch](#hosted-zone-public-viewing-query-metrics-console) + [Ottenere le metriche delle query DNS utilizzando il AWS CLI](#hosted-zone-public-viewing-query-metrics-cli) ## Visualizzazione delle metriche delle query DNS per una zona ospitata pubblica nella console CloudWatch Per visualizzare i parametri delle query DNS per le zone ospitate pubbliche nella CloudWatch console, eseguire la procedura seguente. **Per visualizzare i parametri delle query DNS per una zona ospitata pubblica sulla console CloudWatch** 1. Accedi a Console di gestione AWS e apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 1. Nel riquadro di navigazione, seleziona **Parametri**. 1. Nell'elenco delle AWS regioni nell'angolo superiore destro della console, scegli **Stati Uniti orientali (Virginia settentrionale).** Le metriche di Route 53 non sono disponibili se scegli un'altra AWS regione. 1. Nella scheda **All metrics (Tutti i parametri)** scegliere **Route 53**. 1. Scegli **Hosted Zone Metrics (Parametri zona ospitata)**. 1. Seleziona la casella di controllo per una o più zone ospitate con il nome della metrica. **DNSQueries** 1. Nella scheda **Graphed metrics (Parametri definiti)**, modifica i valori applicabili per visualizzare i parametri nel formato desiderato. Per **Statistica**, scegli **Somma** o **SampleCount**; entrambe le statistiche mostrano lo stesso valore. ## Ottenere le metriche delle query DNS utilizzando il AWS CLI Per ottenere le metriche delle query DNS utilizzando il AWS CLI, si utilizza il comando. [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) Tenere presente quanto segue: + Specifica la maggior parte dei valori per il comando in un file JSON separato. Per ulteriori informazioni, consulta [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html). + Il comando restituisce un valore per ogni intervallo specificato per `Period` nel file JSON. `Period` è espresso in secondi, pertanto se specifichi un periodo di tempo di cinque minuti e specifichi `60` per `Period`, otterrai cinque valori. Se specifichi un periodo di tempo di cinque minuti e specifichi `300` per `Period`, otterrai un valore. + Nel file JSON, puoi specificare qualsiasi valore per `Id`. + Lasciate la AWS regione non specificata o specificatela `us-east-1` come regione. Se scegli qualsiasi altra regione, i parametri di Route 53 non saranno disponibili. Per ulteriori informazioni, consulta [Configurazione della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) nella Guida per *AWS Command Line Interface l'*utente. Ecco il AWS CLI comando che usi per ottenere i parametri delle query DNS per il periodo di cinque minuti compreso tra le 4:01 e le 4:07 del 1° maggio 2019. Il parametro `metric-data-queries` fa riferimento al file JSON di esempio che segue il comando. ``` aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z ``` Di seguito è riportato il file JSON di esempio: ``` [ { "Id": "my_dns_queries_id", "MetricStat": { "Metric": { "Namespace": "AWS/Route53", "MetricName": "DNSQueries", "Dimensions": [ { "Name": "HostedZoneId", "Value": "Z1D633PJN98FT9" } ] }, "Period": 60, "Stat": "Sum" }, "ReturnData": true } ] ``` Di seguito è riportato l'output di questo comando. Tenere presente quanto segue: + L'ora di inizio e l'ora di fine nel comando coprono un periodo di tempo di sette minuti, da `2019-05-01T04:01:00Z` a `2019-05-01T04:07:00Z`. + I valori restituiti sono solo sei. Non esiste alcun valore per `2019-05-01T04:05:00Z` perché durante quel minuto non ci sono state query DNS. + Il valore di `Period` specificato nel file JSON è `60` (secondi), pertanto i valori vengono segnalati a intervalli di un minuto. ``` { "MetricDataResults": [ { "Id": "my_dns_queries_id", "StatusCode": "Complete", "Label": "DNSQueries", "Values": [ 101.0, 115.0, 103.0, 127.0, 111.0, 120.0 ], "Timestamps": [ "2019-05-01T04:07:00Z", "2019-05-01T04:06:00Z", "2019-05-01T04:04:00Z", "2019-05-01T04:03:00Z", "2019-05-01T04:02:00Z", "2019-05-01T04:01:00Z" ] } ] } ``` # Eliminazione di una zona ospitata pubblica Questa sezione illustra come eliminare una zona ospitata pubblica utilizzando la console Amazon Route 53. Puoi eliminare una zona ospitata solo se non sono presenti record diversi dai record SOA e NS di default. Se la tua zona ospitata contiene altri record, devi eliminarli prima di eliminare la zona ospitata. In questo modo si impedisce l'eliminazione accidentale di una zona ospitata che contiene ancora record. **Topics** + [Impedire che il traffico venga instradato al dominio](#delete-public-hosted-zone-stop-routing) + [Eliminazione di zone ospitate pubbliche create da un altro servizio](#delete-public-hosted-zone-created-by-another-service) + [Utilizzo della console Route 53 per eliminare una zona ospitata pubblica](#delete-public-hosted-zone-procedure) ## Impedire che il traffico venga instradato al dominio Se desideri mantenere la registrazione del tuo dominio, ma desideri interrompere il routing del traffico Internet sul tuo sito o applicazione Web, ti consigliamo di eliminare i *record* nella zona ospitata invece di eliminarla. **Importante** Se elimini una zona ospitata, non puoi annullarne l'eliminazione. Devi creare una nuova zona ospitata e aggiornare i server di nomi per la registrazione del tuo dominio, operazione che può richiedere fino a 48 ore per rendere effettiva la modifica. Inoltre, se elimini una zona ospitata, qualcuno potrebbe dirottare il dominio e instradare il traffico verso le proprie risorse utilizzando il tuo nome di dominio. Se è stata delegata la responsabilità di un sottodominio a una zona ospitata e si desidera eliminare la zona ospitata figlio, è inoltre necessario aggiornare la zona ospitata padre eliminando il record NS con lo stesso nome della zona ospitata figlio. Ad esempio, se si desidera eliminare la zona ospitata acme.example.com, è necessario eliminare anche il record NS acme.example.com nella zona ospitata example.com. Prima di eliminare la zona ospitata figlio, si consiglia di eliminare il record NS e di attendere la durata del TTL del record NS. Ciò impedisce il dirottamento della zona ospitata figlio per il periodo di tempo in cui i resolver DNS includono ancora nella cache i server dei nomi per la zona ospitata figlio. Se desideri evitare di pagare la tariffa mensile per la zona ospitata, puoi trasferire il servizio DNS per il dominio a un servizio DNS gratuito. Quando trasferisci un servizio DNS, è necessario aggiornare i server di nomi per la registrazione del dominio. Se il dominio è registrato con Route 53, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md) per informazioni su come sostituire i server dei nomi di Route 53 con i server di nomi per il nuovo servizio DNS. Se il dominio è registrato con un altro registrar, utilizza il metodo fornito dal registrar per aggiornare i server di nomi per la registrazione del dominio. Per ulteriori informazioni, esegui una ricerca su Internet immettendo la query "servizio DNS gratuito". ## Eliminazione di zone ospitate pubbliche create da un altro servizio Se una zona ospitata è stata creata da un altro servizio, non sarà possibile eliminarla utilizzando la console Route 53. Al contrario, è necessario utilizzare il processo applicabile all'altro servizio: + **AWS Cloud Map**— Per eliminare una zona ospitata AWS Cloud Map creata quando hai creato uno spazio dei nomi DNS pubblico, elimina lo spazio dei nomi. AWS Cloud Map elimina automaticamente la zona ospitata. Per ulteriori informazioni, consulta [Eliminazione degli spazi dei nomi](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) nella *Guida per gli sviluppatori di AWS Cloud Map *. + **Rilevamento del servizio Amazon Elastic Container Service (Amazon ECS)**: per eliminare una zona ospitata pubblica creata da Amazon ECS quando hai creato un servizio utilizzando l'individuazione dei servizi, eliminare i servizi Amazon ECS che utilizzano lo spazio dei nomi ed eliminare lo spazio dei nomi. Per ulteriori informazioni, consulta [Eliminazione di un servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) nella *Guida per gli sviluppatori di Amazon Elastic Container Service*. ## Utilizzo della console Route 53 per eliminare una zona ospitata pubblica Per utilizzare la console Route 53 per eliminare una zona ospitata pubblica, completa la procedura seguente. **Come eliminare una zona ospitata pubblica tramite la console Route 53** 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 **Hosted zones** (Zone ospitate) e scegli il link evidenziato per la zona ospitata che desideri eliminare. 1. Conferma che la zona ospitata che desideri eliminare contiene solo un record NS e un record SOA. Se contiene registri aggiuntivi, eliminali. Sarà inoltre necessario disabilitare la firma DNSSEC: **Nota** Se tenti di eliminare la zona ospitata senza soddisfare questi requisiti, Route 53 restituirà un errore: Se la firma DNSSEC è abilitata: la zona ospitata specificata contiene chiavi di firma delle chiavi DNSSEC e quindi non può essere eliminata Se esistono altri set di record di risorse (diversi dai record SOA e NS predefiniti): la zona ospitata specificata contiene set di record di risorse non richiesti e quindi non può essere eliminata 1. Nella pagina dei dettagli della zona ospitata, nell'elenco **Records** (Registri), se l'elenco dei record include i record per i quali il valore della colonna **Type** (Tipo) è diverso da NS o SOA, scegli la riga, quindi seleziona **Delete** (Elimina). Per selezionare più record consecutivi, seleziona la prima riga, tieni premuto il tasto **Shift (MAIUSC)** e seleziona l'ultima riga. Per selezionare più record non consecutivi, seleziona la prima riga, tieni premuto il tasto **Ctrl** e seleziona le righe rimanenti. **Nota** Se hai creato record NS per sottodomini nella hosted zone, elimina anche questi record. 1. Torna alla pagina **Hosted zones** (Zone ospitate) e scegli la riga per la zona ospitata che desideri eliminare. 1. Scegli **Elimina**. 1. Digita la chiave di conferma e scegli **Elimina**. 1. Se desideri rendere il dominio non disponibile su Internet, ti consigliamo di trasferire il servizio DNS su un servizio DNS gratuito e quindi eliminare la zona ospitata di Route 53. In questo modo si impedisce che query DNS future vengano instradate in modo non corretto. Se il dominio è registrato con Route 53, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md) per informazioni su come sostituire i server dei nomi di Route 53 con i server di nomi per il nuovo servizio DNS. Se il dominio è registrato con un altro registrar, utilizza il metodo fornito dal registrar per modificare i server di nomi per il dominio. **Nota** Se stai eliminando una zona ospitata per un sottodominio (acme.esempio.com), non è necessario modificare i server di nomi per il dominio (esempio.com). # Verifica delle risposte DNS da Route 53 Se hai creato una zona ospitata di Amazon Route 53 per il tuo dominio, puoi utilizzare lo strumento di controllo DNS nella console per vedere in che modo Route 53 risponderà alle query DNS se configuri il dominio per utilizzare Route 53 come servizio DNS. Per i record di geolocalizzazione, geoprossimità e latenza, puoi anche simulare le query provenienti da un particolare indirizzo IP di un and/or client resolver DNS per scoprire quale risposta restituirebbe Route 53. **Importante** Lo strumento non invia query al Domain Name System, ma risponde solo in base alle impostazioni nei record nella zona ospitata. Lo strumento restituisce le stesse informazioni indipendentemente dal fatto che la zona ospitata sia attualmente utilizzata o meno per instradare il traffico per il dominio. Lo strumento di controllo DNS funziona solo per zone ospitate pubbliche. **Nota** Lo strumento di controllo DNS restituisce informazioni simili a quelle solitamente fornite dalla sezione di risposta del comando `dig`. Pertanto, se esegui una query per i server di nomi di un sottodominio che puntano ai server di nomi padre, questi non verranno restituiti. **Topics** + [Utilizzo dello strumento di controllo per vedere come Amazon Route 53 risponde alle query DNS](#dns-test-how-route-53-responds) + [Utilizzo dello strumento di controllo per la simulazione di query da indirizzi IP specifici (solo record di geolocalizzazione e latenza)](#dns-test-simulate-requests) ## Utilizzo dello strumento di controllo per vedere come Amazon Route 53 risponde alle query DNS Puoi utilizzare lo strumento per vedere le risposte restituite da Amazon Route 53 in risposta a una query DNS per un record. **Come utilizzare lo strumento di controllo per vedere come Route 53 risponde alle query DNS** 1. Accedi e apri la console Route 53 all'indirizzo. Console di gestione AWS [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel riquadro di navigazione scegliere **Hosted Zones (Zone ospitate)**. 1. Nella pagina **Hosted zones (Zone ospitate) **, scegli il nome di una zona ospitata. La console visualizza l'elenco dei record per tale hosted zone. 1. Per passare direttamente alla pagina **Controlla risposta da Route 53**, seleziona **Test record**. 1. Specifica i seguenti valori: + Il nome del record, escluso il nome della zona ospitata. Ad esempio, per controllare **www.example.com**, inserire **www**. Per controllare **example.com**, lasciare vuoto il campo **Record name (Nome record)** . + Il tipo di record che si desidera controllare, ad esempio **A** o **CNAME**. 1. Scegli **Get Response (Ottieni risposta)**. 1. La sezione **Response returned by Route 53 (Risposta restituita da Route 53)** include i seguenti valori: **Codice di risposta DNS** Un codice che indica se la query era valida o meno. Il codice di risposta più comune è **NOERROR**, che indica che la query era valida. Se la risposta non è valida, Route 53 restituisce un codice di risposta che spiega il motivo. Per un elenco dei codici di risposta possibili, consulta [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) sul sito Web di IANA. **Protocollo** Il protocollo che è stato usato da Amazon Route 53 per rispondere alla query, **UDP** o **TCP**. **Risposta restituita da Route 53** Il valore che Route 53 restituirebbe a un'applicazione Web. Il valore è uno dei seguenti: + Per i record non di alias, la risposta contiene il valore o i valori nel record. + Per più record con lo stesso nome e tipo, tra cui record ponderati, di latenza, di geolocalizzazione e di failover, la risposta contiene il valore proveniente dal record appropriato, in base alla richiesta. + Per i record di alias che si riferiscono a AWS risorse diverse da un altro record, la risposta contiene un indirizzo IP o un nome di dominio per la AWS risorsa, a seconda del tipo di risorsa. + Per i record alias che fanno riferimento ad altri record, la risposta contiene il valore o i valori provenienti dal record di riferimento. ## Utilizzo dello strumento di controllo per la simulazione di query da indirizzi IP specifici (solo record di geolocalizzazione e latenza) Se hai creato record di latenza o record di geolocalizzazione, puoi utilizzare lo strumento di controllo per simulare le query tramite l'indirizzo IP per un resolver DNS e un client. **Utilizzare lo strumento di controllo per simulare le query da parte di indirizzi IP specificati** 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 riquadro di navigazione scegliere **Hosted Zones (Zone ospitate)**. 1. Nella pagina **Hosted zones (Zone ospitate) **, scegli il nome di una zona ospitata. La console visualizza l'elenco dei record per tale hosted zone. 1. Per passare direttamente alla pagina **Check response from Route 53 (Controlla riposta da Route 53)**, seleziona **Test record set (Testa serie di record)**. Per passare alla pagina **Check response from Route 53 (Controlla riposta da Route 53)** per un record specifico, seleziona la casella di controllo per il record e seleziona **Test record set (Testa serie di record)**. 1. Se si è selezionato **Test record set (Testa serie di record)** senza aver prima scelto un record, specificare i seguenti valori: + Il nome del record, escluso il nome della zona ospitata. Ad esempio, per controllare **www.example.com**, inserire **www**. Per controllare **example.com**, lasciare vuoto il campo **Record name (Nome record)** . + Il tipo di record che si desidera controllare, ad esempio **A** o **CNAME**. 1. Specifica i valori applicabili: **Indirizzo IP del resolver** Specificate un IPv6 indirizzo IPv4 or per simulare la posizione del resolver DNS utilizzato da un client per effettuare richieste. Questa funzione è utile per il testing dei record di latenza e di geolocalizzazione. Se si omette questo valore, lo strumento utilizza l'indirizzo IP di un resolver DNS nella regione AWS Stati Uniti orientali (Virginia settentrionale) (us-east-1). **EDNS0 IP di sottorete del client** Se il resolver lo supporta EDNS0, inserisci l'IP della sottorete del client per un indirizzo IP nella posizione geografica applicabile, ad esempio **192.0.2.0 o **2001:db** 8:85 a3: :8a2e: 370:7334**. **Maschera sottorete** Se specificate un indirizzo IP per l'IP della **sottorete EDNS0 del client, potete facoltativamente specificare il numero di bit dell'indirizzo IP** che lo strumento di controllo includa nella query DNS. **Ad esempio, se si specifica **192.0.2.44** per l'**IP di sottorete EDNS0 del client e 24 per la subnet** ****mask**, lo strumento di controllo simulerà una query da 192.0.2.0/24**.** Il valore predefinito è 24 bit per gli indirizzi e 64 bit per gli indirizzi. IPv4 IPv6 1. Scegli **Get Response (Ottieni risposta)**. 1. La sezione **Response returned by Route 53 (Risposta restituita da Route 53)** include i seguenti valori: **Query DNS inviata a Route 53** La query, in [formato BIND](https://en.wikipedia.org/wiki/Zone_file), che lo strumento di controllo ha inviato a Route 53. Questo è lo stesso formato che un'applicazione Web utilizzerebbe per inviare una query. I tre valori sono tipicamente il nome del record, **IN** (per internet), e il tipo di record. **Codice di risposta DNS** Un codice che indica se la query era valida o meno. Il codice di risposta più comune è **NOERROR**, che indica che la query era valida. Se la risposta non è valida, Route 53 restituisce un codice di risposta che spiega il motivo. Per un elenco dei codici di risposta possibili, consulta [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) sul sito Web di IANA. **Protocollo** Il protocollo che è stato usato da Amazon Route 53 per rispondere alla query, **UDP** o **TCP**. **Risposta restituita da Route 53** Il valore che Route 53 restituirebbe a un'applicazione Web. Il valore è uno dei seguenti: + Per i record non di alias, la risposta contiene il valore o i valori nel record. + Per più record con lo stesso nome e tipo, tra cui record ponderati, di latenza, di geolocalizzazione e di failover, la risposta contiene il valore proveniente dal record appropriato, in base alla richiesta. + Per i record di alias che si riferiscono a AWS risorse diverse da un altro record, la risposta contiene un indirizzo IP o un nome di dominio per la AWS risorsa, a seconda del tipo di risorsa. + Per i record alias che fanno riferimento ad altri record, la risposta contiene il valore o i valori provenienti dal record di riferimento. # Configurazione dei server di nomi white label Ogni zona ospitata di Amazon Route 53 è associata a quattro server di nomi, noti collettivamente come set di delega. Per impostazione predefinita, i server di nomi hanno nomi come ns-2048.awsdns-64.com. Se desideri che il nome di dominio del tuo server di nomi sia lo stesso nome di dominio della tua zona ospitata, ad esempio, ns1.esempio.com, puoi configurare nomi di server white label, noti anche come server di nomi vanity o privati. La procedura seguente spiega come configurare un set di quattro server di nomi white label che puoi riutilizzare per più domini. Ad esempio, supponiamo che possiedi i domini esempio.com, esempio.org ed esempio.net. Grazie a questi passaggi, puoi configurare server di nomi white label per esempio.com e riutilizzarli per esempio.org ed esempio.net. **Topics** + [Fase 1: Creazione un set di delega Route 53 riutilizzabile](#white-label-name-servers-create-reusable-delegation-set) + [Fase 2: Creazione o nuova creazione di una zona ospitata di Amazon Route 53 e modifica del TTL per i record NS e SOA](#white-label-name-servers-create-hosted-zones) + [Fase 3: ricrea record per le hosted zone](#white-label-name-servers-create-resource-record-sets) + [Fase 4: ottenere gli indirizzi IP](#white-label-name-servers-get-ip-addresses) + [Fase 5: crea record per server di nomi white label](#white-label-name-servers-create-white-label-resource-record-sets) + [Fase 6: aggiorna i record NS e SOA](#white-label-name-servers-update-ns-soa-records) + [Fase 7: crea record associati e modifica i server di nomi del registrar](#white-label-name-servers-create-glue-records) + [Fase 8: monitora il traffico per il tuo sito Web o applicazione](#white-label-name-servers-monitor-traffic) + [Fase 9: TTLs Tornate ai valori originali](#white-label-name-servers-change-ttls-back) + [Fase 10: (opzionale) contatta i servizi DNS ricorsivi](#white-label-name-servers-contact-recursive-dns-services) ## Fase 1: Creazione un set di delega Route 53 riutilizzabile I server dei nomi con white label sono associati a un set di delega Route 53 riutilizzabile. È possibile utilizzare server di nomi con etichetta bianca per una zona ospitata solo se la zona ospitata e il set di deleghe riutilizzabile sono stati creati dallo stesso account. AWS Per creare un set di deleghe riutilizzabile, puoi utilizzare l'API Route 53, la AWS CLI o una delle. AWS SDKs Per ulteriori informazioni, consulta la seguente documentazione: + **API Route 53**: consulta la [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)guida di *riferimento all'API Amazon Route 53* + **AWS CLI** *— Vedi [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html)nel riferimento ai comandi AWS CLI * + **AWS SDKs**[Consulta la documentazione SDK applicabile nella pagina Documentazione AWS](https://docs.aws.amazon.com/) ## Fase 2: Creazione o nuova creazione di una zona ospitata di Amazon Route 53 e modifica del TTL per i record NS e SOA Crea o crea nuovamente le zone ospitate per Amazon Route 53: + **Se non stai utilizzando Route 53 come servizio DNS per i domini per i quali desideri utilizzare server di nomi white label**: crea le zone ospitate e specifica il set di delega riutilizzabile creato nella fase precedente con ogni zona ospitata. Per ulteriori informazioni, [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)consulta *Amazon Route 53 API Reference*. + **Se stai utilizzando Route 53 come servizio DNS per i domini per i quali desideri utilizzare server di nomi white label**: devi creare le zone ospitate per cui desideri utilizzare i server dei nomi white label e specificare il set di delega riutilizzabile creato nella fase precedente per ogni zona ospitata. **Importante** Non puoi modificare i server di nomi che sono associati a una zona ospitata esistente. Puoi associare un set di delega riutilizzabile a una zona ospitata solo quando crei la hosted zone. Quando crei le zone ospitate e prima di tentare di accedere alle risorse per i domini corrispondenti, modifica i seguenti valori di TTL per ogni hosted zone: + Cambia il valore TTL per il record NS per le zone ospitate su 60 secondi o meno. + Cambia il valore TTL minimo per il record SOA per le zone ospitate su 60 secondi o meno. Questo è l'ultimo valore nel record SOA. Se accidentalmente dai al tuo registrar indirizzi IP sbagliati per i server di nomi white label, il tuo sito Web non sarà disponibile e non sarà disponibile per la durata del TTL dopo aver corretto il problema. Impostando un valore TTL basso, puoi ridurre la quantità di tempo per cui il tuo sito Web non è disponibile. Per ulteriori informazioni sulla creazione di zone ospitate e sulla specifica di un set di delega riutilizzabile per i name server per le zone ospitate, consulta [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)*Amazon Route 53 API* Reference. ## Fase 3: ricrea record per le hosted zone Crea record nelle zone ospitate create nella fase 2: + **Se stai eseguendo la migrazione del servizio DNS per i tuoi domini ad Amazon Route 53** - potresti essere in grado di creare record importando le informazioni sui record esistenti. Per ulteriori informazioni, consulta [Creazione di record mediante importazione di un file di zona](resource-record-sets-creating-import.md). + **Se stai sostituendo le zone ospitate esistenti in modo che sia possibile utilizzare server dei nomi white label**: nelle nuove zone ospitate, crea nuovamente i record che appaiono nelle tue zone ospitate correnti. Route 53 non fornisce un metodo per l'esportazione di record da una zona ospitata, ma alcuni fornitori di terze parti lo fanno. Puoi quindi utilizzare la funzione di importazione di Route 53 per importare record non alias per i quali la policy di routing è semplice. Non vi è alcun modo per esportare e importare nuovamente record o record alias per cui la policy di routing non è semplice. Per informazioni sulla creazione di record utilizzando l'API Route 53, consulta [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)*Amazon Route 53 API Reference*. Per informazioni sulla creazione di record utilizzando la console Route 53, consulta [Utilizzo dei record](rrsets-working-with.md). ## Fase 4: ottenere gli indirizzi IP Ottieni gli IPv6 indirizzi IPv4 e gli indirizzi dei name server nel set di delega riutilizzabile e compila la tabella seguente. **** | Nome di un server di nomi nel set di delega riutilizzabile (ad esempio: ns-2048.awsdns-64.com) | IPv4 e indirizzi IPv6                                             | Nome che desideri assegnare al server di nomi white label (ad esempio: ns1.esempio.com) | | --- | --- | --- | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | Ad esempio, supponiamo che i quattro nomi di server per il set di delega riutilizzabile sono: + ns-2048.awsdns-64.com + ns-2049.awsdns-65.net + ns-2050.awsdns-66.org + ns-2051.awsdns-67.co.uk Di seguito sono descritti i comandi di Linux e Windows da eseguire per ottenere gli indirizzi IP per il primo dei quattro server di nomi: **comandi dig per Linux** ``` % dig A ns-2048.awsdns-64.com +short 192.0.2.117 ``` ``` % dig AAAA ns-2048.awsdns-64.com +short 2001:db8:85a3::8a2e:370:7334 ``` **comando nslookup per Windows** ``` c:\> nslookup ns-2048.awsdns-64.com Non-authoritative answer: Name: ns-2048.awsdns-64.com Addresses: 2001:db8:85a3::8a2e:370:7334 192.0.2.117 ``` ## Fase 5: crea record per server di nomi white label Nella zona ospitata che ha lo stesso nome (ad esempio esempio.com) del nome di dominio del server di nomi white label (ad esempio ns1.esempio.com), crea otto record: + Un record A per ogni server di nomi white label + Un record AAAA per ogni server di nomi white label **Importante** Se utilizzi gli stessi server di nomi white label per due o più zone ospitate, non eseguire questa operazione per le altre zone ospitate. Per ogni record, specifica i seguenti valori. Per ulteriori informazioni, consulta la tabella compilata nella fase precedente: **Policy di routing** Specifica **Routing semplice**. **Nome record** Il nome che desideri assegnare a uno dei tuoi server di nomi white label, ad esempio: ns1.esempio.com. Per il prefisso (ns1 in questo esempio), puoi utilizzare qualsiasi valore valido in un nome di dominio. **Valore/instradamento traffico a** L' IPv6 indirizzo IPv4 o di uno dei name server di Route 53 nel set di delega riutilizzabile. Se specifichi indirizzi IP sbagliati al momento della creazione di record per i server di nomi white label, il tuo sito o applicazione Web non sarà disponibile su Internet quando esegui le fasi successive. Anche se correggi gli indirizzi IP immediatamente, il tuo sito o applicazione Web rimarrà non disponibile per la durata del TTL. **Tipo di record** Specificare **A** quando si creano record per gli IPv4 indirizzi. Specificate **AAAA** quando create i record per gli IPv6 indirizzi. **TTL (secondi)** Questo valore è la quantità di tempo per cui i resolver DNS memorizzano nella cache le informazioni di questo record prima di inoltrare un'altra query DNS a Route 53. È consigliabile specificare un valore iniziale di 60 secondi o meno, in modo che sia possibile recuperare in modo rapido se accidentalmente si specificano valori errati in questi record. ## Fase 6: aggiorna i record NS e SOA Aggiorna i record SOA e NS nelle zone ospitate per cui desideri utilizzare i server di nomi white label. Esegui le fasi dalla 6 alla 8 per una zona ospitata e il dominio corrispondente alla volta, quindi ripeti la procedura per un'altra zona ospitata e dominio. **Importante** Inizia con la zona ospitata di Amazon Route 53 che ha lo stesso nome di dominio (ad esempio esempio.com) del server dei nomi white label (ad esempio ns1.esempio.com). 1. Aggiornamento del record SOA sostituendo il nome del server dei nomi di Route 53 con il nome di uno dei server dei nomi white label **Esempio** Sostituisci il nome del server di nomi Route 53: `ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60` con il nome di uno dei tuoi server di nomi white label: `ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60` **Nota** È stato modificato l'ultimo valore, il time to live (TTL) in [Fase 2: Creazione o nuova creazione di una zona ospitata di Amazon Route 53 e modifica del TTL per i record NS e SOA](#white-label-name-servers-create-hosted-zones). Per informazioni sull'aggiornamento di record utilizzando la console Route 53, consulta [Modifica di record](resource-record-sets-editing.md). 1. Nel record NS, annota i nomi dei server di nomi attuali per il dominio, in modo da poterli ripristinare, se necessario. 1. Aggiorna il record NS. Sostituisci il nome dei server di nomi Route 53 con i nomi dei tuoi quattro server di nomi white label, ad esempio, `ns1.example.com`, `ns2.example.com`, `ns3.example.com` e `ns4.example.com`. ## Fase 7: crea record associati e modifica i server di nomi del registrar Utilizza il metodo fornito dal registrar per creare record associati e modificare i server di nomi del registrar: 1. Aggiungere record associati: + **Se stai aggiornando il dominio con lo stesso nome di dominio dei server dei nomi white label**: crea quattro Glue Record associati per i quali i nomi e gli indirizzi IP corrispondono ai valori che hai ottenuto nella fase 4. Includi IPv4 sia l'indirizzo che l' IPv6 indirizzo di un name server con etichetta bianca nel record Glue corrispondente, ad esempio: **ns1.example.com**: indirizzi IP = 192.0.2.117 e 2001:db8:85a3::8a2e:370:7334 I registrar utilizzano una serie di termini diversi per i record associati. Questa operazione è nota anche come registrazione di nuovi server di nomi o qualcosa di simile. + **Se stai aggiornando un altro dominio**— Se Route 53 è il servizio DNS, è necessario prima completare il passaggio nel punto precedente e creare i record di colla corrispondenti al nome di dominio. Passare quindi alla fase 2 in questa procedura. 1. Cambia server dei nomi per il dominio con i nomi dei tuoi server di nomi white label. Se stai utilizzando Amazon Route 53 come servizio DNS, consulta [Aggiunta o modifica di server di nomi e glue record per un dominio](domain-name-servers-glue-records.md). ## Fase 8: monitora il traffico per il tuo sito Web o applicazione Monitora il traffico per il sito Web o l'applicazione per cui hai creato record associati e modificato i server di nomi nella fase 7: + **Se il traffico si interrompe**: utilizza il metodo fornito dal registrar per modificare i server dei nomi per il dominio e riportarli ai precedenti server di nomi di Route 53. Questi sono i server di nomi che avevi annotato nella fase 6b. Stabilisci quindi ciò che non ha funzionato. + **Se il traffico non è influenzato**: ripeti le fasi da 6 a 8 per il resto delle zone ospitate per cui desideri utilizzare gli stessi server dei nomi white label. ## Fase 9: TTLs Tornate ai valori originali Per tutte le zone ospitate che ora utilizzano i server di nomi white label, modifica i seguenti valori: + Cambia il valore TTL per il record NS per le zone ospitate con un valore più tipico per i record NS, per esempio, 172800 secondi (due giorni). + Cambia il valore TTL minimo per il record SOA per le zone ospitate con un valore più tipico per i record SOA, per esempio, 900 secondi, Questo è l'ultimo valore nel record SOA. ## Fase 10: (opzionale) contatta i servizi DNS ricorsivi *Facoltativo* Se utilizzi il routing di geolocalizzazione di Amazon Route 53, contatta i servizi DNS ricorsivi che supportano l' edns-client-subnetestensione di e fornisci loro i nomi dei EDNS0 tuoi name server con etichetta bianca. In questo modo questi servizi DNS continueranno a instradare le query DNS alla posizione Route 53 ottimale in base alla posizione geografica approssimativa da cui è provenuta la query. # Record NS e SOA creati da Amazon Route 53 per una zona ospitata pubblica Per ciascuna zona ospitata creata, Amazon Route 53 crea automaticamente un record di server dei nomi (NS) e un record di origine di autorità (SOA). Raramente è necessario modificare questi record. **Topics** + [Il record di server dei nomi (NS)](#NSrecords) + [Il record di origine di autorità (SOA)](#SOArecords) ## Il record di server dei nomi (NS) Amazon Route 53 crea automaticamente un record di server dei nomi (NS) che ha lo stesso nome della tua zona ospitata. Vengono elencati i quattro server di nomi che sono i server di nomi ufficiali per la tua hosted zone. Tranne che in circostanze rare, si consiglia di non aggiungere, modificare o eliminare i server dei nomi in questo record. I seguenti esempi mostrano il formato per i nomi di server dei nomi di Route 53 (sono solo esempi; non utilizzarli durante l'aggiornamento dei record di server dei nomi del tuo registrar): + *ns-2048.awsdns-64.com* + *ns-2049.awsdns-65.net* + *ns-2050.awsdns-66.org* + *ns-2051.awsdns-67.co.uk* Per ottenere l'elenco dei server di nomi per la tua hosted zone: 1. Accedi e apri la console Route 53 all'indirizzo. Console di gestione AWS [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione, scegli **Zone ospitate**. 1. Nella pagina **Zone ospitate**, scegli il pulsante di opzione (non il nome) per la zona ospitata, quindi seleziona **Visualizza dettagli**. 1. Nella pagina dei dettagli della zona ospitata, scegli **Dettagli della zona ospitata**. 1. Prendi nota dei quattro server indicati per **Server dei nomi**. Per ulteriori informazioni sulla migrazione del servizio DNS da un altro provider di servizi DNS a Route 53, consulta [Rendere Amazon Route 53 il servizio DNS per un dominio esistenteRendere il Route 53 il servizio DNS per un dominio esistente](MigratingDNS.md). ## Il record di origine di autorità (SOA) I; record origine di autorità (SOA) identifica le informazioni DNS di base che interessano il dominio, ad esempio: ``` 1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400 ``` Un record SOA include i seguenti elementi: + Il server dei nomi di Route 53 che ha creato il record SOA, ad esempio, `ns-2048.awsdns-64.net`. + L'indirizzo e-mail dell'amministratore. Il simbolo `@` è sostituito da un punto, ad esempio `hostmaster.example.com`. Il valore di default è un indirizzo e-mail amazon.com che non è monitorato. + Un numero di serie che puoi incrementare ogni volta che aggiorni un record nella zona ospitata. Route 53 non incrementa automaticamente il numero. (Il numero di serie viene utilizzato dai servizi DNS che supportano il DNS secondario.) In questo esempio, il valore è `1`. + Un tempo di aggiornamento in secondi che i server DNS secondari attendono prima di eseguire query sui record SOA dei server DNS primari per verificare la presenza di modifiche. In questo esempio, il valore è `7200`. + L'intervallo in secondi che un server secondario attende prima di provare il trasferimento di una zona non riuscito. Di solito, il tempo per il nuovo tentativo è inferiore al tempo di aggiornamento. In questo esempio, il valore è `900` (15 minuti). + Il tempo in secondi per cui un server secondario continuerà a tentare di completare un trasferimento di zona. Se questo trascorre prima del trasferimento, il server secondario smetterà di rispondere alle query perché considera i suoi dati troppo vecchi per essere affidabili. In questo esempio, il valore è `1209600` (due settimane). + Il TTL minimo. Questo valore consente di definire il periodo di tempo in cui i resolver ricorsivi devono memorizzare nella cache le seguenti risposte da Route 53: **NXDOMAIN** Non vi è alcun record di alcun tipo con il nome specificato nella query DNS, ad esempio example.com. Non sono inoltre presenti record figlio del nome specificato nella query DNS, ad esempio zenith.example.com. **NODATA** Esiste almeno un record con il nome specificato nella query DNS, ma nessuno di questi record ha il tipo (ad esempio A) specificato nella query DNS. Quando un resolver DNS memorizza nella cache un risultato NXDOMAIN, questa operazione viene definita come *memorizzazione negativa nella cache*. La durata della memorizzazione negativa nella cache è il minore dei seguenti valori: + Questo valore: il TTL minimo nel record SOA. Nell'esempio, il valore è `86400` (un giorno). + Il valore del TTL per il record SOA. Il valore predefinito è 900 secondi. Per informazioni su come modificare questo valore, consulta [Modifica di record](resource-record-sets-editing.md). Quando Route 53 risponde alle query DNS con una risposta NXDOMAIN o NODATA (una risposta negativa), viene addebitata la tariffa per le query standard. Consulta "Query" in [Prezzi di Amazon Route 53](https://aws.amazon.com/route53/pricing/). Se sei preoccupato per il costo delle risposte negative, un'opzione consiste nel modificare il TTL per il record SOA, il valore TTL minimo nel record SOA (questo valore) o entrambi. Tieni presente che l'aumento di questi valori TTLs, che si applicano alle risposte negative per l'intera zona ospitata, può avere effetti sia positivi che negativi: + I resolver DNS di Internet memorizzano nella cache l'inesistenza di record per periodi più lunghi, cosa che riduce il numero di query che vengono inoltrate a Route 53. In questo modo si riduce l'addebito di Route 53 per le query DNS. + Tuttavia, se si elimina erroneamente un record valido e successivamente lo si ricrea, i resolver DNS memorizzeranno nella cache la risposta negativa (questo record non esiste) per un periodo più lungo. In questo modo si allungano i tempi in cui i clienti o gli utenti non possono raggiungere la risorsa corrispondente, ad esempio un server Web per acme.example.com. **Per trovare i record SOA in Route 53** 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**. 1. Seleziona il nome collegato del dominio per cui desideri visualizzare i record. 1. Nella sezione **Records** (Record) puoi visualizzare tutti i record elencati e puoi filtrarli in modo da trovare il valore del tuo SOA. # Abilitare il ripristino accelerato per la gestione dei record DNS pubblici Il ripristino accelerato di Route 53 per la gestione dei record DNS pubblici è progettato per raggiungere un Recovery Time Objective (RTO) di 60 minuti in caso di indisponibilità del servizio nella regione Stati Uniti orientali (Virginia settentrionale). Se abilitato su una zona ospitata pubblica su Route 53, sarà possibile riprendere ad apportare modifiche ai record DNS nella zona ospitata pubblica entro circa 60 minuti dal AWS rilevamento che le operazioni nella regione Stati Uniti orientali (Virginia settentrionale) sono compromesse. **Importante** Il ripristino accelerato è disponibile solo per le zone ospitate pubbliche. Le zone ospitate private non sono supportate. **Nota** La risoluzione delle query DNS dal piano dati della Route 53 continua a funzionare normalmente durante l'interruzione del servizio regionale. Vedi [Resilience in Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) per una comprensione delle operazioni del piano dati rispetto a quelle del piano di controllo. **Topics** + [Come funziona il ripristino accelerato per i record DNS pubblici](#accelerated-recovery-how-it-works) + [Reinvio delle modifiche DNS dopo il failover](#accelerated-recovery-resubmit) + [Failback nella regione Stati Uniti orientali (Virginia settentrionale)](#accelerated-recovery-failback) + [Ulteriori considerazioni](#accelerated-recovery-considerations) + [Come abilitare il ripristino accelerato per la gestione dei record DNS pubblici](#accelerated-recovery-enable) ## Come funziona il ripristino accelerato per i record DNS pubblici Quando il ripristino accelerato è abilitato, Route 53 manterrà una copia della tua zona ospitata pubblica nella regione degli Stati Uniti occidentali (Oregon). Se i servizi nella regione Stati Uniti orientali (Virginia settentrionale) non sono disponibili per un periodo prolungato, Route 53 eseguirà il failover entro 60 minuti, reindirizzando automaticamente le operazioni del piano di controllo per le zone ospitate pubbliche abilitate al ripristino accelerato verso la regione Stati Uniti occidentali (Oregon). Puoi quindi continuare ad apportare modifiche al DNS a livello di codice tramite CLI, SDK e API. Tieni presente che durante il failover sarà disponibile un set limitato di metodi API. Per ulteriori dettagli, consulta la sezione «Considerazioni aggiuntive». Quando la regione si riprenderà, Route 53 eseguirà la procedura di failback, indirizzando automaticamente le operazioni del piano di controllo verso la regione degli Stati Uniti orientali (Virginia settentrionale). **Nota** Prima che si verifichi qualsiasi danno alla regione Stati Uniti orientali (Virginia settentrionale), è necessario innanzitutto abilitare il ripristino accelerato per la gestione dei record DNS pubblici nella zona ospitata pubblica. Questa operazione può essere eseguita tramite Console, CLI, SDK o API (vedi la sezione intitolata *Come abilitare il ripristino accelerato per la gestione dei record DNS pubblici* in questa pagina di seguito). Non è possibile abilitare il ripristino accelerato per la gestione dei record DNS pubblici dopo un failover. ## Reinvio delle modifiche DNS dopo il failover In condizioni normali, le modifiche alle zone ospitate pubbliche con ripristino accelerato abilitato verranno accettate dalla regione Stati Uniti orientali (Virginia settentrionale) e quindi replicate con successo nella regione Stati Uniti occidentali (Oregon). Tuttavia, quando si verifica un'interruzione del servizio nella regione Stati Uniti orientali (Virginia settentrionale), alcune modifiche possono essere accettate dalla regione Stati Uniti orientali (Virginia settentrionale), ma non possono essere replicate nella regione Stati Uniti occidentali (Oregon). Queste modifiche in corso vengono definite «modifiche bloccate». Una volta completato il failover, Route 53 consiglia di inviare nuovamente le modifiche non disponibili prima di riprendere i flussi di lavoro DNS. È possibile ottenere ciò utilizzando l'API o utilizzando quanto descritto di seguito. AWS CloudFormation ### Utilizzo dell'API per tracciare e inviare le modifiche DNS [Se utilizzi l'API Route 53, la AWS CLI o AWS SDKs per gestire i record DNS, dovrai utilizzare l'API e l'[ChangeResourceRecordSets API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) rispettivamente per inviare e tenere traccia delle GetChange modifiche DNS.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) Quando utilizzi l' ChangeResourceRecordSets API per apportare modifiche al DNS, Route 53 restituisce un identificatore (ID) per la modifica apportata (vedi [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)per i dettagli dell'oggetto di risposta alle modifiche). Puoi fornire questo ID in una richiesta successiva all' GetChange API e osservare lo stato della modifica. Le modifiche DNS con stato INSYNC sono state replicate nella regione Stati Uniti occidentali (Oregon) e propagate a tutti i server DNS della Route 53. Non è necessario eseguire ulteriori azioni su queste modifiche prima o dopo un failover. Tuttavia, in caso di riduzione del valore nella regione Stati Uniti orientali (Virginia settentrionale), GetChange potrebbe tornare PENDING, a indicare che la modifica potrebbe non essere stata replicata nella regione Stati Uniti occidentali (Oregon). In tal caso, una volta completato il failover, GetChange verrà restituito, a indicare che Route 53 non è riuscita a NoSuchChange replicare questa modifica DNS. Pertanto, dopo il failover, puoi tranquillamente ignorare queste modifiche DNS bloccate e inviarle nuovamente come nuove modifiche DNS. Saprai che il processo di failover è stato completato quando Route 53 pubblica un messaggio su AWS Health Dashboard. ### Utilizzo AWS CloudFormation per tenere traccia e inviare le modifiche AWS CloudFormation monitora automaticamente lo stato di replica delle modifiche DNS utilizzando l' GetChange API e completa un aggiornamento solo dopo che le modifiche DNS sono state confermate come INSYNC. Se lo utilizzi CloudFormation per gestire i record DNS e la regione Stati Uniti orientali (Virginia settentrionale) non è più disponibile, le azioni intraprese non CloudFormation verranno completate correttamente durante il periodo di indisponibilità. Tuttavia, puoi semplicemente ripetere le stesse azioni per consentire CloudFormation di inviare nuovamente le modifiche DNS, una volta completato il processo di failover di Route 53. ## Failback nella regione Stati Uniti orientali (Virginia settentrionale) Una volta ripristinata la situazione, Route 53 ripristinerà le operazioni del piano di controllo per la zona ospitata dal pubblico verso la regione degli Stati Uniti orientali (Virginia settentrionale). Durante il failback, non sarà necessario inviare nuovamente le modifiche DNS, poiché durante questo processo non verranno introdotte modifiche bloccate. ## Ulteriori considerazioni È necessario tenere presente alcune considerazioni aggiuntive relative alla funzionalità di ripristino accelerato: 1. Non sarà possibile creare nuove zone ospitate, eliminare zone ospitate esistenti, abilitare la firma DNSSEC o disabilitare la firma DNSSEC durante il failover. 1. AWS PrivateLink le connessioni non funzioneranno dopo il failover, ma funzioneranno nuovamente dopo un failback nella regione Stati Uniti orientali (Virginia settentrionale). 1. CloudFront Al momento non sono supportati [i piani forfettari](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html). 1. Le zone ospitate con ripristino accelerato abilitato non possono essere eliminate. È necessario disabilitare il ripristino accelerato prima di tentare di eliminare la zona ospitata. 1. Durante il failover, i seguenti metodi API continueranno a essere supportati per le zone ospitate pubbliche con ripristino accelerato abilitato. Tuttavia, tutti gli altri metodi API di Route 53 non funzioneranno fino a quando non si verificherà un failback. + `ChangeResourceRecordSets` + `GetChange` + `GetGeoLocation` + `GetHostedZone` + `GetHostedZoneCount` + `GetHostedZoneLimit` + `GetReusableDelegationSet` + `GetReusableDelegationSetLimit` + `ListGeoLocations` + `ListHostedZones` + `ListHostedZonesByName` + `ListResourceRecordSets` + `ListReusableDelegationSets` ## Come abilitare il ripristino accelerato per la gestione dei record DNS pubblici Puoi abilitare il ripristino accelerato per la gestione dei record DNS pubblici utilizzando la console Route 53, l'API, la CLI o l'SDK. Il tempo necessario per abilitare il ripristino accelerato dipenderà dalle dimensioni della zona ospitata pubblica e da altri fattori. È consigliabile pianificare che il processo di attivazione del ripristino accelerato richieda fino a diverse ore. Puoi controllare lo stato del processo di abilitazione nella scheda Ripristino accelerato della tua zona ospitata pubblica o tramite l'API. `GetHostedZone` Una volta completato il processo, ci sarà un breve periodo di tempo della durata di diversi minuti in cui le modifiche al DNS non verranno accettate. Una volta completate, le modifiche al DNS possono procedere normalmente. **Per abilitare e disabilitare il ripristino accelerato utilizzando la console Route 53** 1. 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**. 1. Scegli la zona ospitata pubblica per la quale desideri abilitare il ripristino accelerato. 1. **Nella scheda **Ripristino accelerato**, scegli Abilita.** 1. Scegli **Save changes** (Salva modifiche). 1. Monitora lo stato della zona ospitata. Lo stato mostra **Abilitazione del ripristino accelerato** durante la configurazione e cambia in **Abilitato** al termine. **Puoi disabilitare il ripristino accelerato seguendo gli stessi passaggi precedenti, ma scegliendo invece Disabilita.** Esempio di CLI da abilitare ``` aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789 ``` Esempio CLI da disabilitare ``` aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789 ``` # Utilizzo delle zone ospitate private Una *zona ospitata privata* è un contenitore che contiene informazioni su come desideri che Amazon Route 53 risponda alle query DNS per un dominio e i relativi sottodomini all'interno di uno o più VPCs domini creati con il servizio Amazon VPC. Di seguito viene descritto il funzionamento delle zone ospitate private: 1. Puoi creare una zona ospitata privata, come esempio.com, e specificare il VPC che desideri associare alla zona ospitata. Dopo aver creato la zona ospitata, puoi associarne altre. VPCs 1. Puoi creare record nella zona ospitata in grado di determinare il modo in cui Route 53 risponde alle query DNS per i dominio e sottodomini all'interno e tra i tuoi VPC. Supponiamo ad esempio che tu disponga di un server di database in esecuzione su un'istanza EC2 nel VPC associato alla zona ospitata privata. Puoi creare un record A o AAAA, ad esempio db.esempio.com e specificare l'indirizzo IP del server di database. Per ulteriori informazioni sul record, consulta [Utilizzo dei record](rrsets-working-with.md). Per informazioni sui requisiti di Amazon VPC per l'utilizzo di zone ospitate private, consulta [Utilizzo di zone ospitate private](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) nella *Guida per l'utente di Amazon VPC*. 1. Quando un'applicazione inoltra una query DNS per db.esempio.com, Route 53 restituisce l'indirizzo IP corrispondente. Per ottenere una risposta da una zona ospitata privata devi anche eseguire un'istanza EC2 in una delle aree associate VPCs (o disporre di un endpoint in entrata da una configurazione ibrida). Se tenti di interrogare una zona ospitata privata dall'esterno della configurazione VPCs o della configurazione ibrida, la richiesta verrà risolta in modo ricorsivo su Internet. 1. L'applicazione utilizza l'indirizzo IP che ha ricevuto da Route 53 per stabilire una connessione con il server di database. Quando crei una zona ospitata privata, vengono utilizzati i seguenti server nomi: + ns-0.awsdns-00.com + ns-512.awsdns-00.net + ns-1024.awsdns-00.org + ns-1536.awsdns-00.co.uk Questi server nomi vengono utilizzati perché il protocollo DNS richiede che ogni zona ospitata disponga di un set di record NS. Questi server nomi sono riservati e non vengono mai utilizzati dalle zone ospitate pubbliche di Route 53. È possibile interrogare tali zone solo tramite VPC Resolver in un VPC che è stato associato alla zona ospitata utilizzando un endpoint in ingresso connesso a quello specificato nella zona ospitata privata. VPCs Sebbene i name server siano visibili su Internet, VPC Resolver non si connette agli indirizzi dei name server. Inoltre, le informazioni sulle zone ospitate private non vengono restituite se si esegue una query direttamente sui server dei nomi tramite Internet. Invece, il VPC Resolver rileva che le query si trovano all'interno di un namespace privato basato su associazioni di zone ospitate da VPC e utilizza la connettività privata diretta per raggiungere i server DNS privati. **Nota** Se lo desideri, puoi modificare il set di record NS in una zona ospitata privata senza compromettere il funzionamento della risoluzione DNS privata. Se decidi di eseguire questa operazione, sebbene non sia consigliata, scegli nomi di dominio riservati che non vengono utilizzati dai server DNS pubblici. Se desideri instradare il traffico per il tuo dominio su Internet, utilizza una zona ospitata *pubblica* di Route 53. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate pubbliche](AboutHZWorkingWith.md). **Topics** + [Considerazioni sull’utilizzo di una zona ospitata privata](hosted-zone-private-considerations.md) + [Creazione di una zona ospitata privata](hosted-zone-private-creating.md) + [Elencare zone ospitate private](hosted-zone-private-listing.md) + [Associarne di più VPCs a una zona ospitata privata](hosted-zone-private-associate-vpcs.md) + [Associazione di un Amazon VPC e una zona ospitata privata creata con account diversi AWS](hosted-zone-private-associate-vpcs-different-accounts.md) + [Dissociarsi VPCs da una zona ospitata privata](hosted-zone-private-disassociate-vpcs.md) + [Eliminazione di una zona ospitata privata](hosted-zone-private-deleting.md) + [Autorizzazioni VPC](hosted-zone-private-vpc-permissions.md) # Considerazioni sull’utilizzo di una zona ospitata privata Quando usi le zone ospitate private, tieni in considerazione quanto segue: + [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings) + [Route 53 health checks](#hosted-zone-private-considerations-health-checks) + [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies) + [Split-view DNS](#hosted-zone-private-considerations-split-view-dns) + [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping) + [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping) + [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules) + [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain) + [Custom DNS servers](#hosted-zone-private-considerations-custom-dns) + [Required IAM permissions](#hosted-zone-private-considerations-required-permissions) **Impostazioni di Amazon VPC** Per usare zone ospitate private, devi impostare le seguenti impostazioni di Amazon VPC su `true`: + `enableDnsHostnames` + `enableDnsSupport` Per ulteriori informazioni, consulta [Visualizza e aggiorna gli attributi DNS per il tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) nella *Amazon VPC* User Guide. **Controllo dell'integrità di Route 53** In una zona ospitata privata, puoi associare i controlli di integrità di Route 53 solo ai record di failover, risposta multivalore, ponderata, latenza, geolocalizzazione e geoprossimità. Per ulteriori informazioni sull'associazione di controlli dell'integrità con record di failover, consulta [Configurazione del failover in una zona ospitata privata](dns-failover-private-hosted-zones.md). **Policy di routing supportate per i record in una zona ospitata privata** Puoi utilizzare le seguenti policy di routing al momento della creazione di un record in una zona ospitata privata: + [Routing semplice](routing-policy-simple.md) + [Routing di failover](routing-policy-failover.md) + [Routing di risposta multivalore](routing-policy-multivalue.md) + [Routing ponderato](routing-policy-weighted.md) + [Routing basato sulla latenza](routing-policy-latency.md) + [Routing di geolocalizzazione](routing-policy-geo.md) + [Geoproximity routing](routing-policy-geoproximity.md) La creazione di record in una zona ospitata privata utilizzando altre policy di routing non è supportata. **Visualizzazione doppia di DNS** Puoi utilizzare Route 53 per configurare DNS con visualizzazione separata, noto anche come DNS split-horizon. Nella visualizzazione doppia di DNS, utilizzi lo stesso nome di dominio (esempio.com) per usi interni (accounting.esempio.com) ed esterni, ad esempio il tuo sito Web pubblico (www.esempio.com). Potrebbe anche essere necessario utilizzare lo stesso nome di sottodominio internamente ed esternamente, ma servire contenuti diversi o richiedere un'autenticazione diversa per gli utenti interni ed esterni. Per configurare la visualizzazione doppia di DNS, esegui la procedura seguente: 1. Crea zone ospitate pubbliche e private con lo stesso nome. (La visualizzazione doppia di DNS funziona ancora se utilizzi un altro servizio DNS per la zona ospitata pubblica.) 1. Associa uno o più Amazon VPCs alla zona ospitata privata. Route 53 VPC Resolver utilizza la zona ospitata privata per instradare le query DNS nella zona specificata. VPCs 1. Crea record in ogni zona ospitata. I record nella zona ospitata pubblica controllano il modo in cui viene instradato il traffico Internet e i record nella zona ospitata privata controllano il modo in cui viene instradato il traffico su Amazon. VPCs Se devi eseguire la risoluzione dei nomi sia del tuo VPC che dei carichi di lavoro locali, puoi utilizzare Route 53 VPC Resolver. Per ulteriori informazioni, consulta [Cos'è Route 53 VPC Resolver?](resolver.md). **Zone ospitate pubbliche e private con spazi dei nomi sovrapposti** Se disponi di zone ospitate private e pubbliche con namespace sovrapposti, come example.com e accounting.example.com, VPC Resolver indirizza il traffico in base alla corrispondenza più specifica. Quando gli utenti accedono a un'istanza EC2 in un Amazon VPC che hai associato alla zona ospitata privata, ecco come Route 53 VPC Resolver gestisce le query DNS: 1. VPC Resolver valuta se il nome della zona ospitata privata corrisponde al nome di dominio nella richiesta, ad esempio accounting.example.com. Una corrispondenza è definita come segue: + Una corrispondenza identica + Il nome della zona ospitata privata è un elemento padre del nome di dominio nella richiesta. Ad esempio, supponiamo che il nome di dominio della richiesta sia il seguente: **seattle.accounting.esempio.com** Le seguenti zone ospitate corrispondono perché sono elementi padre di seattle.accounting.esempio.com: + **accounting.esempio.com** + **esempio.com** Se non esiste una zona ospitata privata corrispondente, VPC Resolver inoltra la richiesta a un resolver DNS pubblico e la richiesta viene risolta come una normale query DNS. 1. Se esiste un nome di zona ospitata privata che corrisponde al nome di dominio nella richiesta, nella zona ospitata viene ricercato un record che corrisponde al nome di dominio DNS e al tipo della richiesta, ad esempio un record per accounting.esempio.com. **Nota** Se esiste una zona ospitata privata corrispondente ma non esiste alcun record che corrisponda al nome di dominio e al tipo nella richiesta, VPC Resolver non inoltra la richiesta a un resolver DNS pubblico. Al contrario, restituisce NXDOMAIN (dominio inesistente) al client. **Zone ospitate pubbliche e private con spazi dei nomi sovrapposti** Se disponi di due o più zone ospitate private con namespace sovrapposti, ad esempio example.com e accounting.example.com, VPC Resolver indirizza il traffico in base alla corrispondenza più specifica. Se hai una zona ospitata privata (example.com) e una regola VPC Resolver Route 53 che indirizza il traffico verso la tua rete per lo stesso nome di dominio, la regola VPC Resolver ha la precedenza. Per informazioni, consulta [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules). Quando gli utenti accedono a un'istanza EC2 in un Amazon VPC che hai associato a tutte le zone private ospitate, ecco come VPC Resolver gestisce le query DNS: 1. VPC Resolver valuta se il nome di dominio nella richiesta, ad esempio accounting.example.com, corrisponde al nome di una delle zone ospitate private. 1. Se non esiste una zona ospitata che corrisponda esattamente al nome di dominio nella richiesta, VPC Resolver verifica la presenza di una zona ospitata con un nome che sia il padre del nome di dominio nella richiesta. Ad esempio, supponiamo che il nome di dominio della richiesta sia il seguente: `seattle.accounting.example.com` Le seguenti zone ospitate corrispondono perché sono elementi padre di `seattle.accounting.example.com`: + `accounting.example.com` + `example.com` VPC Resolver sceglie `accounting.example.com` perché è più specifico di. `example.com` 1. VPC Resolver cerca nella zona `accounting.example.com` ospitata un record che corrisponda al nome di dominio e al tipo DNS nella richiesta, ad esempio un record A per. `seattle.accounting.example.com` Se non esiste alcun record che corrisponda al nome di dominio e al tipo nella richiesta, VPC Resolver restituisce NXDOMAIN (dominio inesistente) al client. **Zone ospitate private e regole VPC Resolver di Route 53** Se hai una zona ospitata privata (example.com) e una regola VPC Resolver che indirizza il traffico verso la tua rete per lo stesso nome di dominio, la regola VPC Resolver ha la precedenza. Si prenda come esempio la seguente configurazione: + Hai una zona ospitata privata denominata example.com che associ a un VPC. + Crei una regola Route 53 VPC Resolver che inoltra il traffico di example.com alla tua rete e associ la regola allo stesso VPC. In questa configurazione, la regola VPC Resolver ha la precedenza sulla zona ospitata privata. Le query DNS vengono inoltrate alla rete anziché risolte in base ai record nella zona ospitata privata. **Delegare responsabilità per un sottodominio** Ora puoi creare record NS in una zona ospitata privata per delegare la responsabilità di un sottodominio. Per ulteriori informazioni, consulta [Tutorial sulle regole di delega del Resolver](outbound-delegation-tutorial.md). **Server DNS personalizzati** Se hai configurato server DNS personalizzati su istanze Amazon EC2 nel VPC, dovrai configurare i server DNS in modo da instradare le query DNS private all'indirizzo IP dei server DNS forniti da Amazon per il tuo VPC. Questo indirizzo IP è l'indirizzo IP alla base dell'intervallo di rete VPC "più due". Ad esempio, se l'intervallo di CIDR per il tuo VPC è 10.0.0.0/16, l'indirizzo IP del server DNS è 10.0.0.2. Se desideri instradare le query DNS tra VPCs e la tua rete, puoi utilizzare VPC Resolver. Per ulteriori informazioni, consulta [Cos'è Route 53 VPC Resolver?](resolver.md). **Autorizzazioni IAM richieste** Per creare zone ospitate private, devi concedere le autorizzazioni IAM per le operazioni Amazon EC2 in aggiunta alle autorizzazioni per le operazioni Route 53. Per ulteriori informazioni, consulta [Operazioni, risorse e chiavi di condizione per Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) in *Service Authorization Reference*. # Creazione di una zona ospitata privata Una zona ospitata privata è un contenitore per i record di un dominio ospitato in uno o più cloud privati virtuali Amazon (VPCs). Crei una zona ospitata per un dominio (ad esempio example.com), quindi crei record per indicare ad Amazon Route 53 come desideri che il traffico venga instradato per quel dominio all'interno e tra i tuoi. VPCs **Importante** Quando crei una zona ospitata privata, devi associare un VPC alla zona ospitata e il VPC specificato deve essere stato creato utilizzando lo stesso account che utilizzi per creare la zona ospitata. Dopo aver creato la zona ospitata, puoi associarne altri VPCs , inclusa VPCs quella creata utilizzando un account diverso. AWS Per associare VPCs quella creata utilizzando un account a una zona ospitata privata creata utilizzando un account diverso, è necessario autorizzare l'associazione e quindi creare l'associazione a livello di codice. Per ulteriori informazioni, consulta [Associazione di un Amazon VPC e una zona ospitata privata creata con account diversi AWS](hosted-zone-private-associate-vpcs-different-accounts.md). Per informazioni su come creare una zona ospitata privata tramite l'API Route 53, consulta la [Documentazione di riferimento delle API di Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/). **Come creare una zona ospitata privata tramite la console Route 53** 1. Per ogni VPC che desideri associare alla zona ospitata di Route 53, modifica le seguenti impostazioni di VPC in `true`: + `enableDnsHostnames` + `enableDnsSupport` Per ulteriori informazioni, consultare [Aggiornamento del supporto DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) nella *Guida per l'utente di Amazon VPC*. 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. I nuovi utenti di Route 53 possono consultare **Nozioni di base**. Se stai già utilizzando Route 53, scegli **Zone ospitate** nel pannello di navigazione. 1. Scegli **Crea zona ospitata**. 1. Nel riquadro **Crea zona ospitata privata**, inserisci un nome di dominio e, facoltativamente, un commento. Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). 1. Nell'elenco **Tipo**, scegli **Zona ospitata privata**. 1. Nell'elenco **VPC ID (ID VPC)**, scegli il VPC che desideri associare alla zona ospitata. **Nota** Se la console mostra il seguente messaggio, stai tentando di associare una zona ospitata che utilizza lo stesso spazio dei nomi di quello di un'altra zona ospitata all'interno dello stesso VPC: "Un dominio in conflitto è già associato a un determinato VPC o set di delega". Ad esempio, se la zona ospitata A e la zona ospitata B utilizzano entrambi lo stesso nome di dominio, come `example.com`, non è possibile associare entrambe le zone ospitate allo stesso VPC. 1. Scegli **Crea zona ospitata**. # Elencare zone ospitate private Puoi utilizzare la console Amazon Route 53 per elencare tutte le zone ospitate che hai creato con l' AWS account corrente. Per informazioni su come elencare le zone ospitate utilizzando l'API Route 53, [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)consulta *Amazon Route 53 API Reference*. **Per elencare le zone ospitate associate a un AWS account** 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**. La pagina **Hosted Zones** mostra automaticamente un elenco di tutte le zone ospitate che sono state create utilizzando l' AWS account corrente. La colonna **Type (Tipo)** indica se una zona ospitata è privata o pubblica. Scegli l'intestazione di colonna per raggruppare tutte le zone ospitate private e pubbliche. # Associarne di più VPCs a una zona ospitata privata Puoi utilizzare la console Amazon Route 53 per VPCs associare altre informazioni a una zona ospitata privata se hai creato la zona ospitata e VPCs poi utilizzando lo stesso AWS account. **Importante** Se desideri associare VPCs ciò che hai creato utilizzando un account a una zona ospitata privata creata utilizzando un account diverso, devi prima autorizzare l'associazione. Inoltre, non è possibile utilizzare la AWS console per autorizzare l'associazione o associarla alla zona VPCs ospitata. Per ulteriori informazioni, consulta [Associazione di un Amazon VPC e una zona ospitata privata creata con account diversi AWS](hosted-zone-private-associate-vpcs-different-accounts.md). Per informazioni su come associare di più VPCs a una zona ospitata privata utilizzando l'API Route 53, consulta [Associate VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) nel *riferimento all'API di Amazon Route 53*. **Per associarne altre VPCs a una zona ospitata privata utilizzando la console Route 53** 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**. 1. Scegli il pulsante di opzione per la zona ospitata privata a cui desideri associarti di più VPCs . 1. Scegli **Modifica**. 1. Scegli **Aggiungi VPC**. 1. Scegli la regione e l'ID del VPC che desideri associare alla zona ospitata. 1. Per VPCs associare altre informazioni a questa zona ospitata, ripeti i passaggi 5 e 6. 1. Scegli **Save changes** (Salva modifiche). # Associazione di un Amazon VPC e una zona ospitata privata creata con account diversi AWS Se desideri associare un VPC creato con un AWS account a una zona ospitata privata creata con un account diverso, esegui la seguente procedura: **Per associare un Amazon VPC e una zona ospitata privata creata con account diversi AWS** 1. Utilizzando l'account che ha creato la zona ospitata, autorizza l'associazione del VPC con la zona ospitata privata utilizzando uno dei seguenti metodi: + **AWS CLI**— Vedi [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)nel riferimento ai *AWS CLI comandi* + ** AWS SDK** o **AWS Tools for Windows PowerShell**: consulta la documentazione applicabile nella pagina [AWS Documentazione](https://docs.aws.amazon.com/) + **API Amazon Route 53**: consulta [Create VPCAssociation Authorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) nel *riferimento all'API Amazon Route 53* Tenere presente quanto segue: + Se desideri associare più VPCs account creati con un account a una zona ospitata creata con un account diverso, devi inviare una richiesta di autorizzazione per ogni VPC. + Quando autorizzi l'associazione, devi specificare l'ID della zona ospitata, perciò la zona ospitata privata deve esistere già. + Non puoi utilizzare la console Route 53 per autorizzare l'associazione di un VPC con una zona ospitata privata o per effettuare l'associazione. 1. Utilizzando l'account che ha creato il VPC, associa il VPC alla zona ospitata. Oltre all'autorizzazione dell'associazione, puoi utilizzare l' AWS SDK, Tools for Windows PowerShell o l'API AWS CLI Route 53. Se utilizzi l'API, utilizza l'azione [Associa VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html). 1. *Consigliato*: elimina l'autorizzazione per associare il VPC alla zona ospitata. L'eliminazione di un'autorizzazione non interessa l'associazione, ma semplicemente impedisce la nuova associazione del VPC con la zona ospitata in futuro. Se desideri riassociare il VPC alla zona ospitata, devi ripetere i passaggi 1 e 2 di questa procedura. **Importante** `ListHostedZonesByVPC`restituisce le zone ospitate fornite da un VPC e l'`GetHostedZone`API restituisce la zona VPCs associata alla zona ospitata. Questi considerano APIs solo l'associazione tra zona ospitata e VPC creata dall'`AssociateVPCWithHostedZone`API o quando viene creata la zona ospitata privata. Se desideri un elenco completo delle associazioni di zone ospitate su un VPC, chiama anche. [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html) **Nota** Per il numero massimo di autorizzazioni che puoi creare, consulta [Quote relative alle entità](DNSLimitations.md#limits-api-entities). # Dissociarsi VPCs da una zona ospitata privata Puoi utilizzare la console Amazon Route 53 per dissociarti VPCs da una zona ospitata privata. In questo modo Route 53 causa l'arresto del traffico di routing utilizzando i record nella zona ospitata per le query DNS originate nel VPC. Ad esempio, se la zona ospitata esempio.com è associata a un VPC e la si dissocia da tale VPC, Route 53 interrompe la risoluzione delle query DNS per esempio.com o uno qualsiasi degli altri record nella zona ospitata esempio.com. **Nota** Non è possibile disassociare l'ultimo VPC da una zona privata ospitata. Se si desidera dissociare tale VPC, è innanzitutto necessario associare un altro VPC alla zona ospitata. **Per dissociarsi VPCs da una zona ospitata privata** 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**. 1. Scegli il pulsante di opzione per la zona ospitata privata da cui desideri dissociarti VPCs da una o più zone. 1. Scegli **Modifica**. 1. Scegli **Rimuovi VPC** accanto al VPC che desideri dissociare da questa zona ospitata. 1. Scegli **Save changes** (Salva modifiche). # Eliminazione di una zona ospitata privata In questa sezione viene spiegato come eliminare una zona ospitata privata utilizzando la console Amazon Route 53. Puoi eliminare una zona ospitata privata solo se non sono presenti record diversi dai record SOA e NS di default. Se la tua zona ospitata contiene altri record, devi eliminarli prima di eliminare la zona ospitata. In questo modo si impedisce l'eliminazione accidentale di una zona ospitata che contiene ancora record. **Topics** + [Eliminazione di zone ospitate private create da un altro servizio](#delete-private-hosted-zone-created-by-another-service) + [Utilizzo della console di Route 53 per eliminare una zona ospitata privata](#delete-private-hosted-zone-procedure) ## Eliminazione di zone ospitate private create da un altro servizio Se una zona ospitata privata è stata creata da un altro servizio, non sarà possibile eliminarla mediante la console Route 53. Al contrario, è necessario utilizzare il processo applicabile all'altro servizio: + **AWS Cloud Map**— Per eliminare una zona ospitata AWS Cloud Map creata quando hai creato uno spazio dei nomi DNS privato, elimina lo spazio dei nomi. AWS Cloud Map elimina automaticamente la zona ospitata. Per ulteriori informazioni, consulta [Eliminazione degli spazi dei nomi](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) nella *Guida per gli sviluppatori di AWS Cloud Map *. + **Rilevamento del servizio Amazon Elastic Container Service (Amazon ECS)**: per eliminare una zona ospitata privata creata da Amazon ECS quando hai creato un servizio utilizzando l'individuazione dei servizi, eliminare i servizi Amazon ECS che utilizzano lo spazio dei nomi ed eliminare lo spazio dei nomi. Per ulteriori informazioni, consulta [Eliminazione di un servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) nella *Guida per gli sviluppatori di Amazon Elastic Container Service*. ## Utilizzo della console di Route 53 per eliminare una zona ospitata privata Per utilizzare la console Route 53 per eliminare una zona ospitata privata, completa la procedura seguente. **Utilizzo della console di Route 53 per eliminare una zona ospitata privata** 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. Conferma che la zona ospitata che desideri eliminare contiene solo un record NS e un record SOA. Se contiene record aggiuntivi, eliminali: 1. Seleziona il nome della zona ospitata che desideri eliminare. 1. Nella pagina **Record**, se l'elenco dei record include i record per i quali il valore della colonna **Tipo** è diverso da **NS** o **SOA**, scegli la riga, quindi seleziona **Elimina**. Per selezionare più record consecutivi, seleziona la prima riga, tieni premuto il tasto **Shift (MAIUSC)** e seleziona l'ultima riga. Per selezionare più record non consecutivi, seleziona la prima riga, tieni premuto il tasto **Ctrl** e seleziona le righe rimanenti. 1. Nella pagina Hosted zone, scegli la riga per la zona ospitata che desideri eliminare. 1. Scegli **Elimina**. 1. Digita la chiave di conferma e scegli **Elimina**. # Autorizzazioni VPC [https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html) APIs Con la condizione della policy IAM`route53:VPCs`, puoi concedere diritti amministrativi granulari ad altri utenti. AWS Ciò consente di concedere a qualcuno le autorizzazioni per associare una zona ospitata, dissociare dalla zona ospitata, creare l'autorizzazione di associazione VPC per, eliminare l'autorizzazione all'associazione VPC per, creare una zona ospitata o elencare le zone ospitate per: + Un singolo VPC. + Qualsiasi VPCs all'interno della stessa regione. + Multiplo VPCs. Per ulteriori informazioni sulle autorizzazioni VPC, consulta. [Utilizzo di condizioni di policy IAM per il controllo granulare degli accessi](specifying-conditions-route53.md) Per informazioni su come autenticare AWS gli utenti, vedi [Autenticazione con identità](security-iam.md#security_iam_authentication) e per sapere come controllare l'accesso alle risorse di Route 53, vedi. [Controllo accessi](security-iam.md#access-control) # Migrazione di una zona ospitata su un altro account AWS Quando migri una zona ospitata verso un'altra Account AWS, segui questi passaggi consigliati. Questi passaggi sono più adatti per le zone ospitate con modifiche ai record poco frequenti. Per le zone ospitate con frequenti aggiornamenti dei record, considerate quanto segue: + Non aggiornate alcun record di risorse durante la migrazione. + Pubblica le modifiche ai record di risorse nelle vecchie e nuove zone ospitate dopo il trasferimento della delega. **Prerequisiti** Installa o aggiorna AWS CLI: Per informazioni sul download, l'installazione e la configurazione di AWS CLI, consulta la [Guida per l'AWS Command Line Interface utente](https://docs.aws.amazon.com/cli/latest/userguide/). **Nota** Configura la CLI in modo che sia possibile utilizzarla quando stai utilizzando sia l'account che ha creato la zona ospitata sia l'account su cui stai migrando la zona ospitata. Per ulteriori informazioni, consulta [Configurazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) nella *Guida per l'utente di AWS Command Line Interface *. Se stai già utilizzando AWS CLI, ti consigliamo di eseguire l'aggiornamento alla versione più recente della CLI in modo che i comandi CLI supportino le funzionalità più recenti di Route 53. **Topics** + [Fase 1: Preparazione per la migrazione](#hosted-zones-migrating-prepare) + [Fase 2: crea una nuova zona ospitata](#hosted-zones-migrating-create-hosted-zone) + [Fase 3: (Facoltativo) Migrazione dei controlli sanitari](#hosted-zones-migrating-health-checks) + [Fase 4: Migrazione dei record dalla vecchia zona ospitata alla nuova zona ospitata](#hosted-zones-migrating-old-to-new) + [Passaggio 5: Confronta i record nella vecchia e nella nuova zona ospitata](#hosted-zones-migrating-compare) + [Passaggio 6: Aggiornare la registrazione del dominio per utilizzare i name server per la nuova zona ospitata](#hosted-zones-migrating-update-domain) + [Passaggio 7: riportare il TTL per il record NS a un valore più alto](#hosted-zones-migrating-change-ttl) + [Passaggio 8: riattiva la firma DNSSEC e stabilisci la catena di fiducia (se necessario)](#hosted-zones-migrating-enable-dnssec) + [Passaggio 9: (Facoltativo) eliminare la vecchia zona ospitata](#hosted-zones-migrating-delete-old-hosted-zone) ## Fase 1: Preparazione per la migrazione Le fasi di preparazione aiutano a ridurre al minimo i rischi associati alla migrazione di una zona ospitata. **1. Monitora la disponibilità delle zone** È possibile monitorare la zona per verificare la disponibilità dei nomi di dominio. Questo può aiutarti a risolvere eventuali problemi che potrebbero portare a ripristinare la migrazione. Puoi monitorare i nomi di dominio con la maggior parte del traffico utilizzando CloudWatch 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 è necessario un rollback, poiché potresti anche ricevere feedback dai tuoi clienti a causa della mancata disponibilità di un dominio. **2. Abbassa l'impostazione TTL** L'impostazione TTL (time-to-live) per un record consente di specificare il periodo di tempo per cui desideri che il resolver DNS memorizzi nella cache i record e utilizzi le informazioni memorizzate nella cache. Quando il TTL scade, un resolver invia un'altra query al fornitore di servizi DNS per un dominio per ottenere le informazioni più recenti. L'impostazione TTL tipica per il record NS è 172800 secondi, o due giorni. Il record NS elenca i server dei nomi che il Domain Name System (DNS) può utilizzare per ottenere informazioni su come instradare il traffico per il tuo dominio. La riduzione del TTL per il record NS, sia con il tuo attuale provider di servizi DNS che con Route 53, riduce i tempi di inattività del dominio se scopri un problema durante la migrazione del DNS a Route 53. Se non riduci il TTL, il tuo dominio potrebbe essere non disponibile su Internet per un massimo di due giorni in caso di problemi. **Per abbassare il TTL** 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. Scegli **Zone ospitate** nel pannello di navigazione. 1. Scegli il nome della zona ospitata. 1. Scegli il record NS e, nel riquadro **Dettagli del record**, scegli **Modifica record**. 1. Modifica il valore di **TTL (secondi)**. È consigliabile specificare un valore compreso tra 60 secondi e 900 secondi (15 minuti). 1. Scegli **Save** (Salva). **3. Rimuovi il record DS dalla zona principale (se hai configurato DNSSEC)** Se hai configurato DNSSEC per il dominio, prima di eseguire la migrazione del dominio a Route 53 rimuovi il record Delegation Signer (DS) dalla zona padre. Se la zona principale è ospitata tramite Route 53, consulta [Eliminazione di chiavi pubbliche per un dominio](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) per ulteriori informazioni. Se la zona principale è ospitata su un altro registrar, contattalo per rimuovere il record DS. Route 53 attualmente non supporta la migrazione dell'impostazione DNSSEC. Pertanto, dovrai disabilitare la convalida DNSSEC eseguita sul tuo dominio prima della migrazione rimuovendo il record DS dalla zona principale. Dopo la migrazione, puoi riattivare la convalida DNSSEC configurando DNSSEC sulla nuova zona ospitata e aggiungendo il rispettivo record DS alla zona principale. **4. Assicurati che non vi siano altre operazioni in corso che si basano sulla zona ospitata in migrazione** Alcune operazioni si baseranno sulla risoluzione DNS nella zona ospitata in migrazione, ad esempio, il processo di rinnovo del TLS/SSL certificato potrebbe richiedere la modifica dei record DNS e il provider cercherà di risolvere il record DNS come metodo di convalida. Prima della migrazione, è necessario assicurarsi che non siano in corso altre operazioni, al fine di evitare un impatto imprevisto della migrazione della zona ospitata. ## Fase 2: crea una nuova zona ospitata Crea la nuova zona ospitata nell'account verso cui desideri migrare la zona ospitata. Scegli la scheda per le istruzioni per la console AWS CLI o. + [CLI](#migrate-hz-cli) + [Console](#migrate-hz-console) ------ #### [ CLI ] Immetti il comando seguente: ``` aws route53 create-hosted-zone \ --name $hosted_zone_name \ --caller-reference $unique_string ``` Per ulteriori informazioni, consulta [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html). ------ #### [ Console ] **Per creare la nuova zona ospitata utilizzando un account diverso** 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/). Accedi con le credenziali dell'account per l'account su cui desideri migrare la zona ospitata. 1. Crea una zona ospitata. Per ulteriori informazioni, consulta [Creazione di una zona ospitata pubblica](CreatingHostedZone.md). 1. Annota l'ID della zona ospitata. In alcuni casi, avrai bisogno di queste informazioni in un secondo momento. 1. Esci dalla console Route 53. Abbassa il TTL NS anche nella nuova zona, analogamente all'impostazione Lower TTL in preparazione. Fase 1, Abbassa l'impostazione TTL. ------ ## Fase 3: (Facoltativo) Migrazione dei controlli sanitari Puoi associare i record DNS del nuovo account ai controlli di integrità di Route 53 dall'account da cui stai effettuando la migrazione. Per migrare un controllo dello stato di Route 53, devi creare nuovi controlli di integrità nel tuo nuovo account con la stessa configurazione di quelli esistenti. Per ulteriori informazioni, consulta [Creazione di controlli sanitari su Amazon Route 53](dns-failover.md). ## Fase 4: Migrazione dei record dalla vecchia zona ospitata alla nuova zona ospitata È possibile migrare i record da un file Account AWS all'altro utilizzando la console o il. AWS CLI ------ #### [ Console ] Se la zona contiene solo pochi record, si può prendere in considerazione l'utilizzo della console Route 53 per elencare i record nella vecchia zona, annotarli e crearli nella nuova zona. Se hai migrato il check-in sanitario[Fase 3: (Facoltativo) Migrazione dei controlli sanitari](#hosted-zones-migrating-health-checks), quando crei i record nella nuova zona ospitata, devi specificare il nuovo ID del controllo sanitario. Per ulteriori informazioni, consulta i seguenti argomenti: + [Elencazione di record](resource-record-sets-listing.md) + [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md) + [Configurazione di un failover DNS](dns-failover-configuring.md) È necessario abbassare il TTL NS anche nella nuova zona, in modo simile all'impostazione Lower TTL nel passaggio 1. ------ #### [ CLI ] Se la zona contiene un numero elevato di record, è possibile esportare i record che si desidera migrare in un file, modificare il file e quindi utilizzare il file modificato per creare record nella nuova zona ospitata. La procedura seguente utilizza i comandi AWS CLI, sebbene a questo scopo siano disponibili anche strumenti di terze parti. **** 1. Esegui il comando seguente: ``` aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file ``` Tenere presente quanto segue: + Per*hosted-zone-id*, specifica l'ID della vecchia zona ospitata che contiene i record che desideri migrare. + Per*path-to-output-file*, specifica il percorso della directory e il nome del file in cui vuoi salvare l'output. + Il carattere `>` invia l'output al file specificato. + Gestisce AWS CLI automaticamente l'impaginazione per le zone ospitate che contengono più di 100 record. Per ulteriori informazioni, vedere [Utilizzo delle opzioni di impaginazione dell'interfaccia a riga di AWS comando nella Guida per](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html) l'*AWS Command Line Interface utente*. Se si utilizza un altro metodo programmatico per elencare i record, ad esempio uno dei seguenti AWS SDKs, è possibile ottenere un massimo di 100 record per pagina di risultati. Se la zona ospitata contiene più di 100 record, è necessario inviare più richieste per elencare tutti i record. Creare una copia di questo output. Dopo aver creato i record nella nuova zona ospitata, è consigliabile eseguire il AWS CLI `list-resource-record-sets` comando sulla nuova zona ospitata e confrontare i due output per assicurarsi che tutti i record siano stati creati. 1. Modifica i record che desideri migrare. Modifica il file esportato prima di poterlo utilizzare con il `change-resource-record-sets` comando. È possibile apportare queste modifiche utilizzando la funzione di ricerca e sostituzione in un editor di testo. **Nota** I passaggi seguenti descrivono la modifica manuale utilizzando un editor di testo. Gli utenti esperti possono automatizzare queste trasformazioni utilizzando strumenti programmatici come jq, Python o altri linguaggi di scripting. Apri una copia del file creato nel passaggio 1 di questa procedura che contiene i record che desideri migrare e apporta le seguenti modifiche: + Sostituisci l' ResourceRecordSets elemento nella parte superiore del file con `Changes` element. + Facoltativo: aggiungi un `Comment` elemento. + Elimina le righe relative ai record NS e SOA del nome della zona ospitata. La nuova zona ospitata dispone già di tali record. + Per ogni record, aggiungi un elemento `Action` e un `ResourceRecordSets` elemento, aggiungi le parentesi di apertura e chiusura (`{ }`) come richiesto per rendere valido il codice JSON. **Nota** È possibile usare un validatore JSON per verificare che tutte le graffe e le parentesi siano nella posizione corretta. Per trovare un validatore JSON online, cerca «validatore JSON» nel tuo browser. + Se la zona ospitata contiene eventuali alias che fanno riferimento ad altri record nella stessa zona ospitata, apportare le modifiche seguenti: + Cambiare l'ID della zona ospitata con l'ID della nuova zona ospitata. **Importante** Se il record di alias punta a un'altra risorsa, ad esempio un sistema di bilanciamento del carico, non modificare l'ID della zona ospitata con l'ID della zona ospitata del dominio. Se modifichi accidentalmente l'ID della zona ospitata, ripristina l'ID della zona ospitata sull'ID della zona ospitata della risorsa stessa, non sull'ID della zona ospitata del dominio. L'ID della zona ospitata dalla risorsa è disponibile nella AWS console in cui è stata creata la risorsa. + Sposta i record alias alla fine del file. Prima di poter creare il record alias, Route 53 deve creare il record a cui un record alias fa riferimento. **Importante** Se uno o più record alias fanno riferimento ad altri record alias, i record che rappresentano la destinazione di alias devono comparire nel file prima dei record alias di riferimento. Ad esempio, se `alias.example.com` è l'alias di destinazione per `alias.alias.example.com`, `alias.example.com` deve apparire primo nel file. + Eliminare i record alias che instradano il traffico verso un'istanza di policy di traffico. Annotare i record in modo da ricrearli più tardi. + Se hai effettuato la migrazione dei controlli sanitari[Fase 3: (Facoltativo) Migrazione dei controlli sanitari](#hosted-zones-migrating-health-checks), modifica i record per associarli al controllo IDs sanitario appena creato. L'esempio seguente mostra la versione modificata dei record per una zona ospitata per esempio.com. Il testo rosso in corsivo è nuovo: ``` { "Comment": "string", "Changes": [ { "Action": "CREATE", "ResourceRecordSet":{ "ResourceRecords": [ { "Value": "192.0.2.4" }, { "Value": "192.0.2.5" }, { "Value": "192.0.2.6" } ], "Type": "A", "Name": "route53documentation.com.", "TTL": 300 } }, { "Action": "CREATE", "ResourceRecordSet":{ "AliasTarget": { "HostedZoneId": "Z3BJ6K6RIION7M", "EvaluateTargetHealth": false, "DNSName": "s3-website-us-west-2.amazonaws.com." }, "Type": "A", "Name": "www.route53documentation.com." } } ] } ``` 1. Dividi file di grandi dimensioni in file più piccoli Se si dispone di una notevole quantità di record o se si dispone di record che hanno molti valori (ad esempio, molti indirizzi IP), potrebbe essere necessario suddividere il file in file più piccoli. I valori massimi sono: + Ogni file può contenere un massimo di 1.000 record. + La lunghezza combinata massima dei valori di tutti gli elementi `Value` è 32.000 byte. 1. Crea record nella nuova zona ospitata Inserisci la seguente CLI: ``` aws route53 change-resource-record-sets \ --hosted-zone-id new-hosted-zone-id \ --change-batch file://path-to-file-that-contains-records ``` Specifica i seguenti valori: + Per`new-hosted-zone-id`, specifica l'ID della nuova zona ospitata. + Per`path-to-file-that-contains-records`, specifica il percorso della directory e il nome del file che hai modificato nei passaggi precedenti. Se hai eliminato alcun record alias che instradano il traffico verso un'istanza di policy di traffico, crearli nuovamente utilizzando la console Route 53. Per ulteriori informazioni, consulta [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md). ------ ## Passaggio 5: Confronta i record nella vecchia e nella nuova zona ospitata Per confermare di aver creato correttamente tutti i record nella nuova zona ospitata, immettete il seguente comando CLI per elencare i record nella nuova zona ospitata e confrontare l'output con l'elenco dei record della vecchia zona ospitata. ``` aws route53 list-resource-record-sets \ --hosted-zone-id new-hosted-zone-id \ --output json > path-to-output-file ``` Specifica i seguenti valori: + Per`new-hosted-zone-id`, specifica l'ID della nuova zona ospitata. + Per`path-to-output-file`, specifica il percorso della directory e il nome del file in cui vuoi salvare l'output. Utilizzate un nome di file diverso dal nome di file utilizzato nel passaggio 4. Il carattere `>` invia l'output al file specificato. Confrontate l'output con quello del passaggio 4. Oltre ai valori dei record NS e SOA e alle eventuali modifiche apportate nella Fase 4 (ad esempio zone ospitate IDs o nomi di dominio diversi), i due output devono essere identici. Se i record nella nuova zona ospitata non corrispondono ai record della vecchia zona ospitata, esegui una delle seguenti operazioni: + Effettuare correzioni minori utilizzando la console Route 53. Per ulteriori informazioni, consulta [Modifica di record](resource-record-sets-editing.md). + Eliminare tutti i record tranne i record NS e SOA nella nuova zona ospitata e ripetere la procedura nel passaggio 4. ## Passaggio 6: Aggiornare la registrazione del dominio per utilizzare i name server per la nuova zona ospitata Al termine della migrazione dei record nella nuova zona ospitata, modifica i name server per la registrazione del dominio in modo da utilizzare i name server per la nuova zona ospitata. Per ulteriori informazioni, consulta Making Amazon Route 53 come servizio DNS per un dominio esistente. Se la zona ospitata è in uso, ad esempio se gli utenti utilizzano il nome di dominio per navigare su un sito Web o accedere a un'applicazione Web, è necessario continuare a monitorare il traffico e la disponibilità della zona ospitata, incluso il traffico di siti Web o applicazioni, e-mail, ecc. + **Se il traffico rallenta o si interrompe**, riporta il name service per la registrazione del dominio ai nameserver precedenti della vecchia zona ospitata. Stabilisci quindi ciò che non ha funzionato. + **Se il traffico non è influenzato**, continua con il passaggio successivo. ## Passaggio 7: riportare il TTL per il record NS a un valore più alto Nella nuova zona ospitata, modifica il TTL per il record NS con un valore più tipico, ad esempio 172800 secondi (due giorni). Questo migliora la latenza per gli utenti, perché non dovranno aspettare, come spesso accade per resolver DNS, per inviare una query per i server dei nomi per il tuo dominio. **Per modificare il TTL** 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. Scegli **Zone ospitate** nel pannello di navigazione. 1. Scegli il nome della zona ospitata. 1. Scegli il record NS e, nel riquadro **Dettagli del record**, scegli **Modifica record**. 1. Modifica il valore di **TTL (secondi) impostando** il numero di secondi in cui desideri che i resolver DNS memorizzino nella cache i nomi dei name server del tuo dominio. Consigliamo un valore di 172800 secondi. 1. Scegli **Save** (Salva). ## Passaggio 8: riattiva la firma DNSSEC e stabilisci la catena di fiducia (se necessario) Puoi riattivare la firma DNSSEC in due passaggi: 1. Abilita la firma DNSSEC per Route 53 e richiedi che Route 53 crei una chiave di firma delle chiavi (KSK) basata su una chiave gestita dal cliente. AWS Key Management Service 1. Crea una catena di fiducia per la zona ospitata aggiungendo un record Delegation Signer (DS) alla zona principale, in modo che le risposte DNS possano essere autenticate con firme crittografiche affidabili. Per istruzioni, consulta [Abilitazione della firma DNSSEC e creazione di una catena di attendibilità](dns-configuring-dnssec-enable-signing.md). ## Passaggio 9: (Facoltativo) eliminare la vecchia zona ospitata Quando si è certi che la vecchia zona ospitata non è più necessaria più, è possibile facoltativamente eliminarla. Per istruzioni, consulta [Eliminazione di una zona ospitata pubblica](DeleteHostedZone.md). **Importante** Non eliminare la vecchia zona ospitata o qualsiasi record in quella zona ospitata per almeno 48 ore dopo l'aggiornamento della registrazione del dominio in modo che utilizzi i server di nomi per la nuova zona ospitata. Se si cancella la vecchia zona ospitata prima che i resolver DNS interrompano l'utilizzo dei record in quella zona ospitata, il dominio potrebbe essere non disponibile su Internet finché i resolver non iniziano a usare la nuova zona ospitata. # Utilizzo dei record Dopo aver creato una zona ospitata per il tuo dominio (come esempio.com), quindi crea record per indicare al Domain Name System (DNS) come desideri instradare il traffico su Internet per quel dominio. Ad esempio, puoi creare record che fanno in modo che il DNS effettui le seguenti azioni: + Instradare il traffico Internet per esempio.com all'indirizzo IP di un host nel tuo data center. + Instradare le e-mail per quel dominio (ichiro@esempio.com) a un server e-mail (mail.esempio.com). + Instradare il traffico per un sottodominio chiamato operations.tokyo.esempio.com all'indirizzo IP di un altro host. Ogni record include il nome di un dominio o sottodominio, un tipo di record (ad esempio, un record con un tipo di MX instrada le e-mail) e altre informazioni applicabili al tipo di record (per i record MX, il nome host di uno o più server di posta e una priorità per ogni server). Per ulteriori informazioni sui diversi tipi di record, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Il nome di ciascun record in una zona ospitata deve terminare con il nome della zona ospitata. Ad esempio, la zona ospitata esempio.com può contenere record per i sottodomini www.esempio.com e accounting.tokyo.esempio.com, ma non può contenere record per un sottodominio www.esempio.ca. **Nota** Per creare record per configurazioni di routing complesse, puoi anche utilizzare l'editor visivo Traffic Flow e salvare la configurazione come policy sul traffico. Puoi quindi associare la policy di traffico a uno o più nomi di dominio (ad esempio esempio.com) o nomi di sottodominio (ad esempio www.esempio.com), nella stessa zona ospitata o in più zone ospitate. Inoltre, puoi eseguire il roll back degli aggiornamenti se la nuova configurazione non offre le prestazioni previste. Per ulteriori informazioni, consulta [Utilizzo di Traffic Flow per instradare il traffico DNS](traffic-flow.md). Amazon Route 53 non prevede costi per i record che aggiungi a una zona ospitata. Per informazioni sul numero massimo di record che puoi creare in una zona ospitata, consulta [Quote](DNSLimitations.md). **Topics** + [Scegliere una policy di routing](routing-policy.md) + [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md) + [Tipi di record DNS supportati](ResourceRecordTypes.md) + [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md) + [Autorizzazioni del set di record di risorse](resource-record-sets-permissions.md) + [Di seguito sono descritti i valori che devi specificare durante la creazione o la modifica di record di Amazon Route 53.](resource-record-sets-values.md) + [Creazione di record mediante importazione di un file di zona](resource-record-sets-creating-import.md) + [Modifica di record](resource-record-sets-editing.md) + [Eliminazione di record](resource-record-sets-deleting.md) + [Elencazione di record](resource-record-sets-listing.md) # Scegliere una policy di routing Quando crei un record, puoi scegliere una policy di routing che determina come Amazon Route 53 risponde alle query: + **Policy di routing semplice**: utilizza questa opzione per una singola risorsa che esegue una determinata funzione per il tuo dominio, ad esempio un server Web che fornisce i contenuti per il sito Web esempio.com. Puoi utilizzare un routing semplice per creare i record in una zona ospitata privata. + **Policy di routing di failover**: utilizza questa opzione se desideri configurare un failover attivo-passivo. Puoi utilizzare il routing di failover per creare i record in una zona ospitata privata. + **Policy di routing di geolocalizzazione**: utilizza questa opzione se desideri instradare il traffico alle tue risorse in base alla posizione degli utenti. Puoi utilizzare il routing di geolocalizzazione per creare i record in una zona ospitata privata. + **Policy di routing di geoprossimità**: utilizza questa opzione se desideri instradare il traffico in base alla posizione delle tue risorse e, facoltativamente, spostare il traffico dalle risorse in una posizione alle risorse in un'altra posizione. È possibile utilizzare il routing di geoprossimità per creare record in una zona ospitata privata. + **Politica di routing della latenza**: utilizzala quando hai più risorse Regioni AWS e desideri indirizzare il traffico verso la regione che offre la latenza migliore. Puoi utilizzare il routing della latenza per creare i record in una zona ospitata privata. + **Policy di routing basato su IP**: utilizza questa opzione quando desideri instradare il traffico in base alle posizioni degli utenti e disporre degli indirizzi IP da cui proviene il traffico. + **Policy di routing con risposta multivalore**: utilizza questa opzione se desideri che Route 53 risponda alle query DNS con un massimo di otto record integri selezionati casualmente. Puoi utilizzare il routing di risposta multivalore per creare i record in una zona ospitata privata. + **Policy di routing ponderata**: utilizza questa opzione se desideri instradare il traffico a più risorse nelle proporzioni specificate. Puoi utilizzare il routing ponderato per creare i record in una zona ospitata privata. **Topics** + [Routing semplice](routing-policy-simple.md) + [Routing di failover](routing-policy-failover.md) + [Routing di geolocalizzazione](routing-policy-geo.md) + [Geoproximity routing](routing-policy-geoproximity.md) + [Routing basato sulla latenza](routing-policy-latency.md) + [Routing basato su IP](routing-policy-ipbased.md) + [Routing di risposta multivalore](routing-policy-multivalue.md) + [Routing ponderato](routing-policy-weighted.md) + [In che modo Amazon Route 53 utilizza EDNS0 per stimare la posizione di un utente](routing-policy-edns0.md) # Routing semplice Il routing semplice consente di configurare record DNS standard, senza un routing di Route 53 speciale, ad esempio ponderato o latenza. Con il routing semplice, in genere il traffico viene instradato a un'unica risorsa, ad esempio a un server Web per il tuo sito Web. Puoi utilizzare una policy di instradamento semplice per creare i record in una zona ospitata privata. Se scegli la policy di routing semplice nella console Route 53, non è possibile creare più record con lo stesso nome e tipo, ma è possibile specificare più valori nello stesso record, ad esempio più indirizzi IP. (Se scegli la politica di routing semplice per un record di alias, puoi specificare solo una AWS risorsa o un record nella zona ospitata corrente.) Se specifichi più valori in un record, Route 53 restituisce tutti i valori al resolver ricorsivo in ordine casuale e il resolver restituisce i valori al client (ad esempio un browser Web) che ha inviato la query DNS. Il client, quindi, seleziona un valore e inoltra nuovamente la query. Con una policy di instradamento semplice è possibile specificare più indirizzi IP, ma su questi non viene eseguito alcun controllo dell'integrità. Per ulteriori informazioni sui valori specificati dall'utente quando si utilizza la policy di routing semplice per creare record, vedere i seguenti argomenti: + [Valori specifici per record semplici](resource-record-sets-values-basic.md) + [Valori specifici per record alias semplici](resource-record-sets-values-alias.md) + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) # Routing di failover Il routing di failover consente di instradare il traffico verso una risorsa quando la risorsa è integra o a un'altra risorsa quando la prima risorsa non è integra. I record primari e secondari possono instradare il traffico verso qualsiasi risorsa da un bucket Amazon S3 configurato come sito Web in una complessa struttura di record. Per ulteriori informazioni, consulta [Failover attivo-passivo](dns-failover-types.md#dns-failover-types-active-passive). Puoi utilizzare una policy di instradamento di failover per creare i record in una zona ospitata privata. Per ulteriori informazioni sui valori specificati dall'utente quando si utilizza la policy di routing del failover semplice per creare record, vedere i seguenti argomenti: + [Valori specifici per record di failover](resource-record-sets-values-failover.md) + [Valori specifici per i record alias di failover](resource-record-sets-values-failover-alias.md) + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) # Routing di geolocalizzazione Il routing di geolocalizzazione ti consente di scegliere le risorse in grado di gestire il traffico in base alla posizione geografica dei tuoi utenti, ossia la posizione da cui provengono le query DNS. È possibile, ad esempio, instradare tutte le query dall'Europa a un sistema di bilanciamento del carico Elastic Load Balancing nella regione di Francoforte. Quando usi il routing di geolocalizzazione, puoi localizzare i tuoi contenuti e presentare alcuni o tutti i tuoi siti Web nel linguaggio dei tuoi utenti. Puoi utilizzare il routing di geolocalizzazione anche per limitare la distribuzione di contenuti solo ai percorsi in cui disponi di diritti di distribuzione. Un altro possibile utilizzo è quello di bilanciare il carico tra gli endpoint in modo prevedibile, in easy-to-manage modo che ogni posizione dell'utente venga indirizzata in modo coerente allo stesso endpoint. Puoi specificare aree geografiche per continente, paese o stato degli Stati Uniti. Se crei record separati per regioni geografiche che si sovrappongono, ad esempio, un record per Nord America e uno per Canada, la priorità va alla regione geografica più piccola. In questo modo puoi instradare alcune query per un continente a una risorsa e instradare le query per determinati paesi su questo continente a un'altra risorsa. (Per un elenco di paesi in ciascun continente, consulta [Location (Ubicazione)](resource-record-sets-values-geo.md#rrsets-values-geo-location).) La geolocalizzazione funziona attraverso la mappatura di indirizzi IP alle posizioni. Tuttavia, alcuni indirizzi IP non sono mappati ad aree geografiche, quindi anche se crei record di geolocalizzazione che coprono tutti i sette continenti, Amazon Route 53 riceverà alcune query DNS da posizioni che non è in grado di identificare. Puoi creare un record di default che gestisce le query da parte di indirizzi IP che non vengono mappati ad alcuna posizione e le query che provengono da posizioni per cui non hai creato record di geolocalizzazione. Se non crei un record di default, Route 53 restituisce "nessuna risposta" per le query provenienti da tali posizioni. Puoi utilizzare una policy di instradamento basato sulla geolocalizzazione per creare i record in una zona ospitata privata o pubblica. Per ulteriori informazioni, consulta [In che modo Amazon Route 53 utilizza EDNS0 per stimare la posizione di un utente](routing-policy-edns0.md). Per ulteriori informazioni sui valori specificati dall'utente quando si utilizza la policy di routing di geolocalizzazione per creare record, vedere i seguenti argomenti: + [Valori specifici per record di geolocalizzazione](resource-record-sets-values-geo.md) + [Valori specifici per record degli alias di geolocalizzazione](resource-record-sets-values-geo-alias.md) + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) # Instradamento della geolocalizzazione in zone ospitate privata Per le zone ospitate private, Route 53 risponde alle query DNS in base al VPC da cui proviene Regione AWS la query. Per l'elenco di Regioni AWS, consulta [Regioni e zone](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) nella guida per l'*utente di Amazon EC2*. Se la query DNS proviene da una parte on-premise di una rete ibrida, verrà considerata come originata dal Regione AWS in cui si trova il VPC. Se si includono controlli dell'integrità, è possibile creare record predefiniti per: + Indirizzi IP che non sono mappati a posizioni geografiche. + Query DNS provenienti da posizioni per le quali non hai creato record di geolocalizzazione. Se il record di geolocalizzazione per la regione della query DNS non è integro, verrà restituito il record predefinito (se è integro). Nella configurazione di esempio nella figura seguente, le query DNS provenienti da un us-east-1 Regione AWS (Virginia) verranno instradate all'endpoint 1.1.1.1. ![\[Una schermata che mostra un record di geolocalizzazione per una zona ospitata privata.\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/geolocation-phz.png) # Geoproximity routing Il routing di geoprossimità consente ad Amazon Route 53 di instradare il traffico verso le tue risorse in base all'ubicazione geografica dei tuoi utenti e risorse. Indirizza il traffico verso la risorsa più vicina disponibile. Puoi anche scegliere di instradare più o meno traffico a una determinata risorsa specificando un valore, noto come *bias*. Un bias espande o restringe le dimensioni della regione geografica da cui il traffico viene instradato a una risorsa. Puoi creare regole di geoprossimità per le tue risorse e specificare uno dei seguenti valori per ciascuna regola: + Se utilizzi AWS risorse, specifica il gruppo Regione AWS di zone locali in cui hai creato la risorsa. + Se non utilizzi AWS risorse, specifica la latitudine e la longitudine della risorsa. Per utilizzare AWS Local Zones, devi prima abilitarle. Per ulteriori informazioni, consulta [Nozioni di base sulle zone locali](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) nella *Guida per l'utente delle zone locali AWS *. Per conoscere la differenza tra Regioni AWS e Local Zones, consulta [Regions and Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) nella *Amazon EC2 User* Guide. Per modificare facoltativamente le dimensioni della regione geografica da cui Route 53 indirizza il traffico a una risorsa, specifica il valore applicabile per il bias: + Per espandere le dimensioni della regione geografica da cui Route 53 indirizza il traffico a una risorsa, specifica un numero intero positivo tra 1 e 99 per il bias. Route 53 riduce le dimensioni delle Regioni adiacenti. + Per ridurre le dimensioni della Regione geografica da cui Route 53 instrada il traffico a una risorsa, specifica un numero negativo tra -1 e -99 per il bias. Route 53 espande le dimensioni delle Regioni adiacenti. **Nota** Stiamo aggiornando la console Traffic Flow per Route 53. Durante il periodo di transizione, puoi continuare a utilizzare la vecchia console. Seleziona la scheda per la console che stai utilizzando. + [Nuova console](#traffic-flow-geoprox-routing-map-new) + [Vecchia console](#traffic-flow-geoprox-routing-map-old) ------ #### [ New console ] La mappa seguente ne mostra quattro Regioni AWS (numerate da 1 a 5): 1. Stati Uniti occidentali (Oregon) 1. Europa (Francoforte) 1. Asia Pacifico (Tokyo) 1. Africa (Città del Capo) 1. Medio Oriente (Bahrein) **Nota** Le mappe sono disponibili solo con Traffic Flow. ![\[Una mappa del mondo che mostra come viene indirizzato il traffico quando si dispone di record di geoprossimità per le risorse negli Stati Uniti occidentali (Oregon), Regioni AWS in Europa (Francoforte), nell'Asia Pacifico (Tokyo), in Africa (Città del Capo) e nel Medio Oriente (Bahrein).\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png) **La mappa seguente mostra cosa succede se si aggiunge una polarizzazione di \$125 per la regione Stati Uniti occidentali (Oregon) (numero 1 sulla mappa).** Il traffico viene indirizzato alla risorsa in quella regione da una parte più ampia del Nord America e da tutto il Sud America rispetto al passato. ![\[Una mappa del mondo che mostra il modo in cui il traffico viene instradato quando si aggiunge un bias di +25 nella regione Stati Uniti orientali (Virginia settentrionale).\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png) La mappa seguente mostra cosa succede se si modifica la polarizzazione a -25 per la regione Stati Uniti occidentali (Oregon). ****Il traffico viene indirizzato alla risorsa in quella regione da porzioni più piccole del Nord e del Sud America rispetto al passato e una maggiore quantità di traffico viene indirizzata verso le risorse nelle regioni adiacenti **2, 3** e 4.**** ![\[Una mappa del mondo che mostra come viene indirizzato il traffico se si aggiunge una distorsione di -25 nella regione Stati Uniti occidentali (Oregon).\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png) ------ #### [ Old console ] La mappa seguente ne mostra quattro Regioni AWS (numerati da 1 a 4) e una località a Johannesburg, in Sudafrica, specificata da latitudine e longitudine (5). **Nota** Le mappe sono disponibili solo con Traffic Flow. ![\[Una mappa del mondo che mostra come viene indirizzato il traffico quando si dispone di record di geoprossimità per risorse Regioni AWS negli Stati Uniti occidentali (Oregon), Stati Uniti orientali (Virginia settentrionale), Europa (Parigi) e Asia Pacifico (Tokyo) e si ha un record per una non AWS risorsa a Johannesburg, in Sudafrica.\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png) La mappa seguente mostra cosa accade se si aggiunge un bias di \$125 per la regione Stati Uniti orientali (Virginia settentrionale), numero **2** sulla mappa. Il traffico viene instradato alla risorsa in quella regione da una maggiore porzione di Nord America rispetto al passato e da tutto il Sud America. ![\[Una mappa del mondo che mostra il modo in cui il traffico viene instradato quando si aggiunge un bias di +25 nella regione Stati Uniti orientali (Virginia settentrionale).\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png) La mappa seguente mostra cosa accade se si modifica il bias di -25 per la regione Stati Uniti orientali (Virginia settentrionale). Il traffico viene instradato alla risorsa in quella regione da una porzione minore rispetto al passato di Nord e Sud America e molto altro traffico viene instradato a risorse nelle regioni adiacenti **1**, **3** e **5**. ![\[Una mappa del mondo che mostra il modo in cui il traffico viene instradato quando si aggiunge un bias di -25 nella regione Stati Uniti orientali (Virginia settentrionale).\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png) ------ L'effetto della modifica del bias per le tue risorse dipende da una serie di fattori, tra cui le seguenti: + Il numero di risorse di cui disponi. + La vicinanza delle risorse tra loro. + Il numero di utenti che hai vicino la zona di confine tra regioni geografiche. Ad esempio, supponiamo di avere risorse negli Regioni AWS Stati Uniti orientali (Virginia settentrionale) e negli Stati Uniti occidentali (Oregon) e di avere molti utenti a Dallas, Austin e San Antonio, Texas, USA. Queste città sono all'incirca equidistanti tra le risorse, quindi una piccola variazione di orientamento potrebbe comportare una forte oscillazione del traffico tra le risorse dell'una e l'altra. Regione AWS È consigliabile modificare il bias in piccoli incrementi per evitare di sovraccaricare le risorse a causa di aumenti imprevisti del traffico. Per ulteriori informazioni, consulta [In che modo Amazon Route 53 utilizza EDNS0 per stimare la posizione di un utente](routing-policy-edns0.md). ## Come Amazon Route 53 utilizza il bias per instradare il traffico Ecco la formula che Amazon Route 53 utilizza per determinare come instradare il traffico: **Bias** `Biased distance = actual distance * [1 - (bias/100)]` Quando il valore della distorsione è positivo, Route 53 considera l'origine di una query DNS e la risorsa specificata in un record di geoprossimità (ad esempio un'istanza EC2 in un Regione AWS) come se fossero più vicine di quanto non siano in realtà. Ad esempio, supponiamo che hai i seguenti record di geoprossimità: + Un record per il server Web A, che dispone di un bias positivo di 50 + Un record per il server Web B, che non prevede alcun bias Quando un record di geoprossimità dispone di un bias positivo di 50, Route 53 dimezza la distanza tra l'origine di una query e la risorsa per quel record. Route 53 calcola quindi la risorsa che è più vicina all'origine della query. Supponiamo che il server Web A è a 150 chilometri dall'origine di una query e il server Web B è a 100 chilometri. Se nessuno dei record ha un bias, Route 53 instrada le query al server Web B perché è più vicino. Tuttavia, poiché il record per il server Web A ha un bias positivo di 50, Route 53 tratta il server Web A come se fosse 75 chilometri dall'origine della query. Di conseguenza, Route 53 instrada le query al server Web A. Ecco il calcolo per un bias positivo di 50: ``` Bias = 50 Biased distance = actual distance * [1 - (bias/100)] Biased distance = 150 kilometers * [1 - (50/100)] Biased distance = 150 kilometers * (1 - .50) Biased distance = 150 kilometers * (.50) Biased distance = 75 kilometers ``` # Routing basato sulla latenza Se la tua applicazione è ospitata su più server Regioni AWS, puoi migliorare le prestazioni degli utenti servendo le loro richieste dalla piattaforma Regione AWS che offre la latenza più bassa. **Nota** I dati sulla latenza tra gli utenti e le risorse si basano interamente sul traffico tra utenti e data center AWS . Se non utilizzi risorse in un ambiente Regione AWS, la latenza effettiva tra gli utenti e le tue risorse può variare in modo significativo rispetto ai dati di AWS latenza. Ciò vale anche se le risorse si trovano nella stessa città di una Regione AWS. Per usare il routing basato sulla latenza, è necessario creare record di latenza per le risorse in più Regioni AWS. Quando Route 53 riceve una query DNS per il tuo dominio o sottodominio (esempio.com o acme.esempio.com), determina per quali Regioni AWS hai creato record di latenza, determina quale regione offre all'utente la latenza minima e quindi seleziona un record di latenza per quella regione. Route 53 risponde con il valore proveniente dal record selezionato, ad esempio l'indirizzo IP per un server Web. Ad esempio, supponiamo di disporre di sistemi di bilanciamento del carico Elastic Load Balancing nella regione Stati Uniti occidentali (Oregon) e nella regione Asia Pacifico (Singapore). Crei un record di latenza per ogni sistema di bilanciamento del carico. Ecco cosa succede quando un utente a Londra immette il nome di dominio in un browser: 1. Il DNS instrada la query a un server dei nomi di Route 53. 1. Route 53 si riferisce ai propri dati sulla latenza tra Londra e la regione di Singapore e tra Londra e la regione dell'Oregon. 1. Se la latenza è inferiore tra le regioni di Londra e Oregon, Route 53 risponde alla query con l'indirizzo IP per il sistema di bilanciamento del carico dell'Oregon. Se la latenza è inferiore tra Londra e la regione di Singapore, Route 53 risponde con l'indirizzo IP per il sistema di bilanciamento del carico di Singapore. La latenza tra host su Internet può cambiare nel tempo a causa delle modifiche di connettività di rete e di routing. Il routing basato sulla latenza si basa su misurazioni di latenza eseguite in un determinato periodo di tempo e le misurazioni rispecchiano queste modifiche. Una richiesta instradata alla regione dell'Oregon questa settimana potrebbe essere instradata alla regione di Singapore la prossima settimana. **Nota** Quando un browser o un altro visualizzatore utilizza un resolver DNS che supporta l' edns-client-subnetestensione di EDNS0, il resolver DNS invia a Route 53 una versione troncata dell'indirizzo IP dell'utente. Se configuri il routing basato sulla latenza, Route 53 considera questo valore quando instrada il traffico alle tue risorse. Per ulteriori informazioni, consulta [In che modo Amazon Route 53 utilizza EDNS0 per stimare la posizione di un utente](routing-policy-edns0.md). Puoi utilizzare una policy di instradamento della latenza per creare i record in una zona ospitata privata. Per ulteriori informazioni sui valori specificati dall'utente quando si utilizza la policy di routing della latenza per creare record, vedere i seguenti argomenti: + [Valori specifici per i record di latenza](resource-record-sets-values-latency.md) + [Valori specifici per i record alias di latenza](resource-record-sets-values-latency-alias.md) + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) # Instradamento basato sulla latenza in zone ospitate private Per le zone ospitate private, Route 53 risponde alle query DNS con un endpoint che si trova nello stesso Regione AWS o è il più vicino in termini di distanza al VPC da cui ha avuto origine Regione AWS la query. **Nota** Se hai un endpoint in uscita inoltrato a un endpoint in entrata, il record verrà risolto in base alla posizione dell’endpoint in entrata, non dell’endpoint in uscita. Se si includono i controlli dell'integrità e il record con la latenza più bassa rispetto all'origine della query non è integro, viene restituito un endpoint integro con la successiva latenza più bassa. Nella configurazione di esempio riportata nella figura seguente, le query DNS provenienti da un us-east-1 Regione AWS, o più vicino ad esso, verranno instradate all'endpoint 1.1.1.1. Le query DNS da us-west-2, o da regione vicina, verranno instradate all'endpoint 2.2.2.2. ![\[Uno screenshot che mostra due record di latenza per una zona ospitata privata.\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/latency-phz.png) # Routing basato su IP Con il routing basato su IP in Amazon Route 53, puoi ottimizzare il routing DNS sfruttando la tua comprensione della rete, delle applicazioni e dei client per prendere le migliori decisioni di routing DNS per gli utenti finali. Il routing basato su IP offre un controllo granulare per ottimizzare le prestazioni o ridurre i costi di rete caricando i dati su Route 53 sotto forma di mappature. user-IP-to-endpoint I routing di geolocalizzazione e della latenza si basano sui dati che Route 53 raccoglie e mantiene aggiornati. Questo approccio funziona per la maggior parte dei clienti, ma il routing basato su IP offre la possibilità aggiuntiva di ottimizzare il routing a seconda delle conoscenze specifiche del tuo portafoglio clienti. Ad esempio, un provider globale di contenuti video potrebbe voler instradare gli utenti finali da un provider di servizi Internet (ISP) specifico. Quelli che seguono sono alcuni dei casi di utilizzo più frequenti dell'instradamento basato su IP: + Desideri indirizzare gli utenti finali da determinati endpoint a endpoint specifici ISPs in modo da ottimizzare i costi o le prestazioni del transito di rete. + Desideri aggiungere delle sostituzioni ai tipi di instradamento di Route 53 esistenti, come l'instradamento basato sulla geolocalizzazione, sulla base della conoscenza delle posizioni fisiche dei clienti. **Gestione degli intervalli IP e loro associazione a un set di record di risorse () RRSet** Ad IPv4 esempio, è possibile utilizzare blocchi CIDR compresi tra 1 e 24 bit di lunghezza, inclusi, mentre perIPv6, è possibile utilizzare blocchi CIDR tra 1 e 48 bit di lunghezza, inclusi. Per definire un blocco CIDR a zero bit (0.0.0.0/0 o ::/0), utilizza la posizione predefinita ("\$1"). Per le query DNS con un CIDR più lungo di quello specificato nella raccolta CIDR, Route 53 lo abbinerà al CIDR più breve. Ad esempio, se si specifica 2001:0DB8: :/32 come blocco CIDR nella raccolta CIDR e una query ha origine da 2001:0:0000:1234: :/48, corrisponderà. DB8 Se, d'altra parte, specifichi 2001:0DB8: 0000:1234: :/48 nella tua raccolta CIDR e una query ha origine da 2001:0DB8: :/32, questa non corrisponderà e Route 53 risponderà con il record per la posizione predefinita («\$1»). Puoi raggruppare i set di blocchi CIDR (o gli intervalli IP) in posizioni CIDR, che a loro volta sono raggruppate in entità riutilizzabili chiamate raccolte CIDR: **blocco CIDR** Un intervallo IP in notazione CIDR, ad esempio 192.0.2.0/24 o 2001:: :/32. DB8 **Posizione CIDR** Un elenco con i nomi dei blocchi CIDR. Ad esempio, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:: :/32]. DB8 I blocchi in un elenco di posizioni CIDR non devono essere adiacenti o avere lo stesso intervallo. Una singola posizione può avere entrambi i blocchi e questa posizione può essere associata rispettivamente ai set di record A e AAAA. IPv4 IPv6 Per convenzione, di solito il nome è una posizione, ma può essere qualsiasi stringa, ad esempio *Company-A*. **Raccolta CIDR** Una raccolta con i nomi delle posizioni. Ad esempio, mycollection = [example-isp-seattle, example-isp-tokyo]. I set del record della risorsa di routing basato su IP fanno riferimento a una posizione in una raccolta e tutti i set del record della risorsa per lo stesso nome e tipo di set devono fare riferimento alla stessa raccolta. Ad esempio, se crei siti Web in due regioni e desideri indirizzare le query DNS da due diverse posizioni CIDR verso un sito Web specifico in base agli indirizzi IP di origine, entrambe le posizioni devono essere elencate nella stessa raccolta CIDR. Puoi utilizzare una policy di instradamento basato su IP per creare i record in una zona ospitata privata. Per ulteriori informazioni sui valori specificati dall'utente quando utilizzi la policy di routing basato su IP per creare i record, consulta i seguenti argomenti: + [Valori specifici per i record basati su IP](resource-record-sets-values-ipbased.md) + [Valori specifici per i record alias basati su IP](resource-record-sets-values-ipbased-alias.md) + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) **Topics** + [Creazione di una raccolta CIDR con posizioni e blocchi CIDR](resource-record-sets-creating-cidr-collection.md) + [Utilizzo di posizioni e blocchi CIDR](resource-record-sets-working-with-cidr-locations.md) + [Eliminazione di una raccolta CIDR](resource-record-sets-delete-cidr-collection.md) + [Spostamento di una geolocalizzazione in un routing basato su IP](resource-record-sets-move-geolocation-to-cidr.md) # Creazione di una raccolta CIDR con posizioni e blocchi CIDR Per iniziare, crea una raccolta CIDR e aggiungi i blocchi e le posizioni CIDR. **Creazione di una raccolta CIDR tramite la console Route 53** 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 riquadro di navigazione, scegli **IP-based routing** (Routing basato su IP), quindi **CIDR collections** (Raccolte CIDR). 1. Seleziona **Create CIDR collection** (Crea raccolta CIDR). 1. Nel riquadro **Create CIDR collection** (Crea raccolta CIDR), in **Details** (Dettagli), inserisci un nome per la raccolta. 1. Scegli **Create collection** (Crea raccolta) per creare una raccolta vuota. oppure Nella sezione **Crea posizioni CIDR**, inserisci un nome per la posizione CIDR nella casella **Posizione CIDR.** Il nome della posizione può essere una qualsiasi stringa identificativa, ad esempio **company 1** o **Seattle**. Non deve essere obbligatoriamente una posizione geografica effettiva. **Importante** Il nome della posizione CIDR ha una lunghezza massima di 16 caratteri. Inserisci i blocchi CIDR nella casella **Blocchi CIDR**, uno per riga. Questi possono essere IPv4 IPv6 indirizzi che vanno da /0 a /24 per IPv4 e da /0 a /48 per. IPv6 1. Dopo avere inserito i blocchi CIDR, scegli **Create CIDR collection** (Crea raccolta CIDR) oppure **Add another location** (Aggiungi un'altra posizione) per continuare a inserire le posizioni e il blocco CIDR. Puoi inserire più posizioni CIDR per raccolta. 1. Dopo avere inserito le posizioni CIDR, scegli **Create CIDR collection** (Crea raccolta CIDR). # Utilizzo di posizioni e blocchi CIDR **Utilizzo delle posizioni CIDR tramite la console Route 53** 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 riquadro di navigazione, scegli **IP-based routing** (Routing basato su IP), **CIDR collections** (Raccolte CIDR) e poi, nella sezione **CIDR collections** (Raccolte CIDR), fai clic su un collegamento a una raccolta CIDR nell'elenco **Collection name** (Nome raccolta). Nella pagina **CIDR locations** (Posizioni CIDR), puoi creare, eliminare o modificare una posizione CIDR e i relativi blocchi. + Per creare una posizione, scegli **Create CIDR location** (Crea posizione CIDR). + Nel riquadro **Create CIDR location** (Crea posizione CIDR), inserisci un nome per la posizione e i blocchi CIDR associati a essa, quindi scegli **Create** (Crea). + Per visualizzare una posizione CIDR e i blocchi al suo interno, scegli il pulsante di opzione accanto a una posizione per mostrare il nome e i blocchi CIDR nel riquadro della posizione. In questo riquadro puoi anche scegliere **Modifica** per aggiornare il nome della posizione o i suoi blocchi CIDR. Scegli **Salva** una volta completata la modifica. + Per eliminare una posizione CIDR e i blocchi al suo interno, scegli il pulsante di opzione accanto alla posizione che desideri eliminare, quindi seleziona **Delete** (Elimina). Per confermare l'eliminazione, inserisci il nome della posizione nel campo di immissione del testo e scegli di nuovo **Delete** (Elimina). **Importante** L'eliminazione di una posizione CIDR non può essere annullata. Se hai dei record DNS associati alla posizione, il tuo dominio potrebbe diventare irraggiungibile. # Eliminazione di una raccolta CIDR **Eliminazione di una raccolta CIDR, le relative posizioni e i blocchi tramite la console Route 53** 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 riquadro di navigazione, scegli **IP-based routing** (Routing basato su IP) quindi **CIDR collections** (Raccolte CIDR). 1. Nella sezione **CIDR collections** (Raccolte CIDR), fai clic sul nome collegato della raccolta che desideri eliminare. 1. Nella pagina **CIDR locations** (Posizioni CIDR), seleziona ogni posizione una alla volta, scegli **Delete** (Elimina), inserisci il nome nella finestra di dialogo, quindi scegli **Delete** (Elimina). Prima di eliminare la raccolta, devi eliminare ogni posizione associata a una raccolta CIDR. 1. Al termine dell'eliminazione di ogni posizione CIDR, nella pagina **CIDR locations** (Posizioni CIDR) scegli il pulsante di opzione accanto alla raccolta che desideri eliminare, quindi seleziona **Delete** (Elimina). # Spostamento di una geolocalizzazione in un routing basato su IP Se utilizzi le policy di routing di geolocalizzazione o geoprossimità e visualizzi costantemente client specifici instradati a un endpoint che non è ottimale in base alla loro posizione fisica o alla topologia di rete, puoi indirizzare meglio gli intervalli IP pubblici di questi client utilizzando il routing basato su IP. La tabella seguente contiene un esempio di configurazione della geolocalizzazione per un routing di geolocalizzazione esistente che ottimizzeremo per gli intervalli IP della California. | Nome del set del record | Policy di routing e origine | Indirizzo IP dell'endpoint dell'applicazione | | --- | --- | --- | | esempio.com | Routing di geolocalizzazione (Stati uniti) | `198.51.100.1` | | esempio.com | Routing di geolocalizzazione (UE) | `198.51.100.2` | Per sostituire gli intervalli IP dalla California e passare a un nuovo endpoint dell'applicazione, ricrea innanzitutto il routing di geolocalizzazione con un nuovo nome del set del record. | Nome del set del record | Policy di routing e origine | Indirizzo IP dell'endpoint dell'applicazione | | --- | --- | --- | | geo.esempio.com | Routing di geolocalizzazione (Stati uniti) | `198.51.100.1` | | geo.esempio.com | Routing di geolocalizzazione (UE) | `198.51.100.2` | Quindi, crea i record di routing basati su IP e un record predefinito che punta al recordset di routing di geolocalizzazione ricreato recentemente. | Nome del set del record | Policy di routing e origine | Indirizzo IP dell'endpoint dell'applicazione | | --- | --- | --- | | esempio.com | Routing basato su IP (predefinito) | Record alias per l'endpoint dell'applicazione geo.esempio.com che desideri come predefinito. Ad esempio, `198.51.100.1`. | | esempio.com | Routing basato su IP (intervalli IP della California) | `198.51.100.3` | # Routing di risposta multivalore Il routing con risposta multivalore ti consente di configurare Amazon Route 53 per restituire più valori, ad esempio indirizzi IP per i server Web, in risposta alle query DNS. Puoi specificare più valori per quasi tutti i record, ma il routing di risposta multivalore ti consente di controllare lo stato di ciascuna risorsa, perciò Route 53 restituisce valori solo per le risorse integre. Non è un sostituito per un load balancer, ma la capacità di restituire indirizzi IP multipli il cui stato può essere controllato è un modo per utilizzare il DNS al fine di migliorare capacità e load balancer. Per instradare il traffico in modo casuale a più risorse, ad esempio server Web, devi creare un record di risposta multivalore per ciascuna risorsa e, facoltativamente, associare un controllo dell'integrità di Route 53 a ogni record. Route 53 risponde alle query DNS con un massimo di otto record integri e offre diverse risposte a diversi resolver DNS. Se un server Web non è più disponibile dopo che un resolver memorizza una risposta nella cache, il software client può provare un altro indirizzo IP nella risposta. Tenere presente quanto segue: + Se associ un controllo dell'integrità a un record di risposta multivalore, Route 53 risponde alle query DNS con l'indirizzo IP corrispondente solo quando il controllo dell'integrità è positivo. + Se non associ un controllo dell'integrità a un record di risposta multivalore, Route 53 considera sempre il record come integro. + Se disponi di otto o meno record integri, Route 53 risponde alle query DNS con tutti i record integri. + Quando tutti i record non sono integri, Route 53 risponde alle query DNS con un massimo di otto record non integri. Puoi utilizzare una policy di instradamento con risposta multivalore per creare i record in una zona ospitata privata. Per ulteriori informazioni sui valori specificati dall'utente quando si utilizza la policy di routing di risposta multivalore per creare record, vedere [Valori specifici per record di risposta multivalore](resource-record-sets-values-multivalue.md) e [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md). # Routing ponderato Il routing ponderato consente di associare più risorse con un solo nome di dominio (esempio.com) o nome di sottodominio (acme.esempio.com) e di scegliere la quantità di traffico che viene instradato a ciascuna risorsa. Questo può essere utile per un'ampia gamma di scopi, tra cui il bilanciamento del carico e il test di nuove versioni di software. Per configurare il routing ponderato, devi creare record con lo stesso nome e tipo per ciascuna delle tue risorse. Puoi assegnare a ogni record un peso relativo che corrisponde alla quantità di traffico che desideri inviare a ogni risorsa. Amazon Route 53 invia il traffico a una risorsa in base al peso che assegni al record come proporzione del peso totale per tutti i record nel gruppo: ![\[Formula per la quantità di traffico che viene instradato a una determinata risorsa: peso per un record specificato/somma di pesi per tutti i record.\]](http://docs.aws.amazon.com/it_it/Route53/latest/DeveloperGuide/images/WRR_calculation.png) Ad esempio, se desideri inviare una piccola porzione di traffico a una risorsa e il resto a un'altra risorsa, devi specificare un peso di 1 e 255. La risorsa con un peso pari a 1 ottiene 1/256esimo del traffico (01/(01\$1255)) e l'altra risorsa ottiene 255/256esimi (255/(1\$1255)). È possibile modificare gradualmente l'equilibrio modificando i pesi. Se desideri interrompere l'invio del traffico a una risorsa, puoi modificare il peso per quel record su 0. Per ulteriori informazioni sui valori specificati dall'utente quando si utilizza la policy di routing ponderato per creare record, vedere i seguenti argomenti: + [Valori specifici per record ponderati](resource-record-sets-values-weighted.md) + [Valori specifici per i record alias ponderati](resource-record-sets-values-weighted-alias.md) + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) Puoi utilizzare una policy di instradamento ponderato per creare i record in una zona ospitata privata. ## Controlli dell'integrità e routing ponderato Se aggiungi controlli dell'integrità a tutti i record di un gruppo di record ponderati, ma ad alcuni record assegni un peso diverso da zero e ad altri un peso pari a zero, i controlli dell'integrità funzionano come se tutti i record avessero un peso diverso da zero, con le seguenti eccezioni: + Route 53 inizialmente considera solo i record ponderati diversi da zero, se esistenti. + Se tutti i record con un peso maggiore di 0 non sono integri, allora Route 53 considera i record con peso zero. La tabella seguente descrive il comportamento previsto quando il record con peso 0 comprende un controllo dell'integrità: | | Record 1 | Record 2 | Record 3 | | --- |--- |--- |--- | | Weight | 1 | 1 | 0 | | Comprende un controllo dell'integrità? | Sì | Sì | Sì | | | | --- | | Stato del controllo dell'integrità | Non integro | Non integro | Integro | | Si è ricevuta una risposta alla query DNS? | No | No | Sì | | | | --- | | Stato del controllo dell'integrità | Non integro | Non integro | Non integro | | Si è ricevuta una risposta alla query DNS? | Sì | Sì | No | | | | --- | | Stato del controllo dell'integrità | Non integro | Integro | Non integro | | Si è ricevuta una risposta alla query DNS? | No | Sì | No | | | | --- | | Stato del controllo dell'integrità | Integro | Integro | Non integro | | Si è ricevuta una risposta alla query DNS? | Sì | Sì | No | | | | --- | | Stato del controllo dell'integrità | Integro | Integro | Integro | | Si è ricevuta una risposta alla query DNS? | Sì | Sì | No | La tabella seguente descrive il comportamento previsto quando il record con peso 0 non comprende un controllo dell'integrità: | | Record 1 | Record 2 | Record 3 | | --- |--- |--- |--- | | Weight | 1 | 1 | 0 | | Comprende un controllo dell'integrità? | Sì | Sì | No | | | | --- | | Stato del controllo dell'integrità | Integro | Integro | N/D | | Si è ricevuta una risposta alla query DNS? | Sì | Sì | No | | | | --- | | Stato del controllo dell'integrità | Non integro | Non integro | N/D | | Si è ricevuta una risposta alla query DNS? | No | No | Sì | | | | --- | | Stato del controllo dell'integrità | Non integro | Integro | N/D | | Si è ricevuta una risposta alla query DNS? | No | Sì | No | # In che modo Amazon Route 53 utilizza EDNS0 per stimare la posizione di un utente Per migliorare la precisione di geolocalizzazione, geoprossimità, routing basato su IP e latenza, Amazon Route 53 supporta l'estensione di. edns-client-subnet EDNS0 (EDNS0 aggiunge diverse estensioni opzionali al protocollo DNS.) Route 53 può essere utilizzato edns-client-subnet solo quando i resolver DNS lo supportano: + Quando un browser o un altro visualizzatore utilizza un resolver DNS che non supporta edns-client-subnet, Route 53 utilizza l'indirizzo IP di origine del resolver DNS per approssimare la posizione dell'utente e risponde alle query di geolocalizzazione con il record DNS relativo alla posizione del resolver. + Quando un browser o un altro visualizzatore utilizza un resolver DNS che lo supporta edns-client-subnet, il resolver DNS invia a Route 53 una versione troncata dell'indirizzo IP dell'utente. Route 53 determina la posizione dell'utente in base all'indirizzo IP troncato anziché l'indirizzo IP di origine dell'autore della resolver DNS; questo normalmente fornisce una stima più precisa sulla posizione dell'utente. Route 53 risponde quindi alle query di geolocalizzazione con il record DNS per la posizione dell'utente. + EDNS0 non è applicabile alle zone ospitate private. Per le zone ospitate private, Route 53 utilizza i dati dei Resolver VPC in cui si trova la Regione AWS zona ospitata privata per prendere decisioni sulla geolocalizzazione e sul routing della latenza. [Per ulteriori informazioni su edns-client-subnet, consulta EDNS Client Subnet RFC, Client Subnet in DNS Requests.](https://www.rfc-editor.org/rfc/rfc7871) # Scelta tra record alias e non alias I *record alias* di Amazon Route 53 forniscono un'estensione specifica di Route 53 alla funzionalità DNS. I record di alias consentono di indirizzare il traffico verso AWS risorse selezionate, tra cui, a titolo esemplificativo, CloudFront distribuzioni e bucket Amazon S3. Inoltre, consentono di instradare il traffico da un record in una zona ospitata a un altro record. A differenza del record CNAME, puoi creare un record alias sul nodo superiore di uno spazio dei nomi DNS, noto anche come *apex di zona*. Ad esempio, se record il nome DNS esempio.com, l'apex di zona è esempio.com. Non puoi creare un record CNAME per esempio.com, ma puoi creare un record alias per esempio.com che esegue l’instradamento del traffico in www.esempio.com (purché il tipo di record per www.esempio.com non sia già CNAME). Quando Route 53 riceve una query DNS per un record alias, Route 53 risponde con il valore applicabile per la risorsa: + **Un'API regionale personalizzata di Amazon API Gateway o un'API ottimizzata per l'edge**: Route 53 risponderà con uno o più indirizzi IP per l'API. + **Un endpoint dell'interfaccia Amazon VPC**: Route 53 risponderà con uno o più indirizzi IP per l'endpoint dell'interfaccia. + **Una CloudFront distribuzione**: Route 53 risponde con uno o più indirizzi IP per i server CloudFront edge che possono servire i tuoi contenuti. + **Servizio App Runner**: Route 53 risponde con uno o più indirizzi IP. + **Un ambiente Elastic Beanstalk**: Route 53 risponderà con uno o più indirizzi IP per l'ambiente. + **Un sistema di bilanciamento del carico Elastic Load Balancing**: Route 53 risponde con uno o più indirizzi IP del sistema di bilanciamento del carico. Ciò include Application Load Balancer, Classic Load Balancer e Network Load Balancer. + **Un AWS Global Accelerator acceleratore**: Route 53 risponde con gli indirizzi IP dell'acceleratore. + **Un OpenSearch servizio**: Route 53 risponde con uno o più indirizzi IP per il dominio personalizzato del OpenSearch servizio. + **Un bucket Amazon S3 configurato come sito Web statico**: Route 53 risponderà a ogni richiesta con un indirizzo IP per il bucket Amazon S3. + **Un altro record Route 53 dello stesso tipo nella stessa zona ospitata**: Route 53 risponde come se la query fosse per il record a cui fa riferimento il record alias (consulta [Confronto tra record alias e CNAME](#resource-record-sets-choosing-alias-non-alias-comparison)). + **AWS AppSync nome di dominio**: Route 53 risponde con uno o più indirizzi IP per l'endpoint di interfaccia. Per ulteriori informazioni, consulta [Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). Quando si utilizza un record di alias per indirizzare il traffico verso una AWS risorsa, Route 53 riconosce automaticamente le modifiche nella risorsa. Ad esempio, supponiamo che un record alias di un example.com punti a un sistema di bilanciamento del carico Elastic Load Balancing presso lb1-1234.us-east-2.elb.amazonaws.com. Se l'indirizzo IP del load balancer cambia, Route 53 inizia a rispondere automaticamente alle query DNS utilizzando il nuovo indirizzo IP. Se un record di alias punta a una AWS risorsa, non è possibile impostare il time to live (TTL); Route 53 utilizza il TTL predefinito per la risorsa. Se un record alias punta a un altro record nella stessa zona ospitata, Route 53 usa il TTL del record a cui punta il record alias. Per ulteriori informazioni sul valore TTL (Time to Live) corrente per Elastic Load Balancing, consulta [Routing della richiesta](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) nella *Guida per l'utente di Elastic Load Balancing* e cerca "ttl". Per informazioni sulla creazione di record utilizzando la console Route 53, consulta [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md). Per informazioni sui valori che specifichi per i record alias applicabili, consulta l'argomento relativo in [Di seguito sono descritti i valori che devi specificare durante la creazione o la modifica di record di Amazon Route 53.](resource-record-sets-values.md): + [Valori specifici per record alias semplici](resource-record-sets-values-alias.md) + [Valori specifici per i record alias ponderati](resource-record-sets-values-weighted-alias.md) + [Valori specifici per i record alias di latenza](resource-record-sets-values-latency-alias.md) + [Valori specifici per i record alias di failover](resource-record-sets-values-failover-alias.md) + [Valori specifici per record degli alias di geolocalizzazione](resource-record-sets-values-geo-alias.md) + [Valori specifici per i record di alias di geoprossimità](resource-record-sets-values-geoprox-alias.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) ## Confronto tra record alias e CNAME I record alias sono simili a record CNAME, ma ci sono alcune differenze importanti. Nell'elenco seguente vengono confrontati i record alias e i record CNAME. **Risorse verso cui è possibile reindirizzare le query** **Record alias** Un record di alias può reindirizzare le query solo a AWS risorse selezionate, tra cui, a titolo esemplificativo ma non esaustivo, quanto segue: + Bucket Amazon S3 + CloudFront distribuzioni + Un altro record nella stessa zona ospitata Route 53 Ad esempio, è possibile creare un record alias denominato acme.esempio.com che reindirizza le query a un bucket Amazon S3, anch'esso denominato acme.esempio.com. È anche possibile creare un record alias acme.esempio.com che reindirizza le query a un record denominato zenith.example.com nella zona ospitata esempio.com. **Registri CNAME** Un record CNAME può reindirizzare query DNS a qualsiasi record DNS. Ad esempio, è possibile creare un record CNAME che reindirizza le query da acme.esempio.com a zenith.example.com o ad acme.example.org. Non è necessario utilizzare Route 53 come servizio DNS per il dominio a cui si stanno reindirizzando le query. **Creazione di record con lo stesso nome del dominio (record all'apex di zona)** **Record alias** Nella maggior parte delle configurazioni, è possibile creare un record alias con lo stesso nome della zona ospitata (apex di zona). L'unica eccezione è quando si desidera reindirizzare le query dall'apex di zona (come esempio.com) per un record nella stessa zona ospitata che dispone di un tipo CNAME (ad esempio zenith.esempio.com). Il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. **Registri CNAME** Non è possibile creare un record CNAME con lo stesso nome della zona ospitata (apex di zona). Questo vale sia per le zone ospitate che per i nomi di dominio (esempio.com) e per le zone ospitate dei sottodomini (zenith.esempio.com). **Prezzi per query DNS** **Record alias** Route 53 non addebita alcun costo per le richieste di alias alle risorse. AWS Per ulteriori informazioni, consulta la [pagina dei Prezzi Amazon Route 53](https://aws.amazon.com/route53/pricing/). **Registri CNAME** Route 53 prevede addebiti per le query CNAME. Se crei un record CNAME che esegue il reindirizzamento al nome di un altro record in una zona ospitata Route 53 (la stessa zona ospitata o un'altra zona ospitata), ogni query DNS viene addebitata come due query: + Route 53 risponde alla prima query DNS con il nome del record verso cui eseguire il reindirizzamento. + Il resolver DNS deve quindi inviare un'altra query per il record nella prima risposta per ottenere informazioni su dove indirizzare il traffico, ad esempio l'indirizzo IP di un server Web. Se il record CNAME esegue il reindirizzamento al nome di un record ospitato con un altro servizio DNS, Route 53 addebita una query. L'altro servizio DNS potrebbe addebitare la seconda query. **Tipo di record specificato nella query DNS** **Record alias** Route 53 risponde a una query DNS solo quando il nome del record alias (ad esempio acme.esempio.com) e il tipo di record alias (ad esempio A o AAAA) corrispondono al nome e al tipo della query DNS. **Registri CNAME** Un record CNAME esegue il reindirizzamento delle query DNS per un nome di record a prescindere dal tipo di record specificato nella query DNS, ad esempio A o AAAA. **Come vengono elencati i record nelle query dig o nslookup** **Record alias** Nella risposta a una query dig o nslookup, un record alias viene elencato come il tipo di record specificato al momento della creazione del record, ad esempio A o AAAA. (Il tipo di record specificato per un record alias dipende dalla risorsa verso cui si sta instradando il traffico. Ad esempio, per instradare il traffico a un bucket S3, specifica A per il tipo.) La proprietà alias è visibile solo nella console Route 53 o nella risposta a una richiesta programmatica, ad esempio un comando CLI AWS . `list-resource-record-sets` **Registri CNAME** Un record CNAME viene elencato come un record CNAME in risposta alle query d'individuazione o di ricerca. # Tipi di record DNS supportati Amazon Route 53 supporta i tipi di record DNS elencati in questa sezione. Ogni tipo di record include anche un esempio di come formattare l'elemento `Value` quando accedi a Route 53 utilizzando l'API. **Nota** Per i tipi di record che includono un nome di dominio, immetto un nome di dominio completo, ad esempio, *www.esempio.com*. Il punto finale è facoltativo; Route 53 presuppone che il nome di dominio sia completo. Ciò significa che Route 53 considera identici *www.esempio.com* (senza un punto finale) e *www.esempio.com.* (con un punto finale). Route 53 fornisce un'estensione alla funzionalità DNS nota come record alias. Analogamente ai record CNAME, i record alias consentono di indirizzare il traffico verso AWS risorse selezionate, come CloudFront distribuzioni e bucket Amazon S3. Per ulteriori informazioni, incluso un confronto tra record alias e CNAME, vedi [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Tipo di record A](#AFormat) + [Tipo di record AAAA](#AAAAFormat) + [Tipo di record CAA](#CAAFormat) + [Tipo di record CNAME](#CNAMEFormat) + [Tipo di record DS](#DSFormat) + [Tipo di record HTTPS](#HTTPSFormat) + [Tipo di record MX](#MXFormat) + [Tipo di record NAPTR](#NAPTRFormat) + [Tipo di record NS](#NSFormat) + [Tipo di record PTR](#PTRFormat) + [Tipo di record SOA](#SOAFormat) + [Tipo di record SPF](#SPFFormat) + [Tipo di record SRV](#SRVFormat) + [Tipo di record SSHFP](#SSHFPFormat) + [Tipo di record SVCB](#SVCBFormat) + [Tipo di record TLSA](#TLSAFormat) + [Tipo di record TXT](#TXTFormat) ## Tipo di record A Utilizzi un record A per indirizzare il traffico verso una risorsa, ad esempio un server Web, utilizzando un IPv4 indirizzo in notazione decimale puntata. **Esempio per la console Amazon Route 53** ``` 192.0.2.1 ``` **Esempio per l'API Route 53** ``` 192.0.2.1 ``` ## Tipo di record AAAA Si utilizza un record AAAA per indirizzare il traffico verso una risorsa, ad esempio un server Web, utilizzando un IPv6 indirizzo in formato esadecimale separato da due punti. **Esempio per la console Amazon Route 53** ``` 2001:0db8:85a3:0:0:8a2e:0370:7334 ``` **Esempio per l'API Route 53** ``` 2001:0db8:85a3:0:0:8a2e:0370:7334 ``` ## Tipo di record CAA Un record CAA specifica quali autorità di certificazione (CAs) sono autorizzate a emettere certificati per un dominio o sottodominio. La creazione di un record CAA aiuta a prevenire l'emissione errata di certificati per CAs i tuoi domini. Un record CAA non è un sostituto per i requisiti di sicurezza specificati dall'autorità di certificazione, ad esempio il requisito di convalidare che sei il proprietario di un dominio. Puoi utilizzare i record CAA per specificare quanto segue: + Quali autorità di certificazione (CAs) possono emettere SSL/TLS certificati, se ce ne sono + L'indirizzo e-mail o l'URL da contattare quando un'autorità di certificazione emette un certificato per il dominio o il sottodominio. Quando aggiungi un record CAA alle tue zona ospitata, devi specificare tre impostazioni separate da spazi: `flags tag "value"` Nota le seguenti informazioni sul formato per i record CAA: + Il valore di `tag` può contenere solo i caratteri A - Z, a - z e 0-9. + Racchiudi sempre `value` tra virgolette (""). + Alcuni CAs consentono o richiedono valori aggiuntivi per`value`. Specifica i valori aggiuntivi come coppie nome-valore e separale con un punto e virgola (;), ad esempio: `0 issue "ca.example.net; account=123456"` + Se una CA riceve una richiesta per un certificato per un sottodominio (ad esempio www.esempio.com) e non esistono record CAA per il sottodominio esistente, la CA invia una query DNS per un record CAA per il dominio padre (ad esempio esempio.com). Se un record per il dominio padre esiste e la richiesta di certificato è valida, la CA emette il certificato per il sottodominio. + Ti consigliamo di contattare la CA per determinare i valori da specificare per un record CAA. + Non è possibile creare un record CAA e un record CNAME con lo stesso nome perché DNS non consente di utilizzare lo stesso nome per un record CNAME e per qualsiasi altro tipo di record. **Topics** + [Autorizza una CA al rilascio di un certificato per un dominio o sottodominio](#CAAFormat-issue) + [Autorizza una CA al rilascio di un certificato jolly per un dominio o sottodominio](#CAAFormat-issue-wild) + [Impedire a qualsiasi CA di emettere un certificato per un dominio o sottodominio](#CAAFormat-prevent-issue) + [Richiedere che una CA ti contatti se riceve una richiesta di certificato non valida](#CAAFormat-contact) + [Utilizzare un'altra impostazione supportata dalla CA](#CAAFormat-custom-setting) + [Esempi](#CAAFormat-examples) ### Autorizza una CA al rilascio di un certificato per un dominio o sottodominio Per autorizzare una CA a rilasciare un certificato per un dominio o sottodominio, devi creare un record con lo stesso nome del dominio o del sottodominio e specificare le impostazioni seguenti: + **flag** - `0` + **tag** - `issue` + **value**: il codice per la CA che autorizzi a emettere un certificato per il dominio o sottodominio Ad esempio, supponiamo che desideri autorizzare ca.esempio.net a emettere un certificato per esempio.com. Devi creare un record CAA per esempio.com con le impostazioni seguenti: ``` 0 issue "ca.example.net" ``` Per informazioni su come AWS Certificate Manager autorizzare l'emissione di un certificato, consulta [Configurare un record CAA nella Guida](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) per l'*AWS Certificate Manager utente*. ### Autorizza una CA al rilascio di un certificato jolly per un dominio o sottodominio Per autorizzare una CA a rilasciare un certificato jolly per un dominio o sottodominio, devi creare un record con lo stesso nome del dominio o del sottodominio e specificare le impostazioni seguenti. Un certificato jolly si applica al dominio o sottodominio e a tutti i suoi sottodomini. + **flag** - `0` + **tag** - `issuewild` + **value**: il codice per la CA che autorizzi a emettere un certificato per un dominio o sottodominio e i relativi sottodomini Ad esempio, supponiamo che desideri autorizzare ca.esempio.net a emettere un certificato jolly per esempio.com, che si applica a esempio.com e a tutti i suoi sottodomini. Devi creare un record CAA per esempio.com con le impostazioni seguenti: ``` 0 issuewild "ca.example.net" ``` Se desideri autorizzare una CA a rilasciare un certificato jolly per un dominio o sottodominio, devi creare un record con lo stesso nome del dominio o del sottodominio e specificare le impostazioni seguenti. Un certificato jolly si applica al dominio o sottodominio e a tutti i suoi sottodomini. ### Impedire a qualsiasi CA di emettere un certificato per un dominio o sottodominio Per impedire a una CA di rilasciare un certificato jolly per un dominio o sottodominio, devi creare un record con lo stesso nome del dominio o del sottodominio e specificare le impostazioni seguenti: + **flag** - `0` + **tag** - `issue` + **Valore** - `";"` Ad esempio, supponiamo che non desideri che una CA emetta un certificato per esempio.com. Devi creare un record CAA per esempio.com con le impostazioni seguenti: `0 issue ";"` Se non desideri che una CA rilasci un certificato per esempio.com o i suoi sottodomini, devi creare un record CAA per esempio.com con le impostazioni seguenti: `0 issuewild ";"` **Nota** Se crei un record CAA per esempio.com e specifichi entrambi i seguenti valori, una CA che utilizza il valore ca.esempio.net può emettere il certificato per esempio.com: ``` 0 issue ";" 0 issue "ca.example.net" ``` ### Richiedere che una CA ti contatti se riceve una richiesta di certificato non valida Se desideri che una CA che riceve una richiesta non valida per un certificato ti contattati, specifica le impostazioni seguenti: + **flag** - `0` + **tag** - `iodef` + **value**: l'URL o l'indirizzo e-mail a cui desideri che la CA ti informi nel caso in cui riceve una richiesta non valida per un certificato. Utilizza il formato pertinente: `"mailto:email-address"` `"http://URL"` `"https://URL"` Ad esempio, se desidera che una CA che riceve una richiesta non valida per un certificato invii e-mail ad admin@esempio.com, devi creare un record CAA con le impostazioni seguenti: ``` 0 iodef "mailto:admin@example.com" ``` ### Utilizzare un'altra impostazione supportata dalla CA Se la tua CA supporta una funzionalità che non è ancora definita nella RFC per i record CAA, specifica le impostazioni seguenti: + **flags**: 128 (tale valore impedisce alla CA di rilasciare un certificato se non supporta la funzionalità specificata.) + **tag**: il tag che autorizzi la CA a utilizzare + **value**: il valore corrispondente al valore del tag Ad esempio, supponiamo che la tua CA supporti l'invio di un messaggio di testo se la CA riceve una richiesta di certificato non valida. (Non siamo a conoscenza di nessuno CAs che supporti questa opzione). Le impostazioni per il record potrebbero essere le seguenti: ``` 128 exampletag "15555551212" ``` ### Esempi **Esempio per la console Route 53** ``` 0 issue "ca.example.net" 0 iodef "mailto:admin@example.com" ``` **Esempio per l'API Route 53** ``` 0 issue "ca.example.net" 0 iodef "mailto:admin@example.com" ``` ## Tipo di record CNAME Un record CNAME associa le query DNS relative al nome del record corrente, ad esempio acme.example.com, a un altro dominio (example.com o example.net) o sottodominio (acme.example.com o zenith.example.org). **Importante** Il protocollo DNS non consente di creare un record CNAME per il nodo di primo livello di uno spazio di nomi DNS, noto anche come apex di zona. Ad esempio, se record il nome DNS esempio.com, l'apex di zona è esempio.com. Non puoi creare un record CNAME per esempio.com, ma puoi creare più record CNAME per www.esempio.com, nuovoprodotto.esempio.com e così via. Inoltre, se crei un record CNAME per un sottodominio, non puoi creare qualsiasi altro record per quel sottodominio. Ad esempio, se si crea un CNAME per www.example.com, non è possibile creare altri record per i quali il valore del campo **Name (Nome)** è www.example.com. Amazon Route 53 supporta anche i record di alias, che consentono di indirizzare le query a AWS risorse selezionate, come CloudFront distribuzioni e bucket Amazon S3. Gli alias sono simili in alcuni modi al tipo di record CNAME; tuttavia, puoi creare un alias per l'apex di zona. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Esempio per la console Route 53** ``` hostname.example.com ``` **Esempio per l'API Route 53** ``` hostname.example.com ``` ## Tipo di record DS Un record del firmatario della delega (DS) fa riferimento a una chiave di zona per una zona di sottodominio delegata. È possibile creare un record DS quando si stabilisce una catena di attendibilità quando si configura la firma DNSSEC. Per ulteriori informazioni sulla configurazione di DNSSEC in Route 53, consulta [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md). I primi tre valori sono numeri decimali che rappresentano il tag della chiave, l'algoritmo e il tipo di digest. Il quarto valore è il digest della chiave di zona. Per ulteriori informazioni sul formato dei record DS, consulta [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt). **Esempio per la console Route 53** ``` 123 4 5 1234567890abcdef1234567890absdef ``` **Esempio per l'API Route 53** ``` 123 4 5 1234567890abcdef1234567890absdef ``` ## Tipo di record HTTPS Un record di risorse HTTPS è una forma del record DNS Service Binding (SVCB) che fornisce informazioni di configurazione estese, consentendo a un client di connettersi in modo semplice e sicuro a un servizio con un protocollo HTTP. Le informazioni di configurazione sono fornite in parametri che consentono la connessione in un'unica query DNS, anziché richiedere più query DNS. Il formato per un record di risorse HTTPS è: `SvcPriority TargetName SvcParams(optional)` I seguenti parametri sono descritti nella [RFC 9460, sezione](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1) 9.1. **SvcPriority** Un numero intero che rappresenta la priorità. La priorità 0 indica la modalità alias ed è generalmente destinata all'alias all'apice della zona. Questo valore è un numero intero 0-32767 per Route 53, di cui 1-32767 sono record in modalità servizio. Riduci la priorità, aumenta la preferenza. **TargetName** Il nome di dominio della destinazione dell'alias (per la modalità alias) o dell'endpoint alternativo (per). ServiceMode **SvcParams (facoltativo)** Un elenco separato da spazi bianchi, con ogni parametro costituito da una coppia Chiave=Valore o da una chiave autonoma. Se sono presenti più valori, questi vengono presentati come un elenco separato da virgole. I seguenti sono i definiti: SvcParams + `1:alpn`— Protocollo di negoziazione del protocollo a livello di applicazione. IDs L'impostazione predefinita è HTTP/1.1, `h2` è HTTP/2 su TLS e HTTP/3 (protocollo HTTP su `h3` QUIC). + `2:no-default-alpn`— L'impostazione predefinita non è supportata ed è necessario fornire un parametro. `alpn` + `3:port`— l'endpoint alternativo o la porta da cui è possibile raggiungere il servizio. + `4:ipv4hint`— suggerimenti sugli IPv4 indirizzi. + `5:ech`— Client crittografato Hello. + `6:ipv6hint`— suggerimenti IPv6 sugli indirizzi. + `7:dohpath`— Modello DNS su HTTPS + `8:ohttp`— Il servizio gestisce un target HTTP Oblivious **Esempio di console Amazon Route 53 per la modalità alias** ``` 0 example.com ``` **Esempio di console Amazon Route 53 per la modalità di servizio** ``` 16 example.com alpn="h2,h3" port=808 ``` **Esempio dell'API Amazon Route 53 per la modalità alias** ``` 0 example.com ``` **Esempio dell'API Route 53 per la modalità di servizio** ``` 16 example.com alpn="h2,h3" port=808 ``` Per ulteriori informazioni, vedere [RFC 9460, Service Binding and Parameter Specification tramite DNS (SVCB e](https://datatracker.ietf.org/doc/html/rfc9460) HTTPS Resource Records). **Nota** Route 53 non supporta il formato arbitrario di presentazione a chiave sconosciuta `keyNNNNN` ## Tipo di record MX Un record MX specifica i nomi dei server di posta e, se si dispone di due o più server di posta, l'ordine di priorità. Ogni valore di un record MX include due valori: priorità e nome del dominio. **Priorità** Numero intero che rappresenta le priorità per un server di e-mail. Se specifichi solo un server, la priorità può essere un valore intero compreso tra 0 e 65535. Se specifichi più server, il valore specificato per la priorità indica per quali server e-mail desideri indirizzare le e-mail al primo, al secondo e così via. Il server con il valore più basso per la priorità ha la precedenza. Ad esempio, se disponi di due server e-mail e specifichi valori di 10 e 20 per la priorità, l'e-mail viene sempre inviata al server con una priorità di 10 a meno che non sia disponibile. Se specifichi valori di 10 e 10, l'e-mail viene instradata ai due server in modo praticamente uguale. **Nome dominio** Il nome di dominio del server e-mail. Specifica il nome (ad esempio mail.esempio.com) di un record A o AAAA. In [RFC 2181, chiarimenti per la specifica DNS](https://tools.ietf.org/html/rfc2181), la sezione 10.3 proibisce di specificare il nome di un record CNAME per il valore del nome di dominio. (Quando RFC cita "alias", significa un record CNAME, non un record alias di Route 53.) **Esempio per la console Amazon Route 53** ``` 10 mail.example.com ``` **Esempio per l'API Route 53** ``` 10 mail.example.com ``` ## Tipo di record NAPTR Un Name Authority Pointer (NAPTR) è un tipo di record utilizzato dalle applicazioni DDDS (Dynamic Delegation Discovery System) per convertire un valore in un altro valore o per sostituire un valore con un altro. Ad esempio, un uso comune è quello di convertire i numeri di telefono in SIP. URIs L'elemento `Value` per un record NAPTR consiste in sei valori separati da spazio: **Order** Quando specifichi più di un record, la sequenza con cui desideri che l'applicazione DDDS valuti i record. Valori validi: 0-65535. **Preferenza** Quando specifichi due o più record con lo stesso **Order (Ordine)**, le tue preferenze per la sequenza in cui questi record verranno valutati. Ad esempio, se due record hanno un **Order (Ordine)** di 1, l'applicazione DDDS prima valuta il record che ha la **Preference (Preferenza)** più bassa. Valori validi: 0-65535. **Flag** Impostazione specifica per le applicazioni DDDS. I valori attualmente definiti in [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) sono composti da lettere maiuscole e minuscole **"A"**, **"P"**, **"S"** e **"U"**, e dalla stringa vuota, **""**. Includi **Flags (Flag)** tra virgolette. **Servizio** Impostazione specifica per le applicazioni DDDS. Includi **Service (Servizio)** tra virgolette. Per ulteriori informazioni, consulta la pagina pertinente RFCs: + **Applicazione URI DDDS** — [https://tools.ietf.org/html/rfc3404](https://tools.ietf.org/html/rfc3404#section-4.4) \$1section -4.4 + **[Applicazione DDDS S-NAPTR — /rfc3958 \$1section -6.5 https://tools.ietf.org/html](https://tools.ietf.org/html/rfc3958#section-6.5)** + **Applicazione DDDS U-NAPTR** — [https://tools.ietf.org/html/rfc4848 \$1section -4.5](https://tools.ietf.org/html/rfc4848#section-4.5) **Regexp** Un'espressione regolare che l'applicazione DDDS impiega per convertire un valore di input in un valore di output. Ad esempio, un sistema telefonico IP potrebbe utilizzare un'espressione regolare per convertire un numero di telefono immesso da un utente in un URI SIP. Includi **Regexp** tra virgolette. Specifica un valore per **Regexp** o un valore per **Replacement (Sostituzione)**, ma non entrambi. L'espressione regolare può includere i seguenti caratteri ASCII stampabili: + a-z + 0-9 + - (trattino) + (spazio) + \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 . + " (virgolette). Per includere virgolette in una stringa, è necessario anteporre un \$1 carattere: \$1". + \$1 (barra rovesciata). Per includere una barra rovesciata in una stringa, è necessario anteporre un \$1 carattere: \$1\$1". Specifica tutti gli altri valori, ad esempio i nomi di dominio internazionalizzati, in formato ottale. Per la sintassi di **Regexp**, consulta la [RFC 3402, sezione 3.2 Sintassi di espressione sostitutiva](https://tools.ietf.org/html/rfc3402#section-3.2) **Sostituzione** Il nome di dominio completo del prossimo nome di dominio per cui desideri che l'applicazione DDDS invii una query DNS. L'applicazione DDDS sostituisce il valore di input con il valore specificato per **Replacement (Sostituzione)**. Specifica un valore per **Regexp** o un valore per **Replacement (Sostituzione)**, ma non entrambi. Se specifichi un valore per **Regexp**, specifica un punto (**.**) per **Replacement (Sostituzione)**. Il nome di dominio può includere a-z, 0-9 e - (trattino). Per ulteriori informazioni sulle applicazioni DDDS e sui record NAPTR, vedere quanto segue: RFCs + [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt) + [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt) + [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt) + [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) **Esempio per la console Amazon Route 53** ``` 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" . ``` **Esempio per l'API Route 53** ``` 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" . ``` ## Tipo di record NS Un record NS identifica i server di nomi per la zona ospitata. Tieni presente quanto segue: + Un record NS viene utilizzato il più delle volte per controllare la modalità di instradamento del traffico Internet per un dominio. Se si desidera utilizzare i record in una zona ospitata per instradare il traffico per un dominio, è possibile aggiornare le impostazioni di registrazione del dominio per utilizzare i quattro server dei nomi nel record NS predefinito (si tratta del record NS che ha lo stesso nome della zona ospitata). + È possibile creare una zona ospitata separata per un sottodominio (acme.example.com) e utilizzarla per instradare il traffico Internet per il sottodominio e i relativi sottodomini (subdomain.acme.example.com). È possibile impostare questa configurazione, nota come “delegazione della responsabilità di un sottodominio a una zona ospitata”, creando un altro record NS nella zona ospitata per il dominio radice (example.com). Per ulteriori informazioni, consulta [Routing del traffico per sottodomini](dns-routing-traffic-for-subdomains.md). + È inoltre possibile utilizzare i record NS per configurare i server dei nomi white label. Per ulteriori informazioni, consulta [Configurazione dei server di nomi white label](white-label-name-servers.md). + Un altro utilizzo di un record NS è per le zone ospitate private, quando si crea una regola di delega per delegare l'autorità di un sottodominio al resolver locale. È necessario creare questo record NS prima di creare una regola di delega. Per ulteriori informazioni, consulta [In che modo gli endpoint Resolver inoltrano le query DNS dall'utente alla rete VPCs](resolver-overview-forward-vpc-to-network.md). Per ulteriori informazioni sui record NS, consulta [Record NS e SOA creati da Amazon Route 53 per una zona ospitata pubblica](SOA-NSrecords.md). **Esempio per la console Amazon Route 53** ``` ns-1.example.com ``` **Esempio per l'API Route 53** ``` ns-1.example.com ``` ## Tipo di record PTR Un record PTR associa un indirizzo IP al nome di dominio corrispondente. **Esempio per la console Amazon Route 53** ``` hostname.example.com ``` **Esempio per l'API Route 53** ``` hostname.example.com ``` ## Tipo di record SOA Un record di origine di autorità (SOA) fornisce informazioni su un dominio e la zona ospitata Amazon Route 53 corrispondente. Per ulteriori informazioni sui campi in un record SOA, consulta [Record NS e SOA creati da Amazon Route 53 per una zona ospitata pubblica](SOA-NSrecords.md). **Esempio per la console Route 53** ``` ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60 ``` **Esempio per l'API Route 53** ``` ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60 ``` ## Tipo di record SPF I record SPF erano precedentemente usati per verificare l'identità del mittente di messaggi e-mail. Tuttavia, non è più consigliabile creare record per i quali il tipo di record è SPF. La RFC 7208, *Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, versione 1,* è stata aggiornata per dire: «... [La] sua esistenza e il meccanismo definiti in [RFC4408] hanno portato ad alcuni problemi di interoperabilità. Di conseguenza, il suo utilizzo non è più appropriato per SPF versione 1; le implementazioni non devono utilizzarlo." In RFC 7208, consulta la sezione 14.1, [Tipo record DNS SPF](http://tools.ietf.org/html/rfc7208#section-14.1). Invece di un record SPF, è consigliabile creare un record TXT che contiene il valore applicabile. Per ulteriori informazioni sui valori validi, consulta l'articolo Wikipedia [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework). **Esempio per la console Amazon Route 53** ``` "v=spf1 ip4:192.168.0.1/16 -all" ``` **Esempio per l'API Route 53** ``` "v=spf1 ip4:192.168.0.1/16 -all" ``` ## Tipo di record SRV Un record `Value` SRV consiste in quattro valori separati da spazio. I primi tre valori sono numeri decimali con priorità, peso e porta. Il quarto valore è un nome di dominio. I record SRV vengono utilizzati per accedere a servizi, ad esempio un servizio per e-mail o comunicazioni. Per informazioni sul formato dei record SRV, consulta la documentazione relativa al servizio a cui desideri connetterti. **Esempio per la console Amazon Route 53** ``` 10 5 80 hostname.example.com ``` **Esempio per l'API Route 53** ``` 10 5 80 hostname.example.com ``` ## Tipo di record SSHFP Un record di impronte digitali Secure Shell (SSHFP) identifica le chiavi SSH associate al nome di dominio. I record SSHFP devono essere protetti con DNSSEC per stabilire una catena di fiducia. Per ulteriori informazioni su DNSSEC, vedere [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md) Il formato per un record di risorse SSHFP è: `[Key Algorithm] [Hash Type] Fingerprint` [I seguenti parametri sono definiti nella RFC 4255.](https://datatracker.ietf.org/doc/html/rfc4255) **Algoritmo chiave** Tipo di algoritmo: + `0`— Riservato e non utilizzato. + `1: RSA`— L'algoritmo Rivest-Shamir-Adleman è uno dei primi sistemi crittografici a chiave pubblica ed è ancora utilizzato per la trasmissione sicura dei dati. + `2: DSA`— L'algoritmo di firma digitale è uno standard federale di elaborazione delle informazioni per le firme digitali. Il DSA si basa sull'esponenziazione modulare e sui modelli matematici a logaritmi discreti. + `3: ECDSA`— Elliptic Curve Digital Signature Algorithm è una variante del DSA che utilizza la crittografia a curva ellittica. + `4: Ed25519`— L'algoritmo Ed25519 è lo schema di firma EdDSA che utilizza SHA-512 (SHA-2) e Curve25519. + `6: Ed448`— Ed448 è lo schema di firma EdDSA che utilizza e Curve448. SHAKE256 **Tipo di hash** Algoritmo utilizzato per creare l'hash della chiave pubblica: + `0`—Riservato e non utilizzato. + `1: SHA-1` + `2: SHA-256` **Impronta digitale** Rappresentazione esadecimale dell'hash. **Esempio per la console Amazon Route 53** ``` 1 1 09F6A01D2175742B257C6B98B7C72C44C4040683 ``` **Esempio per l'API Route 53** ``` 1 1 09F6A01D2175742B257C6B98B7C72C44C4040683 ``` Per ulteriori informazioni, vedere [RFC 4255: Utilizzo del DNS per pubblicare in modo sicuro le impronte digitali delle chiavi Secure Shell](https://datatracker.ietf.org/doc/html/rfc4255) (SSH). ## Tipo di record SVCB Si utilizza un record SVCB per fornire informazioni di configurazione per l'accesso agli endpoint del servizio. SVCB è un record DNS generico e può essere utilizzato per negoziare i parametri per una varietà di protocolli applicativi. Il formato per un record di risorse SVCB è: `SvcPriority TargetName SvcParams(optional)` I seguenti parametri sono descritti nella [RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3), sezione 2.3. **SvcPriority** Un numero intero che rappresenta la priorità. La priorità 0 indica la modalità alias ed è generalmente destinata all'alias all'apice della zona. Abbassa la priorità, aumenta la preferenza. **TargetName** Il nome di dominio della destinazione dell'alias (per la modalità alias) o dell'endpoint alternativo (per). ServiceMode **SvcParams (facoltativo)** Un elenco separato da spazi bianchi, con ogni parametro costituito da una coppia Chiave=Valore o da una chiave autonoma. Se sono presenti più valori, questi vengono presentati come un elenco separato da virgole. Questo valore è un numero intero 0-32767 per la Route 53, di cui 1-32767 sono record in modalità servizio. I seguenti sono i definiti: SvcParams + `1:alpn`— Protocollo di negoziazione del protocollo a livello di applicazione. IDs L'impostazione predefinita è HTTP/1.1, `h2` è HTTP/2 su TLS e HTTP/3 (protocollo HTTP su `h3` QUIC). + `2:no-default-alpn`— L'impostazione predefinita non è supportata ed è necessario fornire un parametro. `alpn` + `3:port`— la porta per l'endpoint alternativo in cui è possibile raggiungere il servizio. + `4:ipv4hint`— suggerimenti sugli IPv4 indirizzi. + `5:ech`— Client crittografato Hello. + `6:ipv6hint`— suggerimenti IPv6 sugli indirizzi. + `7:dohpath`— Modello DNS su HTTPS + `8:ohttp`— Il servizio gestisce un target HTTP Oblivious **Esempio di console Amazon Route 53 per la modalità alias** ``` 0 example.com ``` **Esempio di console Amazon Route 53 per la modalità di servizio** ``` 16 example.com alpn="h2,h3" port=808 ``` **Esempio dell'API Amazon Route 53 per la modalità alias** ``` 0 example.com ``` **Esempio dell'API Route 53 per la modalità di servizio** ``` 16 example.com alpn="h2,h3" port=808 ``` Per ulteriori informazioni, vedere [RFC 9460, Service Binding and Parameter Specification tramite DNS (SVCB e](https://datatracker.ietf.org/doc/html/rfc9460) HTTPS Resource Records). **Nota** Route 53 non supporta il formato arbitrario di presentazione a chiave sconosciuta `keyNNNNN` ## Tipo di record TLSA Si utilizza un record TLSA per utilizzare l'autenticazione delle entità denominate (DANE) basata su DNS. Un record TLSA associa una certificate/public chiave a un endpoint Transport Layer Security (TLS) e i client possono convalidare la chiave utilizzando un record TLSA firmato con DNSSEC. certificate/public I record TLSA possono essere considerati attendibili solo se DNSSEC è abilitato sul dominio. Per ulteriori informazioni su DNSSEC, vedere [Configurazione della firma DNSSEC in Amazon Route 53](dns-configuring-dnssec.md) Il formato per un record di risorse TLSA è: `[Certificate usage] Selector [Matching type] [Certificate association data]` I seguenti parametri sono specificati nella [RFC 6698, sezione 3](https://datatracker.ietf.org/doc/html/rfc6698#section-3). **Utilizzo del certificato** Speciifica l'associazione fornita che verrà utilizzata per abbinare il certificato presentato nell'handshake TLS: + 0: vincolo CA: il certificato o la chiave pubblica devono essere trovati in uno qualsiasi dei percorsi di certificazione PKIX (Public Key Infrastructure) per il certificato dell'entità finale fornito dal server in TLS. Questo vincolo limita i dati che CAs possono essere utilizzati per emettere certificati per un servizio specifico. + 1: Vincolo del certificato di entità finale: specifica un certificato di entità finale (o la chiave pubblica) che deve corrispondere al certificato dell'entità finale fornito dal server in TLS. Questa certificazione limita il certificato dell'entità finale che può essere utilizzato da un servizio specifico su un host. + 2: Un'asserzione di trust Anchor: specifica un certificato (o la chiave pubblica) che deve essere utilizzato come «trust anchor» durante la convalida del certificato di entità finale fornito dal server in TLS. Consente a un amministratore di dominio di specificare un trust anchor. + 3: Certificazione rilasciata dal dominio: specifica un certificato (o la chiave pubblica) che deve corrispondere al certificato dell'entità finale fornito dal server in TLS. Questa certificazione consente a un amministratore di dominio di emettere certificati per un dominio senza coinvolgere una CA di terze parti. Non è necessario che questo certificato superi la convalida PKIX. **Selector** Speciifica quale parte del certificato presentato dal server nell'handshake corrisponde al valore dell'associazione: + 0: è necessario abbinare l'intero certificato. + 1: La chiave pubblica del soggetto, o la struttura binaria con codifica DER, deve corrispondere. **Tipo corrispondente** Speciifica la presentazione (come determinata dal campo Selector) della corrispondenza del certificato: + 0: Corrispondenza esatta del contenuto. + 1: hash SHA-256. + 2: hash SHA-512. **Dati di associazione dei certificati** I dati da abbinare in base alle impostazioni degli altri campi. **Esempio per la console Amazon Route 53** ``` 0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 ``` **Esempio per l'API Route 53** ``` 0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 ``` Per ulteriori informazioni, vedere [RFC 6698, The DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol](https://datatracker.ietf.org/doc/html/rfc6698): TLSA. ## Tipo di record TXT Un record TXT contiene una o più stringhe racchiuse tra virgolette (`"`). Quando utilizzi la [policy di routing](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) semplice, includi tutti i valori per un dominio (esempio.com) o sottodominio (www.esempio.com) nello stesso record TXT. **Topics** + [Inserimento dei valori del record TXT](#TXTformat-limits) + [Caratteri speciali in un valore di record TXT](#TXTformat-special-characters) + [Maiuscole e minuscole in un valore di record TXT](#TXTformat-case) + [Esempi](#TXTformat-examples) ### Inserimento dei valori del record TXT Una singola stringa può includere fino a 255 caratteri, tra cui i seguenti: + a-z + A-Z + 0-9 + Spazio + - (trattino) + \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 . Se è necessario immettere un valore più lungo di 255 caratteri, suddividere il valore in stringhe di 255 caratteri o numero inferiore e racchiudere ogni stringa tra virgolette doppie (`"`). Nella console, elencare tutte le stringhe sulla stessa riga: ``` "String 1" "String 2" "String 3" ``` Per l'API, includere tutte le stringhe nello stesso elemento `Value`: ``` "String 1" "String 2" "String 3" ``` La lunghezza massima di un valore in un record TXT è di 4.000 caratteri. Per inserire più di un valore TXT, inserisci un valore per riga. ### Caratteri speciali in un valore di record TXT Se il record TXT contiene uno dei seguenti caratteri, è necessario specificare i caratteri utilizzando i codici di escape nel formato: `\` *three-digit octal code* + Caratteri da 000 a 040 ottali (da 0 a 32 decimali, da 0x00 a 0x20 esadecimali) + Caratteri da 177 a 377 ottali (da 127 a 255 decimali, da 0x7F a 0xFF esadecimali) Ad esempio, se il valore del tuo record TXT è `"exämple.com"`, devi specificare `"ex\344mple.com"`. Per una mappatura tra caratteri ASCII e codici ottali, esegui una ricerca su Internet per «codici ottali ASCII». Un utile riferimento è la [tabella estesa dei codici ASCII](https://www.ascii-code.com/). Per includere le virgolette (`"`) in una stringa, inserisci una barra rovesciata (`\`) prima della virgoletta: `\"`. ### Maiuscole e minuscole in un valore di record TXT Maiuscole e minuscole vengono mantenute, perciò `"Ab"` e `"aB"` sono valori diversi. ### Esempi **Esempio per la console Amazon Route 53** Immetti ogni valore su una riga distinta: ``` "This string includes \"quotation marks\"." "The last character in this string is an accented e specified in octal format: \351" "v=spf1 ip4:192.168.0.1/16 -all" ``` **Esempio per l'API Route 53** Immetti ogni valore in un elemento `Value` separato: ``` "This string includes \"quotation marks\"." "The last character in this string is an accented e specified in octal format: \351" "v=spf1 ip4:192.168.0.1/16 -all" ``` # Creazione di record utilizzando la console Amazon Route 53 La procedura seguente spiega come creare record utilizzando la console Amazon Route 53. Per informazioni su come creare record utilizzando l'API Route 53, consulta [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)*Amazon Route 53 API Reference*. **Nota** Per creare record per configurazioni di routing complesse, puoi anche utilizzare l'editor visivo Traffic Flow e salvare la configurazione come policy sul traffico. Puoi quindi associare la policy di traffico a uno o più nomi di dominio (ad esempio esempio.com) o nomi di sottodominio (ad esempio www.esempio.com), nella stessa zona ospitata o in più zone ospitate. Inoltre, puoi eseguire il roll back degli aggiornamenti se la nuova configurazione non offre le prestazioni previste. Per ulteriori informazioni, consulta [Utilizzo di Traffic Flow per instradare il traffico DNS](traffic-flow.md). **Come creare un record mediante la console Route 53** 1. Se non stai creando un record alias, passa al punto 2. Vai anche al passaggio 2 se stai creando un record di alias che indirizza il traffico DNS verso una AWS risorsa diversa da un sistema di bilanciamento del carico Elastic Load Balancing o un altro record Route 53. Quando crei un record alias che instrada il traffico a un sistema di bilanciamento del carico Elastic Load Balancing, se hai creato la zona ospitata e il sistema di bilanciamento del carico utilizzando account diversi, esegui la procedura [Come ottenere il nome DNS per un sistema di bilanciamento del carico Elastic Load Balancing](#resource-record-sets-elb-dns-name-procedure) per ottenere il nome DNS per il sistema di bilanciamento del carico. 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**. 1. Se si dispone già di una zona ospitata per il dominio, passare alla fase 5. In caso contrario, eseguire la procedura applicabile per creare una zona ospitata: + Per instradare il traffico Internet alle risorse, ad esempio bucket Amazon S3 o istanze Amazon EC2, consulta [Creazione di una zona ospitata pubblica](CreatingHostedZone.md). + Per instradare il traffico nel VPC, consulta [Creazione di una zona ospitata privata](hosted-zone-private-creating.md). 1. Nella pagina **Zone ospitate**, scegli il nome della zona ospitata in cui desideri creare i record. 1. Scegli **Crea record**. 1. Scegli e definisci la policy di routing e i valori applicabili. Per ulteriori informazioni, consulta l'argomento per il tipo di record che desideri creare: + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) + [Valori specifici per record semplici](resource-record-sets-values-basic.md) + [Valori specifici per record alias semplici](resource-record-sets-values-alias.md) + [Valori specifici per record di failover](resource-record-sets-values-failover.md) + [Valori specifici per i record alias di failover](resource-record-sets-values-failover-alias.md) + [Valori specifici per record di geolocalizzazione](resource-record-sets-values-geo.md) + [Valori specifici per record degli alias di geolocalizzazione](resource-record-sets-values-geo-alias.md) + [Valori specifici per i record di geoprossimità](resource-record-sets-values-geoprox.md) + [Valori specifici per i record di alias di geoprossimità](resource-record-sets-values-geoprox-alias.md) + [Valori specifici per i record di latenza](resource-record-sets-values-latency.md) + [Valori specifici per i record alias di latenza](resource-record-sets-values-latency-alias.md) + [Valori specifici per i record basati su IP](resource-record-sets-values-ipbased.md) + [Valori specifici per i record alias basati su IP](resource-record-sets-values-ipbased-alias.md) + [Valori specifici per record di risposta multivalore](resource-record-sets-values-multivalue.md) + [Valori specifici per record ponderati](resource-record-sets-values-weighted.md) + [Valori specifici per i record alias ponderati](resource-record-sets-values-weighted-alias.md) 1. Scegli **Crea record**. **Nota** I tuoi nuovi record richiedono tempo per propagarsi ai server DNS di Route 53. Attualmente, l'unico modo per verificare che le modifiche si siano propagate è utilizzare l'azione [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi. 1. Se stai creando più record, ripeti le fasi da 7 a 8. **Come ottenere il nome DNS per un sistema di bilanciamento del carico Elastic Load Balancing** 1. Accedi Console di gestione AWS utilizzando l' AWS account utilizzato per creare il Classic, Application o Network Load Balancer per cui desideri creare un record di alias. 1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Selezionare **Sistemi di bilanciamento del carico** nel riquadro di navigazione. 1. Nell'elenco dei sistemi di load balancer, seleziona il load balancer per cui desideri creare un record alias. 1. Nella scheda **Description (Descrizione)**, ottieni il valore di **DNS name (Nome DNS)**. 1. Se desideri creare record alias per altri sistemi di bilanciamento del carico Elastic Load Balancing, ripeti i passaggi 4 e 5. 1. Esci da. Console di gestione AWS 1. Accedi Console di gestione AWS nuovamente utilizzando l' AWS account che hai usato per creare la zona ospitata da Route 53. 1. Torna al passo 3 della procedura [Creazione di record utilizzando la console Amazon Route 53](#resource-record-sets-creating). # Autorizzazioni del set di record di risorse Le autorizzazioni relative ai set di record di risorse utilizzano le condizioni delle policy di gestione delle identità e degli accessi (IAM) per consentire di impostare autorizzazioni granulari per le azioni sulla console Route 53 o per l'utilizzo dell'API. [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) Un set di record di risorse è definito come più record di risorse con lo stesso nome e tipo (e classe, ma per la maggior parte degli scopi la classe è sempre IN o Internet) che contengono però dati diversi. Ad esempio, se scegli l'instradamento basato sulla geolocalizzazione, puoi avere più record A o AAAA che puntano a endpoint diversi per lo stesso dominio. Tutti questi record A o AAAA si combinano per formare un set di record di risorse. Per ulteriori informazioni sulla terminologia DNS, consulta [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719). Con le condizioni delle policy IAM,`route53:ChangeResourceRecordSetsNormalizedRecordNames`, and `route53:ChangeResourceRecordSetsRecordTypes``route53:ChangeResourceRecordSetsActions`, puoi concedere diritti amministrativi granulari ad altri AWS utenti in qualsiasi altro account. AWS Ciò consente di concedere a qualcuno le autorizzazioni per: + Un singolo set di record di risorse. + Tutti i set di record di risorse di un tipo di record DNS specifico. + Set di record di risorse in cui i nomi contengono una stringa specifica. + Esegui alcune o tutte le `CREATE | UPSERT | DELETE ` azioni quando usi l'[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API o la console Route 53. Puoi anche creare autorizzazioni di accesso che combinano qualsiasi condizione delle policy di Route 53. Ad esempio, puoi concedere a qualcuno le autorizzazioni per modificare i dati del record A per marketing-example.com, ma non consentire all'utente di eliminare i record. Per ulteriori informazioni sulle autorizzazioni relative ai set di record di risorse ed esempi su come utilizzarle, consulta[Utilizzo di condizioni di policy IAM per il controllo granulare degli accessi](specifying-conditions-route53.md). Per informazioni su come autenticare AWS gli utenti, consulta [Autenticazione con identità](security-iam.md#security_iam_authentication) e per imparare a controllare l'accesso alle risorse di Route 53, consulta. [Controllo accessi](security-iam.md#access-control) # Di seguito sono descritti i valori che devi specificare durante la creazione o la modifica di record di Amazon Route 53. Quando crei record utilizzando la console Amazon Route 53, i valori specificati dipendono dalla politica di routing che desideri utilizzare e dal fatto che tu stia creando record di alias, che indirizzano il traffico verso AWS le risorse. Record di alias che indirizzano il traffico verso determinate AWS risorse per le quali si specifica la risorsa di destinazione (ad esempio, Elastic Load Balancing CloudFront , distribuzione, bucket Amazon S3). Facoltativamente, puoi anche associare i controlli di integrità e configurare la valutazione dello stato dell'obiettivo. I seguenti argomenti forniscono informazioni dettagliate sui valori richiesti per ogni politica di routing e tipo di record, aiutandoti a configurare i record della Route 53 in modo efficace. **Topics** + [Valori comuni per tutte le policy di routing](resource-record-sets-values-shared.md) + [Valori comuni per i record alias per tutte le policy di routing](resource-record-sets-values-alias-common.md) + [Valori specifici per record semplici](resource-record-sets-values-basic.md) + [Valori specifici per record alias semplici](resource-record-sets-values-alias.md) + [Valori specifici per record di failover](resource-record-sets-values-failover.md) + [Valori specifici per i record alias di failover](resource-record-sets-values-failover-alias.md) + [Valori specifici per record di geolocalizzazione](resource-record-sets-values-geo.md) + [Valori specifici per record degli alias di geolocalizzazione](resource-record-sets-values-geo-alias.md) + [Valori specifici per i record di geoprossimità](resource-record-sets-values-geoprox.md) + [Valori specifici per i record di alias di geoprossimità](resource-record-sets-values-geoprox-alias.md) + [Valori specifici per i record di latenza](resource-record-sets-values-latency.md) + [Valori specifici per i record alias di latenza](resource-record-sets-values-latency-alias.md) + [Valori specifici per i record basati su IP](resource-record-sets-values-ipbased.md) + [Valori specifici per i record alias basati su IP](resource-record-sets-values-ipbased-alias.md) + [Valori specifici per record di risposta multivalore](resource-record-sets-values-multivalue.md) + [Valori specifici per record ponderati](resource-record-sets-values-weighted.md) + [Valori specifici per i record alias ponderati](resource-record-sets-values-weighted-alias.md) # Valori comuni per tutte le policy di routing Questi sono i valori comuni che puoi specificare durante la creazione o la modifica di record di Amazon Route 53. Questi valori sono utilizzati da tutte le policy di routing. **Topics** + [Nome record](#rrsets-values-common-name) + [Valore/instradamento traffico a](#rrsets-values-common-value) + [TTL (secondi)](#rrsets-values-common-ttl) ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. **Registri CNAME** Se stai creando un record che ha lo stesso valore di **CNAME** per **Tipo di record**, il nome del record non può essere uguale al nome della zona ospitata. **Caratteri speciali** Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). **Caratteri jolly** Puoi utilizzare un asterisco (\$1) all'interno del nome. Il DNS considera il carattere \$1 sia come un carattere jolly che come il carattere \$1 (ASCII 42), a seconda della posizione nel nome. Per ulteriori informazioni, consulta [Utilizza un asterisco (\$1) nei nomi di zone ospitate e registri](DomainNameFormat.md#domain-name-format-asterisk). Non puoi utilizzare il carattere jolly \$1 per set di record della risorsa che sono di tipo **NS**. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. **A — IPv4 indirizzo** Un indirizzo IP in IPv4 formato, ad esempio **192.0.2.235**. **AAAA: IPv6 indirizzo** Un indirizzo IP in IPv6 formato, ad esempio, **2001:0 db 8:85 a 3:0:0:8 a2e: 0370:7334**. **CAA - Autorizzazione della certification authority** Tre valori separati da spazi che determinano le autorità di certificazione a cui è consentito emettere certificati o certificati con caratteri jolly per il dominio o il sottodominio specificato da **Nome record**. Puoi utilizzare i record CAA per specificare quanto segue: + Quali CAs autorità SSL/TLS di certificazione () possono emettere certificati, se presenti + L'indirizzo e-mail o l'URL da contattare quando un'autorità di certificazione emette un certificato per il dominio o il sottodominio. **CNAME - Nome canonico** Il nome di dominio completo (come *www.esempio.com*) che Route 53 deve restituire in risposta alle query DNS per questo record. Un punto finale è facoltativo; Route 53 presuppone che il nome dominio sia completo. Ciò significa che Route 53 considera identici *www.esempio.com* (senza un punto finale) e *www.esempio.com.* (con un punto finale). **MX - Scambio di posta** Una priorità e un nome di dominio che specifica un server di posta, ad esempio **10 mailserver.example.com**. Il punto finale viene trattato come facoltativo. **NAPTR - Puntatore dell'autorità dei nomi** Sei impostazioni separate da spazi utilizzate dalle applicazioni DDDS (Dynamic Delegation Discovery System) per convertire un valore in un altro valore o per sostituire un valore con un altro. Per ulteriori informazioni, consulta [Tipo di record NAPTR](ResourceRecordTypes.md#NAPTRFormat). **PTR - Puntatore** Il nome dominio che desideri sia restituito da Route 53. **NS - Server di nomi** Il nome di dominio di un server dei nomi, ad esempio **ns1.example.com**. È possibile specificare un registro NS con solo una policy di routing semplice. **SPF - Sender Policy Framework** Un record SPF racchiuso tra virgolette, ad esempio **"v=spf1 ip4:192.168.0.1/16-all"**. L'utilizzo di record SPF non è consigliato. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). **SRV - Localizzatore di servizi** Un record SRV. I record SRV vengono utilizzati per accedere a servizi, ad esempio un servizio per e-mail o comunicazioni. Per informazioni sul formato dei record SRV, consulta la documentazione relativa al servizio a cui desideri connetterti. Il punto finale viene trattato come facoltativo. Il formato di un record SRV è: **[priority] [weight] [port] [server host name]** Ad esempio: **1 10 5269 xmpp-server.example.com.** **TXT - Testo** Un record di testo. Racchiudi il testo tra virgolette, ad esempio **"Esempio di immissione di testo"**. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. # Valori comuni per i record alias per tutte le policy di routing Questi sono i valori alias comuni che devi specificare durante la creazione o la modifica di record di Amazon Route 53. Questi valori sono utilizzati da tutte le policy di routing. **Topics** + [Nome record](#rrsets-values-common-alias-name) + [Valore/instradamento traffico a](#rrsets-values-alias-common-target) ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. **Registri CNAME** Se stai creando un record che ha lo stesso valore di **CNAME** per **Type (Tipo)**, il nome del record non può essere uguale al nome della zona ospitata. **Alias per CloudFront distribuzioni e bucket Amazon S3** Il valore specificato dipende in parte dalla AWS risorsa verso cui stai instradando il traffico: + **CloudFront distribuzione**: la distribuzione deve includere un nome di dominio alternativo che corrisponda al nome del record. Ad esempio, se il nome del record è **acme.example.com**, la distribuzione CloudFront deve includere **acme.example.com** come uno dei nomi di dominio alternativi. Per ulteriori informazioni, consulta [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) nella *Amazon CloudFront Developer Guide*. + **Bucket Amazon S3**: il nome del record deve corrispondere al nome del bucket Amazon S3. Ad esempio, se il nome del bucket è **acme.example.com**, anche il nome del record deve essere **acme.example.com**. Inoltre, devi configurare il bucket per l'hosting di siti Web. Per ulteriori informazioni, consulta [Configurazione di un bucket per l'hosting di un sito Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) nella *Guida per utenti di Amazon Simple Storage Service*. **Caratteri speciali** Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). **Caratteri jolly** Puoi utilizzare un asterisco (\$1) all'interno del nome. Il DNS considera il carattere \$1 sia come un carattere jolly che come il carattere \$1 (ASCII 42), a seconda della posizione nel nome. Per ulteriori informazioni, consulta [Utilizza un asterisco (\$1) nei nomi di zone ospitate e registri](DomainNameFormat.md#domain-name-format-asterisk). ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). **Importante** Se hai utilizzato lo stesso AWS account per creare la tua zona ospitata e la risorsa verso cui stai indirizzando il traffico e se la risorsa non compare nell'elenco degli **endpoint**, controlla quanto segue: Conferma di aver scelto un valore supportato per **Tipo di record**. I valori supportati sono specifici della risorsa a cui si sta instradando il traffico. **Ad esempio, per indirizzare il traffico verso un bucket S3, devi scegliere **A — IPv4 indirizzo** per Tipo di record.** Confermare che l'account disponga delle autorizzazioni IAM necessarie per elencare le risorse applicabili. Ad esempio, affinché le distribuzioni CloudFront vengano visualizzate nell'elenco **Endpoint**, l'account deve disporre dell'autorizzazione per l’esecuzione della seguente azione: `cloudfront:ListDistributions`. Per un esempio di policy IAM, consultare [Autorizzazioni necessarie per utilizzare la console Amazon Route 53](access-control-managing-permissions.md#console-required-permissions). Se hai utilizzato AWS account diversi per creare la zona ospitata e la risorsa, l'elenco degli **endpoint** non mostra la tua risorsa. Consulta la seguente documentazioni relativa al tipo di risorsa per stabilire il valore da immettere in **Endpoint**. **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Per API Gateway personalizzato, regionale APIs e ottimizzato per i dispositivi perimetrali APIs, effettuate una delle seguenti operazioni: + **Se hai usato lo stesso account per creare la zona ospitata Route 53 e l'API**: scegli **Endpoint**, e seleziona quindi un'API dall'elenco. Se ne hai molti APIs, puoi inserire i primi caratteri dell'endpoint API per filtrare l'elenco. **Nota** Il nome del record che stai creando deve corrispondere a un nome di dominio personalizzato per la tua API, ad esempio **api.example.com**. + **Se hai utilizzato account diversi per creare la tua zona ospitata Route 53 e la tua API**: inserisci l'endpoint dell'API per l'API, ad esempio **api.example.com**. Se hai utilizzato un AWS account per creare la zona ospitata corrente e un account diverso per creare un'API, l'API non verrà visualizzata nell'elenco degli **endpoint** in **API Gateway APIs**. Se hai utilizzato un account per creare la zona ospitata corrente e uno o più account diversi per creare tutti i tuoi APIs, l'elenco degli **endpoint** mostra **Nessun target disponibile** in **API Gateway APIs**. Per ulteriori informazioni, consulta [Routing del traffico a un'API di Amazon API Gateway usando il proprio nome di dominio](routing-to-api-gateway.md). **CloudFront distribuzioni** Per CloudFront le distribuzioni, effettuate una delle seguenti operazioni: + **Se hai utilizzato lo stesso account per creare la zona ospitata su Route 53 e la tua CloudFront distribuzione**, scegli **Endpoint** e scegli una distribuzione dall'elenco. Se disponi di molte distribuzioni, puoi inserire i primi caratteri del nome del dominio per la distribuzione per filtrare l'elenco. Se la distribuzione non appare nell'elenco, tieni presente quanto segue: + Il nome di questo record deve corrispondere a un nome di dominio alternativo nella distribuzione. + Se hai appena aggiunto un nome di dominio alternativo alla tua distribuzione, potrebbero essere necessari 15 minuti prima che le modifiche si propaghino a tutte le CloudFront edge location. Fino a quando le modifiche non si sono propagate, Route 53 non può conoscere il nuovo nome di dominio alternativo. + **Se hai utilizzato account diversi per creare la zona ospitata su Route 53 e la tua distribuzione, inserisci il nome di CloudFront dominio per la distribuzione****, ad esempio d111111abcdef8.cloudfront.net.** **Se hai utilizzato un AWS account per creare la zona ospitata corrente e un account diverso per creare una distribuzione, la distribuzione non verrà visualizzata nell'elenco degli endpoint.** **Se hai utilizzato un account per creare la zona ospitata corrente e uno o più account diversi per creare tutte le distribuzioni, l'elenco degli **endpoint** mostra **Nessun obiettivo disponibile** nelle distribuzioni. CloudFront ** Non indirizzate le query a una CloudFront distribuzione che non si è propagata a tutte le edge location, altrimenti gli utenti non saranno in grado di accedere al contenuto applicabile. La tua CloudFront distribuzione deve includere un nome di dominio alternativo che corrisponda al nome del record. Ad esempio, se il nome del record è **acme.example.com, la CloudFront distribuzione deve includere **acme.example.com**** come uno dei nomi di dominio alternativi. Per ulteriori informazioni, consulta [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) nella *Amazon CloudFront Developer Guide*. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A — IPv4 indirizzo** per il **tipo di record** e uno con un valore di **AAAA — IPv6** indirizzo. Per ulteriori informazioni, consulta [Instradamento del traffico verso una CloudFront distribuzione Amazon utilizzando il tuo nome di dominio](routing-to-cloudfront-distribution.md). **Servizio App Runner** Per il servizio App Runner, esegui una delle seguenti operazioni: + **Se hai utilizzato lo stesso account per creare la zona ospitata su Route 53 e il servizio App Runner** Regione AWS, scegli il, quindi scegli il nome di dominio dell'ambiente verso cui indirizzare il traffico dall'elenco. + **Se hai utilizzato account diversi per creare la tua zona ospitata su Route 53 e il tuo App Runner**, inserisci il nome di dominio personalizzato. Per ulteriori informazioni, consulta [Gestione di nomi di dominio personalizzati per App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html). **Se hai utilizzato un AWS account per creare la zona ospitata corrente e un account diverso per creare un App Runner, l'App Runner non verrà visualizzato nell'elenco degli endpoint.** Per ulteriori informazioni, consulta [Configurazione di Amazon Route 53 per instradare il traffico a un servizio App Runner](routing-to-app-runner.md#routing-to-app-runner-configuring). **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se il nome di dominio per l'ambiente Elastic Beanstalk comprende la regione in cui hai distribuito l'ambiente, puoi creare un record alias che instrada il traffico verso l'ambiente. Ad esempio, il nome di dominio `my-environment.us-west-2.elasticbeanstalk.com` è un nome di dominio regionalizzato. Per gli ambienti creati prima dell'inizio del 2016, il nome di dominio non include la regione. Per instradare il traffico verso questi ambienti, è necessario creare un record CNAME invece di un record alias. Non puoi creare un record CNAME per il nome di dominio root. Ad esempio, se il tuo nome di dominio è esempio.com, è possibile creare un record che consente di instradare il traffico per acme.esempio.com al tuo ambiente Elastic Beanstalk, ma non potrai creare un record che consente di instradare il traffico per esempio.com al tuo ambiente Elastic Beanstalk. Per gli ambienti Elastic Beanstalk che hanno sottodomini regionalizzati, procedi in uno dei modi seguenti: + **Se hai usato lo stesso account per creare la zona ospitata Route 53 e l'ambiente Elastic Beanstalk**: scegli **Endpoint** e seleziona quindi un ambiente dall'elenco. Se disponi di molti ambienti, puoi inserire i primi caratteri dell'attributo CNAME affinché l'ambiente filtri l'elenco. + **Se hai usato diversi account per creare la tua zona ospitata Route 53 e l'ambiente Elastic Beanstalk**\$1 specifica l'attributo CNAME per l'ambiente Elastic Beanstalk. Per ulteriori informazioni, consulta [Instradamento del traffico verso un ambiente AWS Elastic Beanstalk](routing-to-beanstalk-environment.md). **load balancer ELB** Per i sistemi di bilanciamento del carico ELB, procedere in uno dei seguenti modi: + **Se hai usato lo stesso account per creare la zona ospitata Route 53 e il load balancer**: scegli **Endpoint** e seleziona un load balancer dall'elenco. Se disponi di molti sistemi di bilanciamento del carico, puoi inserire i primi caratteri del nome DNS per filtrare l'elenco. + **Se hai usato diversi account per creare la tua zona ospitata Route 53 e il load balancer**: inserisci il valore ottenuto nella procedura [Come ottenere il nome DNS per un sistema di bilanciamento del carico Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure). **Se hai utilizzato un AWS account per creare la zona ospitata corrente e un account diverso per creare un sistema di bilanciamento del carico, il sistema di bilanciamento del carico non verrà visualizzato nell'elenco degli endpoint.** Se hai utilizzato un account per creare la zona ospitata corrente e uno o più account diversi per creare tutti i bilanciatori del carico, nell'elenco **Endpoints** viene visualizzato **Nessuna destinazione disponibile** in **Elastic Load Balancer**. La consolle aggiunge **dualstack.** per Application Load Balancer e Classic Load Balancer da un diverso account. Quando un client, ad esempio un browser Web, richiede l'indirizzo IP per il nome di dominio (esempio.com) o il nome di sottodominio (www.esempio.com), il client può richiedere un IPv4 indirizzo (un record A), un IPv6 indirizzo (un record AAAA) o entrambi IPv4 gli IPv6 indirizzi (in richieste separate). La designazione **dualstack.** consente a Route 53 di rispondere con l'indirizzo IP appropriato per il load balancer in base al formato dell'indirizzo IP richiesto dal client. Per ulteriori informazioni, consulta [Routing del traffico a un load balancer ELB](routing-to-elb-load-balancer.md). **AWS Acceleratori Global Accelerator** Per gli acceleratori AWS Global Accelerator, inserisci il nome DNS dell'acceleratore. È possibile inserire il nome DNS di un acceleratore creato utilizzando l' AWS account corrente o utilizzando un account diverso. AWS **Bucket Amazon S3** Per i bucket Amazon S3 che sono configurati come endpoint del sito Web, procedi in uno dei modi seguenti: + **Se hai usato lo stesso account per creare la zona ospitata Route 53 e il bucket Amazon S3**: scegli **Endpoint** e seleziona quindi un bucket dall'elenco. Se disponi di molti bucket, puoi inserire i primi caratteri del nome DNS per filtrare l'elenco. Il valore di **Endpoint** diventa l'endpoint del sito Web Amazon S3 per il bucket. + **Se hai usato diversi account per creare la tua zona ospitata Route 53 e il bucket Amazon S3** - inserisci il nome della regione nella quale hai creato il bucket S3. Utilizza il valore che appare nella colonna **Endpoint sito web** nella tabella [Endpoint del sito web Amazon S3](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) in *Riferimenti generali di Amazon Web Services*. **Se hai utilizzato AWS account diversi dall'account corrente per creare i tuoi bucket Amazon S3, il bucket non verrà visualizzato nell'elenco degli endpoint.** Devi configurare il bucket per l'hosting di siti Web. Per ulteriori informazioni, consulta [Configurazione di un bucket per l'hosting di un sito Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) nella *Guida per utenti di Amazon Simple Storage Service*. Il nome del record deve corrispondere al nome del bucket Amazon S3. Ad esempio, se il nome del bucket Amazon S3 è **acme.esempio.com**, anche il nome del record deve essere **acme.esempio.com**. In un gruppo di alias ponderati, alias di latenza, alias di failover o alias di geolocalizzazione, puoi creare un solo record che instrada le query a un bucket Amazon S3 perché il nome del record deve corrispondere al nome del bucket e nomi dei bucket devono essere globalmente univoci. ** OpenSearch Servizio Amazon** Per OpenSearch Service, esegui una delle seguenti operazioni: + **OpenSearch Dominio personalizzato del servizio**: il nome del record deve corrispondere al dominio personalizzato. Ad esempio, se il nome del dominio personalizzato è test.example.com, anche il nome di questo record deve essere test.example.com. + **Se hai utilizzato lo stesso account per creare la tua zona ospitata su Route 53 e il tuo dominio di OpenSearch servizio, scegli il, quindi scegli il nome di dominio**. Regione AWS + **Se hai utilizzato account diversi per creare la tua zona ospitata su Route 53 e il tuo dominio di OpenSearch servizio**, inserisci il nome di dominio personalizzato. Per ulteriori informazioni, consulta [Creare un endpoint personalizzato](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html). Se hai utilizzato un AWS account per creare la zona ospitata corrente e un account diverso per creare un dominio di OpenSearch servizio, il dominio non verrà visualizzato nell'elenco degli **endpoint**. **Se hai utilizzato un account per creare la zona ospitata corrente e uno o più account diversi per creare tutti i domini di OpenSearch servizio, l'elenco degli **endpoint** mostra **Nessun obiettivo disponibile** in Servizio. OpenSearch ** Per ulteriori informazioni, consulta [Configurazione di Amazon Route 53 per instradare il traffico verso un endpoint OpenSearch di dominio Amazon Service](routing-to-open-search-service.md#routing-to-open-search-service-configuring). **Endpoint dell'interfaccia di Amazon VPC** Per gli endpoint dell'interfaccia Amazon VPC, effettua una delle seguenti operazioni: + **Se hai usato lo stesso account per creare la zona ospitata Route 53 e l'endpoint dell'interfaccia**: scegli **Endpoint** e seleziona quindi un endpoint dell'interfaccia dall'elenco. Se disponi di molte interfacce di endpoint, puoi inserire i primi caratteri del nome host DNS per filtrare l'elenco. + **Se hai utilizzato account diversi per creare la tua zona ospitata Route 53 e l'endpoint dell'interfaccia**, inserisci il nome host DNS per l'endpoint dell'interfaccia, ad esempio **vpce-123456789abcdef01- example-us-east -1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**. **Se hai utilizzato un AWS account per creare la zona ospitata corrente e un account diverso per creare un endpoint di interfaccia, l'endpoint dell'interfaccia non verrà visualizzato nell'elenco degli endpoint sotto gli **endpoint** VPC.** Se hai utilizzato un account per creare la zona ospitata attuale e uno o più account diversi per creare tutti gli endpoint di interfaccia, nell'elenco **Endpoint** viene visualizzato **Nessuna destinazione disponibile** in **Endpoint VPC**. Per ulteriori informazioni, consulta [Routing del traffico a un endpoint di interfaccia di Amazon Virtual Private Cloud usando il proprio nome dominio](routing-to-vpc-interface-endpoint.md). **Record in questa zona ospitata** Per i record in questa zona ospitata, scegli **Endpoint**, quindi seleziona il record applicabile. Se disponi di molti record, puoi inserire i primi caratteri del nome per filtrare l'elenco. Se la zona ospitata contiene solo i record NS e SOA di default, nell'elenco **Endpoint** viene visualizzato **Nessuna destinazione disponibile**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi scegliere un record il cui valore di **Tipo di record** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. # Valori specifici per record semplici Quando crei record semplici, specifichi i valori seguenti. **Topics** + [Policy di routing](#rrsets-values-basic-routing-policy) + [Nome record](#rrsets-values-basic-name) + [Valore/instradamento traffico a](#rrsets-values-basic-value) + [Tipo di record](#rrsets-values-basic-type) + [TTL (secondi)](#rrsets-values-basic-ttl) ## Policy di routing Scegli **Routing semplice**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — IPv4 indirizzo** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **NS - Server di nomi** Il nome di dominio di un server dei nomi, ad esempio **ns1.example.com**. **Nota** È possibile specificare un record NS con solo una policy di routing. + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore per **Tipo di record** in base al modo in cui desideri che Route 53 risponda alle query DNS. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. # Valori specifici per record alias semplici Quando crei record alias, specifichi i valori seguenti. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Nota** Se si utilizza Route 53 in AWS GovCloud (US) Region, questa funzionalità presenta alcune restrizioni. Per ulteriori informazioni, consulta la [pagina di Amazon Route 53](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) nella *Guida per l'utente di AWS GovCloud (US) *. **Topics** + [Policy di routing](#rrsets-values-alias-routing-policy) + [Nome record](#rrsets-values-alias-name) + [Valore/instradamento traffico a](#rrsets-values-alias-alias-target) + [Tipo di record](#rrsets-values-alias-type) + [Valutazione dello stato della destinazione](#rrsets-values-alias-evaluate-target-health) ## Policy di routing Scegli **Routing semplice**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi indirizzare, consulta [Common values for alias records for value/route traffic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target) to. Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico: **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. ## Valutazione dello stato della destinazione Quando il valore di **Policy di routing** è **Semplice**, è possibile scegliere tra **No** il valore di default **Sì** perché **Valuta integrità della destinazione** non ha effetto per il routing **Semplice**. Se hai solo un record con nome e tipo, Route 53 risponde alle query DNS utilizzando i valori in quel record, indipendentemente dall'integrità della risorsa. Per altre politiche di routing, **Evaluate target health** determina se Route 53 controlla lo stato della risorsa a cui si riferisce il record di alias: + **Servizi in cui Evaluate lo stato dell'obiettivo offre vantaggi operativi**: per i sistemi di bilanciamento del carico (ELB) e gli AWS Elastic Beanstalk ambienti con sistemi di bilanciamento del carico, l'impostazione di **Evaluate target health** su **Yes** consente a Route 53 di indirizzare il traffico lontano da risorse non integre. + **Servizi ad alta disponibilità**: per servizi come bucket Amazon S3, endpoint di interfaccia VPC, Amazon API Gateway, AWS Global Accelerator Amazon Service e Amazon VPC Lattice OpenSearch **, Evaluate Target Health non offre alcun vantaggio operativo perché questi** servizi sono progettati per un'elevata disponibilità. Per gli scenari di failover con questi servizi, utilizza invece i [controlli di integrità della Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Per informazioni dettagliate su come **Evaluate Target Health** funziona con diversi AWS servizi, consulta la [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth)documentazione nel riferimento all'API. # Valori specifici per record di failover Quando crei record di failover, specifichi i valori seguenti. **Nota** Per informazioni su come creare record di failover nella propria zona ospitata privata, consulta [Configurazione del failover in una zona ospitata privata](dns-failover-private-hosted-zones.md). **Topics** + [Policy di routing](#rrsets-values-failover-routing-policy) + [Nome record](#rrsets-values-failover-name) + [Tipo di record](#rrsets-values-failover-type) + [TTL (secondi)](#rrsets-values-failover-ttl) + [Valore/instradamento traffico a](#rrsets-values-failover-value) + [Tipo di record di failover](#rrsets-values-failover-record-type) + [Controllo dell’integrità](#rrsets-values-failover-associate-with-health-check) + [ID record](#rrsets-values-failover-set-id) ## Policy di routing Scegli **Failover**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per entrambi i record nel gruppo di record di failover. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona lo stesso valore per i record di failover principali e secondari. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — IPv4 indirizzo** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Tipo di record di failover Scegli un valore applicabile per questo record. Affinché il failover funzioni correttamente, è necessario creare un record di failover principale e uno secondario. Non puoi creare record non di failover che hanno gli stessi valori per **Nome record** e **Tipo di record** come record di failover. ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (ad esempio i record di failover o ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate Target Health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Domain Name (Nome dominio)**, specifica il nome di dominio del server (ad esempio, us-east-2-www.example.com), anziché il nome dei record (example.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## ID record Immetti un valore che identifichi in modo univoco i record principale e secondario. # Valori specifici per i record alias di failover Quando crei record alias di failover, specifichi i valori seguenti. Per informazioni, consultare gli argomenti seguenti: + Per informazioni su come creare record di failover nella propria zona ospitata privata, consulta [Configurazione del failover in una zona ospitata privata](dns-failover-private-hosted-zones.md). + Per ulteriori informazioni sui record alias, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Policy di routing](#rrsets-values-failover-alias-routing-policy) + [Nome record](#rrsets-values-failover-alias-name) + [Tipo di record](#rrsets-values-failover-alias-type) + [Valore/instradamento traffico a](#rrsets-values-failover-alias-alias-target) + [Tipo di record di failover](#rrsets-values-failover-alias-failover-record-type) + [Controllo dell’integrità](#rrsets-values-failover-alias-associate-with-health-check) + [Valutazione dello stato della destinazione](#rrsets-values-failover-alias-evaluate-target-health) + [ID record](#rrsets-values-failover-alias-set-id) ## Policy di routing Scegli **Failover**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per entrambi i record nel gruppo di record di failover. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico. Seleziona lo stesso valore per i record di failover principali e secondari: **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi indirizzare, consulta [Common values for alias records for value/route traffic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target) to. Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). **Nota** Quando crei i record di failover principale e secondario, puoi facoltativamente creare un record di failover e un record *alias* di failover con gli stessi valori per **Nome** e **Tipo di record**. Se combini il record di failover con il record alias di failover, entrambi possono essere il record principale. ## Tipo di record di failover Scegli un valore applicabile per questo record. Affinché il failover funzioni correttamente, è necessario creare un record di failover principale e uno secondario. Non puoi creare record non di failover che hanno gli stessi valori per **Nome record** e **Tipo di record** come record di failover. ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (come i record di failover o ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate Target Health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Domain Name (Nome dominio)**, specifica il nome di dominio del server (ad esempio, us-east-2-www.example.com), anziché il nome dei record (example.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## Valutazione dello stato della destinazione Seleziona **Sì** se desideri che Route 53 determini se rispondere alle query DNS utilizzando questo record controllando l'integrità della risorsa specificata da **Endpoint**. Tenere presente quanto segue: **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un'API regionale personalizzata di API Gateway o un'API ottimizzata per l'edge. **CloudFront distribuzioni** Non è possibile impostare **Evaluate target health** su **Sì** quando l'endpoint è una CloudFront distribuzione. **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se specifichi un ambiente Elastic Beanstalk in **Endpoint** e l'ambiente contiene un load balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. (Un ambiente contiene automaticamente un load balancer ELB se include più di un'istanza Amazon EC2.) Se imposti **Valutazione dell'integrazione della destinazione** su **Sì** e nessuna istanza Amazon EC2 è integra o lo stesso load balancer non è integro, Route 53 instrada le query ad altre risorse disponibili integre, se presenti. Se l'ambiente contiene una sola istanza Amazon EC2, non sono previsti requisiti speciali. **Load balancer ELB** Il comportamento del controllo dell'integrità dipende dal tipo di load balancer: + **Classic Load Balancer**: se in **Endpoint** specifichi un Classic Load Balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. Se imposti **Valutazione dell'integrità della destinazione** su **Sì** e né le istanze EC2 né il load balancer risultano integri, Route 53 instrada le query ad altre risorse. + **Application Load Balancer/Network Load Balancer**: se specifichi un Application Load Balancer/Network Load Balancer ELB e imposti **Valutazione dell'integrità della destinazione** su **Sì**, Route 53 instrada le query al load balancer in base all'integrità dei gruppi di destinazione a esso associati: + Affinché un Application Load Balancer/Network Load Balancer venga considerato integro, un gruppo target contenente target deve includere almeno un target integro. Se un gruppo target contiene solo target non integri, il load balancer viene considerato non integro e Route 53 instrada le query ad altre risorse. + Un gruppo target che non include target registrati viene considerato non integro. Quando crei un load balancer, configuri le impostazioni per i controlli dell'integrità di Elastic Load Balancing, che svolgono una funzione analoga ai controlli dell'integrità di Route 53. Non creare controlli dell'integrità di Route 53 per le istanze EC2 che record con un load balancer ELB. **Bucket S3** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un bucket S3. **Endpoint dell'interfaccia di Amazon VPC** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un endpoint dell'interfaccia Amazon VPC. **Altri record nella stessa zona ospitata** Se la AWS risorsa specificata in **Endpoint** è un record o un gruppo di record (ad esempio, un gruppo di record ponderati) ma non è un altro record di alias, ti consigliamo di associare un controllo dello stato a tutti i record dell'endpoint. Per ulteriori informazioni, consulta [Cosa accade se si omettono i controlli dell'integrità?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID record Immetti un valore che identifichi in modo univoco i record principale e secondario. # Valori specifici per record di geolocalizzazione Quando crei record di geolocalizzazione, specifichi i valori seguenti. **Topics** + [Policy di routing](#rrsets-values-geo-routing-policy) + [Nome record](#rrsets-values-geo-name) + [Tipo di record](#rrsets-values-geo-type) + [TTL (secondi)](#rrsets-values-geo-ttl) + [Valore/instradamento traffico a](#rrsets-values-geo-value) + [Location (Ubicazione)](#rrsets-values-geo-location) + [Stati degli Stati Uniti](#rrsets-values-geo-sublocation) + [Controllo dell’integrità](#rrsets-values-geo-associate-with-health-check) + [ID record](#rrsets-values-geo-set-id) ## Policy di routing Seleziona **Geolocalizzazione**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. Immetti lo stesso nome per tutti i record nel gruppo di record di geolocalizzazione. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona lo stesso valore per tutti i record nel gruppo dei record di geolocalizzazione. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — IPv4 indirizzo** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Location (Ubicazione) Quando configuri Route 53 per rispondere alle query DNS in base alla posizione da cui provengono, seleziona il continente o il paese per il quale desideri che Route 53 risponda con le impostazioni di questo record. Se desideri che Route 53 risponda alle query DNS dei singoli paesi degli Stati Uniti, seleziona **Stati Uniti** dall'elenco **Posizione**, quindi seleziona lo stato dal gruppo **Posizione secondaria**. Per una zona ospitata privata, seleziona il continente, il paese o la suddivisione più vicini a Regione AWS quello in cui si trova la risorsa. Ad esempio, se la risorsa si trova in us-east-1, puoi specificare Nord America, Stati Uniti o Virginia. **Importante** Si consiglia di creare un record di geolocalizzazione con il valore **Default (Predefinito)** per l’opzione **Location (Posizione)**. Questo copre le località geografiche per cui non hai creato record nonché gli indirizzi IP per cui Route 53 non è in grado di identificare una località. Non puoi creare record di non geolocalizzazione che hanno gli stessi valori per **Nome record** e **Tipo di record** come record di geolocalizzazione. Per ulteriori informazioni, consulta [Routing di geolocalizzazione](routing-policy-geo.md). Di seguito sono indicati i paesi che Amazon Route 53 associa a ogni continente. I codici dei paesi sono quelli della norma ISO 3166. Per maggiori informazioni, consulta l'articolo di Wikipedia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2): **Africa (AF)** AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW **Antartide (AN)** AQ, GS, TF **Asia (AS)** AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE **Europa (EU)** AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK Alcuni provider ritengono che TR si trovi in Asia e gli indirizzi IP lo rispecchieranno. **Nord America (NA)** AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI **Oceania (OC)** AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS **Sud America (SA)** AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE **Nota** Route 53 non supporta la creazione di record di geolocalizzazione per i seguenti paesi: Isola Bouvet (BV), Isola di Natale (CX), Sahara Occidentale (EH) e Isola e Isole Heard (HM). McDonald Non sono disponibili dati sugli indirizzi IP per questi paesi. ## Stati degli Stati Uniti Quando configuri Route 53 per rispondere alle query DNS in base allo stato degli Stati Uniti da cui provengono, seleziona lo stato dall'elenco **Stati degli Stati Uniti**. I territori degli Stati Uniti (ad esempio, Porto Rico) sono presenti come paesi nell'elenco **Location (Posizione)**. **Importante** Alcuni indirizzi IP sono associati agli Stati Uniti, ma non a un singolo paese. Se crei record per tutti i paesi degli Stati Uniti, ti consigliamo di creare anche un record generico per gli Stati Uniti per instradare le query per questi indirizzi IP non associati. Se non crei un record generico per gli Stati Uniti, Route 53 risponde alle query DNS provenienti dagli indirizzi IP non associati agli Stati Uniti con le impostazioni del record di geolocalizzazione predefinito (se ne hai creato uno) o con una "non risposta". ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (ad esempio i record di failover o ponderati) e specifichi il controllo dello stato per tutti i record. IDs Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate Target Health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Domain Name (Nome dominio)**, specifica il nome di dominio del server (ad esempio, us-east-2-www.example.com), anziché il nome dei record (example.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. Per i record di geolocalizzazione, se un endpoint non è integro, Route 53 cerca un record per la regione geografica associata più estesa. Ad esempio, supponiamo che siano presenti record per un paese degli Stati Uniti, per tutti gli Stati Uniti, per il Nord America e per tutte le località, con l'opzione **Location (Località)** impostata su **Default (Predefinita)**. Se l'endpoint per il record del paese non è integro, Route 53 controlla i record per gli Stati Uniti, per il Nord America e per tutte le località, in quest'ordine, finché non trova un record con un endpoint integro. Se tutti i record applicabili sono in uno stato non integro, incluso il record per tutte le sedi, Route 53 risponde a una query DNS con il valore del record della regione geografica più piccola. ## ID record Immetti un valore che identifichi in modo univoco questo record nel gruppo di record di geolocalizzazione. # Valori specifici per record degli alias di geolocalizzazione Quando crei record alias di geolocalizzazione, specifichi i valori seguenti. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Policy di routing](#rrsets-values-geo-alias-routing-policy) + [Nome record](#rrsets-values-geo-alias-name) + [Tipo di record](#rrsets-values-geo-alias-type) + [Valore/instradamento traffico a](#rrsets-values-geo-alias-alias-target) + [Location (Ubicazione)](#rrsets-values-geo-alias-location) + [Stati degli Stati Uniti](#rrsets-values-geo-alias-sublocation) + [Controllo dell’integrità](#rrsets-values-geo-alias-associate-with-health-check) + [Valutazione dello stato della destinazione](#rrsets-values-geo-alias-evaluate-target-health) + [ID record](#rrsets-values-geo-alias-set-id) ## Policy di routing Seleziona **Geolocalizzazione**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per tutti i record nel gruppo di record di geolocalizzazione. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico. Seleziona lo stesso valore per tutti i record nel gruppo dei record di geolocalizzazione. **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi indirizzare, consulta[Valore/instradamento traffico a](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). ## Location (Ubicazione) Quando configuri Route 53 per rispondere alle query DNS in base alla posizione da cui provengono, seleziona il continente o il paese per il quale desideri che Route 53 risponda con le impostazioni di questo record. Se desideri che Route 53 risponda alle query DNS dei singoli stati degli Stati Uniti, seleziona **Stati Uniti** dall'elenco **Posizione**, quindi seleziona lo stato dall'elenco **Stati degli Stati Uniti**. Per una zona ospitata privata, seleziona il continente, il paese o la suddivisione più vicina a Regione AWS quella in cui si trova la risorsa. Ad esempio, se la risorsa si trova in us-east-1, puoi specificare Nord America, Stati Uniti o Virginia. **Importante** Si consiglia di creare un record di geolocalizzazione con il valore **Default (Predefinito)** per l’opzione **Location (Posizione)**. Questo copre le località geografiche per cui non hai creato record nonché gli indirizzi IP per cui Route 53 non è in grado di identificare una località. Non puoi creare record di non geolocalizzazione che hanno gli stessi valori per **Nome record** e **Tipo di record** come record di geolocalizzazione. Per ulteriori informazioni, consulta [Routing di geolocalizzazione](routing-policy-geo.md). Di seguito sono indicati i paesi che Amazon Route 53 associa a ogni continente. I codici dei paesi sono quelli della norma ISO 3166. Per maggiori informazioni, consulta l'articolo di Wikipedia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2): **Africa (AF)** AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW **Antartide (AN)** AQ, GS, TF **Asia (AS)** AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE **Europa (EU)** AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK Alcuni provider ritengono che TR si trovi in Asia e gli indirizzi IP lo rispecchieranno. **Nord America (NA)** AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI **Oceania (OC)** AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS **Sud America (SA)** AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE **Nota** Route 53 non supporta la creazione di record di geolocalizzazione per i seguenti paesi: Isola Bouvet (BV), Isola di Natale (CX), Sahara Occidentale (EH) e Isola e Isole Heard (HM). McDonald Non sono disponibili dati sugli indirizzi IP per questi paesi. ## Stati degli Stati Uniti Quando configuri Route 53 per rispondere alle query DNS in base allo stato degli Stati Uniti da cui provengono, seleziona lo stato dall'elenco **Stati degli Stati Uniti**. I territori degli Stati Uniti (ad esempio, Porto Rico) sono presenti come paesi nell'elenco **Location (Posizione)**. **Importante** Alcuni indirizzi IP sono associati agli Stati Uniti, ma non a un singolo paese. Se crei record per tutti i paesi degli Stati Uniti, ti consigliamo di creare anche un record generico per gli Stati Uniti per instradare le query per questi indirizzi IP non associati. Se non crei un record generico per gli Stati Uniti, Route 53 risponde alle query DNS provenienti dagli indirizzi IP non associati agli Stati Uniti con le impostazioni del record di geolocalizzazione predefinito (se ne hai creato uno) o con una "non risposta". ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (ad esempio i record di failover o ponderati) e specifichi il controllo dello stato per tutti i record. IDs Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. Per i record di geolocalizzazione, se un endpoint non è integro, Route 53 cerca un record per la regione geografica associata più estesa. Ad esempio, supponiamo che siano presenti record per un paese degli Stati Uniti, per tutti gli Stati Uniti, per il Nord America e per tutte le località, con l'opzione **Location (Località)** impostata su **Default (Predefinita)**. Se l'endpoint per il record del paese non è integro, Route 53 controlla i record per gli Stati Uniti, per il Nord America e per tutte le località, in quest'ordine, finché non trova un record con un endpoint integro. Se tutti i record applicabili sono in uno stato non integro, incluso il record per tutte le sedi, Route 53 risponde a una query DNS con il valore del record della regione geografica più piccola. ## Valutazione dello stato della destinazione Seleziona **Sì** se desideri che Route 53 determini se rispondere alle query DNS utilizzando questo record controllando l'integrità della risorsa specificata da **Endpoint**. Tenere presente quanto segue: **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un'API regionale personalizzata di API Gateway o un'API ottimizzata per l'edge. **CloudFront distribuzioni** Non è possibile impostare **Evaluate target health** su **Sì** quando l'endpoint è una CloudFront distribuzione. **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se specifichi un ambiente Elastic Beanstalk in **Endpoint** e l'ambiente contiene un load balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. (Un ambiente contiene automaticamente un load balancer ELB se include più di un'istanza Amazon EC2.) Se imposti **Valutazione dell'integrazione della destinazione** su **Sì** e nessuna istanza Amazon EC2 è integra o lo stesso load balancer non è integro, Route 53 instrada le query ad altre risorse disponibili integre, se presenti. Se l'ambiente contiene una sola istanza Amazon EC2, non sono previsti requisiti speciali. **Load balancer ELB** Il comportamento del controllo dell'integrità dipende dal tipo di load balancer: + **Classic Load Balancer**: se in **Endpoint** specifichi un Classic Load Balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. Se imposti **Valutazione dell'integrità della destinazione** su **Sì** e né le istanze EC2 né il load balancer risultano integri, Route 53 instrada le query ad altre risorse. + **Application Load Balancer/Network Load Balancer**: se specifichi un Application Load Balancer/Network Load Balancer ELB e imposti **Valutazione dell'integrità della destinazione** su **Sì**, Route 53 instrada le query al load balancer in base all'integrità dei gruppi di destinazione a esso associati: + Affinché un Application Load Balancer/Network Load Balancer venga considerato integro, ogni gruppo target contenente target deve includere almeno un target integro. Se un gruppo target contiene solo target non integri, il load balancer viene considerato non integro e Route 53 instrada le query ad altre risorse. + Un gruppo target che non include target registrati viene considerato non integro. Quando crei un load balancer, configuri le impostazioni per i controlli dell'integrità di Elastic Load Balancing, che svolgono una funzione analoga ai controlli dell'integrità di Route 53. Non creare controlli dell'integrità di Route 53 per le istanze EC2 che record con un load balancer ELB. **Bucket S3** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un bucket S3. **Endpoint dell'interfaccia di Amazon VPC** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un endpoint dell'interfaccia Amazon VPC. **Altri record nella stessa zona ospitata** Se la AWS risorsa specificata in **Endpoint** è un record o un gruppo di record (ad esempio, un gruppo di record ponderati) ma non è un altro record di alias, ti consigliamo di associare un controllo dello stato a tutti i record dell'endpoint. Per ulteriori informazioni, consulta [Cosa accade se si omettono i controlli dell'integrità?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID record Immetti un valore che identifichi in modo univoco questo record nel gruppo di record di geolocalizzazione. # Valori specifici per i record di geoprossimità Quando si creano record di geoprossimità, si specificano i seguenti valori. **Topics** + [Policy di routing](#rrsets-values-geoprox-routing-policy) + [Nome record](#rrsets-values-geoprox-name) + [Tipo di record](#rrsets-values-geoprox-type) + [TTL (secondi)](#rrsets-values-geoprox-ttl) + [Valore/instradamento traffico a](#rrsets-values-geoprox-value) + [Endpoint location (Posizione endpoint)](#rrsets-values-geoprox-endpoint-location) + [Bias](#rrsets-values-geoprox-bias) + [Controllo dell’integrità](#rrsets-values-geoprox-associate-with-health-check) + [ID record](#rrsets-values-geoprox-set-id) ## Policy di routing Scegli **Geoproximity**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. Inserisci lo stesso nome per tutti i record del gruppo di record di geoprossimità. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona lo stesso valore per tutti i record del gruppo di record di geoprossimità. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — indirizzo IPv4 ** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Endpoint location (Posizione endpoint) È possibile specificare la posizione dell'endpoint della risorsa utilizzando uno dei seguenti metodi: **Coordinate personalizzate** Specificare la longitudine e la latitudine per un'area geografica. **Regione AWS** **Scegliete una regione disponibile dall'elenco delle località.** Per ulteriori informazioni sulle regioni, consulta [Infrastruttura AWS globale](https://aws.amazon.com/about-aws/global-infrastructure/). **AWS Gruppo di zone locali** Scegliete un gruppo di zone locali disponibile dall'elenco delle **ubicazioni**. Per ulteriori informazioni sulle Local Zones, vedere [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) nella *AWS Local Zones User Guide*. Un gruppo di zone locale è in genere la zona locale senza il carattere finale. Ad esempio, se la zona locale è, `us-east-1-bue-1a` il gruppo di zone locali lo è`us-east-1-bue-1`. Puoi anche identificare il Local Zones Group per una zona locale specifica utilizzando il comando [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI: ``` aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName" ``` Questo comando restituisce:`"GroupName": "us-west-2-den-1"`, specificando che la zona locale `us-west-2-den-1a` appartiene al gruppo di zone locali. `us-west-2-den-1` Non è possibile creare record non di geoprossimità con gli stessi valori per **Record name** e Record **type dei record di** geoprossimità. Inoltre, non è possibile creare due set di record di risorse di geoprossimità che specificano la stessa posizione per lo stesso nome e tipo di record. ## Bias Una distorsione espande o riduce un'area geografica da cui la Route 53 indirizza il traffico verso una risorsa. Un bias positivo amplia l'area, mentre un bias negativo la restringe. Per ulteriori informazioni, consulta [Come Amazon Route 53 utilizza il bias per instradare il traffico](routing-policy-geoproximity.md#routing-policy-geoproximity-bias). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Si verifica lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e politica di routing (ad esempio i record di failover o ponderati) e si specifica il controllo dello stato per tutti i record. IDs Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Si seleziona **Sì per Evaluate** **Target Health** per un record di alias o per i record in un gruppo di alias di failover, alias di geolocalizzazione, alias di geoprossimità, alias di latenza, alias basato su IP o record di alias ponderato. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Domain Name (Nome dominio)**, specifica il nome di dominio del server (ad esempio, us-east-2-www.example.com), anziché il nome dei record (example.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. Per i record di geoprossimità, se un endpoint non è integro, Route 53 cerca un endpoint più vicino che sia ancora integro. ## ID record Inserisci un valore che identifichi in modo univoco questo record nel gruppo di record di geoprossimità. # Valori specifici per i record di alias di geoprossimità Quando si creano record di alias di geoprossimità, si specificano i seguenti valori. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Policy di routing](#rrsets-values-geoprox-alias-routing-policy) + [Nome record](#rrsets-values-geoprox-alias-name) + [Tipo di record](#rrsets-values-geoprox-alias-type) + [Valore/instradamento traffico a](#rrsets-values-geoprox-alias-alias-target) + [Endpoint location (Posizione endpoint)](#rrsets-values-geoprox-alias-endpoint-location) + [Bias](#rrsets-values-geoprox-alias-bias) + [Controllo dell’integrità](#rrsets-values-geoprox-alias-associate-with-health-check) + [Valutazione dello stato della destinazione](#rrsets-values-geoprox-alias-evaluate-target-health) + [ID record](#rrsets-values-geoprox-alias-set-id) ## Policy di routing **Scegli Geoproximity.** ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Inserisci lo stesso nome per tutti i record del gruppo di record di geoprossimità. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico. Seleziona lo stesso valore per tutti i record del gruppo di record di geoprossimità: **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi rivolgerti, consulta[Valore/instradamento traffico a](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target). Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). ## Endpoint location (Posizione endpoint) È possibile specificare la posizione dell'endpoint della risorsa utilizzando uno dei seguenti metodi: **Coordinate personalizzate** Specificare la longitudine e la latitudine per un'area geografica. **Regione AWS** **Scegliete una regione disponibile dall'elenco delle località.** Per ulteriori informazioni sulle regioni, consulta [Infrastruttura AWS globale](https://aws.amazon.com/about-aws/global-infrastructure/). **AWS Gruppo di zone locali** Scegliete una regione di zona locale disponibile dall'elenco delle **ubicazioni**. Per ulteriori informazioni sulle Local Zones, vedere [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) nella *AWS Local Zones User Guide*. Un gruppo di zone locale è in genere la zona locale senza il carattere finale. Ad esempio, se la zona locale è, `us-east-1-bue-1a` il gruppo di zone locali lo è`us-east-1-bue-1`. Puoi anche identificare il Local Zones Group per una zona locale specifica utilizzando il comando [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI: ``` aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName" ``` Questo comando restituisce:`"GroupName": "us-west-2-den-1"`, specificando che la zona locale `us-west-2-den-1a` appartiene al gruppo di zone locali. `us-west-2-den-1` Non è possibile creare record non di geoprossimità con gli stessi valori per **Record name** e Record **type dei record di** geoprossimità. Inoltre, non è possibile creare due set di record di risorse di geoprossimità che specificano la stessa posizione per lo stesso nome e tipo di record. Per ulteriori informazioni, consulta .html available-local-zones ## Bias Una distorsione espande o riduce un'area geografica da cui la Route 53 indirizza il traffico verso una risorsa. Un bias positivo amplia l'area, mentre un bias negativo la restringe. Per ulteriori informazioni, consulta [Come Amazon Route 53 utilizza il bias per instradare il traffico](routing-policy-geoproximity.md#routing-policy-geoproximity-bias). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Si verifica lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e politica di routing (ad esempio i record di failover o ponderati) e si specifica il controllo dello stato per tutti i record. IDs Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Si seleziona **Sì** per **Valutare lo stato dell'obiettivo** per un record di alias o per i record in un gruppo di alias di failover, alias di geolocalizzazione, alias di geoprossimità, alias di latenza, alias basato su IP o record di alias ponderato. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. Per i record di geoprossimità, se un endpoint non è integro, Route 53 cerca un endpoint più vicino che sia ancora integro. ## Valutazione dello stato della destinazione Seleziona **Sì** se desideri che Route 53 determini se rispondere alle query DNS utilizzando questo record controllando l'integrità della risorsa specificata da **Endpoint**. Tenere presente quanto segue: **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un'API regionale personalizzata di API Gateway o un'API ottimizzata per l'edge. **CloudFront distribuzioni** Non è possibile impostare **Evaluate target health** su **Sì** quando l'endpoint è una CloudFront distribuzione. **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se specifichi un ambiente Elastic Beanstalk in **Endpoint** e l'ambiente contiene un load balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. (Un ambiente contiene automaticamente un load balancer ELB se include più di un'istanza Amazon EC2.) Se imposti **Valutazione dell'integrazione della destinazione** su **Sì** e nessuna istanza Amazon EC2 è integra o lo stesso load balancer non è integro, Route 53 instrada le query ad altre risorse disponibili integre, se presenti. Se l'ambiente contiene una sola istanza Amazon EC2, non sono previsti requisiti speciali. **Load balancer ELB** Il comportamento del controllo dell'integrità dipende dal tipo di load balancer: + **Classic Load Balancer**: se in **Endpoint** specifichi un Classic Load Balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. Se imposti **Valutazione dell'integrità della destinazione** su **Sì** e né le istanze EC2 né il load balancer risultano integri, Route 53 instrada le query ad altre risorse. + **Application Load Balancer/Network Load Balancer**: se specifichi un Application Load Balancer/Network Load Balancer ELB e imposti **Valutazione dell'integrità della destinazione** su **Sì**, Route 53 instrada le query al load balancer in base all'integrità dei gruppi di destinazione a esso associati: + Affinché un Application Load Balancer/Network Load Balancer venga considerato integro, ogni gruppo target contenente target deve includere almeno un target integro. Se un gruppo target contiene solo target non integri, il load balancer viene considerato non integro e Route 53 instrada le query ad altre risorse. + Un gruppo target che non include target registrati viene considerato non integro. Quando crei un load balancer, configuri le impostazioni per i controlli dell'integrità di Elastic Load Balancing, che svolgono una funzione analoga ai controlli dell'integrità di Route 53. Non creare controlli dell'integrità di Route 53 per le istanze EC2 che record con un load balancer ELB. **Bucket S3** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un bucket S3. **Endpoint dell'interfaccia di Amazon VPC** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un endpoint dell'interfaccia Amazon VPC. **Altri record nella stessa zona ospitata** Se la AWS risorsa specificata in **Endpoint** è un record o un gruppo di record (ad esempio, un gruppo di record ponderati) ma non è un altro record di alias, ti consigliamo di associare un controllo dello stato a tutti i record dell'endpoint. Per ulteriori informazioni, consulta [Cosa accade se si omettono i controlli dell'integrità?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID record Inserisci un valore che identifichi in modo univoco questo record nel gruppo di record di geoprossimità. # Valori specifici per i record di latenza Quando crei record di latenza, specifichi i valori seguenti. **Topics** + [Policy di routing](#rrsets-values-latency-routing-policy) + [Nome record](#rrsets-values-latency-name) + [Tipo di record](#rrsets-values-latency-type) + [TTL (secondi)](#rrsets-values-latency-ttl) + [Valore/instradamento traffico a](#rrsets-values-latency-value) + [Region](#rrsets-values-latency-region) + [Controllo dell’integrità](#rrsets-values-latency-associate-with-health-check) + [ID record](#rrsets-values-latency-set-id) ## Policy di routing Scegli **Latenza**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per tutti i record nel gruppo di record di latenza. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Selezionare il valore di **Tipo** in base al modo in cui si desidera che Route 53 risponda alle query DNS. Seleziona lo stesso valore per tutti i record nel gruppo di record di latenza. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — IPv4 indirizzo** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Region La Regione Amazon EC2 in cui risiede la risorsa che hai specificato in questo record. Route 53 consiglia una Regione Amazon EC2 in base ad altri valori specificati. Lo stesso vale anche per le zone ospitate private. Si consiglia di non modificare questo valore. Tenere presente quanto segue: + È possibile creare un solo record di latenza per ogni Regione Amazon EC2. + Non è necessario creare record di latenza per tutte le Regioni Amazon EC2. Route 53 sceglie la Regione con la migliore latenza tra quelle per cui sono stati creati i record di latenza. + Non puoi creare record di non latenza che hanno gli stessi valori per **Nome record** e **Tipo di record** come record di latenza. + Se si crea un record con il tag della Regione **cn-north-1**, Route 53 risponde sempre alle query provenienti dalla Cina utilizzando questo record, indipendentemente dalla latenza. Per ulteriori informazioni sull'utilizzo dei record di latenza, consulta [Routing basato sulla latenza](routing-policy-latency.md). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (ad esempio i record di failover o ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## ID record Immetti un valore che identifichi in modo univoco questo record nel gruppo di record di latenza. # Valori specifici per i record alias di latenza Quando crei record alias di latenza, specifichi i valori seguenti. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Policy di routing](#rrsets-values-latency-alias-routing-policy) + [Nome record](#rrsets-values-latency-alias-name) + [Tipo di record](#rrsets-values-latency-alias-type) + [Valore/instradamento traffico a](#rrsets-values-latency-alias-alias-target) + [Region](#rrsets-values-latency-alias-region) + [Controllo dell’integrità](#rrsets-values-latency-alias-associate-with-health-check) + [Valutazione dello stato della destinazione](#rrsets-values-latency-alias-evaluate-target-health) + [ID record](#rrsets-values-latency-alias-set-id) ## Policy di routing Scegli **Latenza**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per tutti i record nel gruppo di record di latenza. Per ulteriori informazioni sui nomi dei record, consultare [Nome record](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico: **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. Seleziona lo stesso valore per tutti i record nel gruppo di record di latenza. ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi indirizzare, consulta [Common values for alias records for value/route traffic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target) to. Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). ## Region La regione Amazon EC2 in cui risiede la risorsa che hai specificato in questo record. Route 53 consiglia una Regione Amazon EC2 in base ad altri valori specificati. Lo stesso vale anche per le zone ospitate private. Si consiglia di non modificare questo valore. Tenere presente quanto segue: + È possibile creare un solo record di latenza per ogni Regione Amazon EC2. + Non è necessario creare record di latenza per tutte le Regioni Amazon EC2. Route 53 sceglie la Regione con la migliore latenza tra quelle per cui sono stati creati i record di latenza. + Non puoi creare record di non latenza che hanno gli stessi valori per **Nome record** e **Tipo di record** come record di latenza. + Se si crea un record con il tag della Regione **cn-north-1**, Route 53 risponde sempre alle query provenienti dalla Cina utilizzando questo record, indipendentemente dalla latenza. Per ulteriori informazioni sull'utilizzo dei record di latenza, consulta [Routing basato sulla latenza](routing-policy-latency.md). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (come i record di failover o ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## Valutazione dello stato della destinazione Seleziona **Sì** se desideri che Route 53 determini se rispondere alle query DNS utilizzando questo record controllando l'integrità della risorsa specificata da **Endpoint**. Tenere presente quanto segue: **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un'API regionale personalizzata di API Gateway o un'API ottimizzata per l'edge. **CloudFront distribuzioni** Non è possibile impostare **Evaluate Target Health** su **Sì** quando l'endpoint è una CloudFront distribuzione. **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se specifichi un ambiente Elastic Beanstalk in **Endpoint** e l'ambiente contiene un load balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. (Un ambiente contiene automaticamente un load balancer ELB se include più di un'istanza Amazon EC2.) Se imposti **Valutazione dell'integrazione della destinazione** su **Sì** e nessuna istanza Amazon EC2 è integra o lo stesso load balancer non è integro, Route 53 instrada le query ad altre risorse disponibili integre, se presenti. Se l'ambiente contiene una sola istanza Amazon EC2, non sono previsti requisiti speciali. **Load balancer ELB** Il comportamento del controllo dell'integrità dipende dal tipo di load balancer: + **Classic Load Balancer**: se in **Endpoint** specifichi un Classic Load Balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. Se imposti **Valutazione dell'integrità della destinazione** su **Sì** e né le istanze EC2 né il load balancer risultano integri, Route 53 instrada le query ad altre risorse. + **Application Load Balancer/Network Load Balancer**: se specifichi un Application Load Balancer/Network Load Balancer ELB e imposti **Valutazione dell'integrità della destinazione** su **Sì**, Route 53 instrada le query al load balancer in base all'integrità dei gruppi di destinazione a esso associati: + Affinché un Application Load Balancer/Network Load Balancer venga considerato integro, ogni gruppo target contenente target deve includere almeno un target integro. Se un gruppo target contiene solo target non integri, il load balancer viene considerato non integro e Route 53 instrada le query ad altre risorse. + Un gruppo target che non include target registrati viene considerato non integro. Quando crei un load balancer, configuri le impostazioni per i controlli dell'integrità di Elastic Load Balancing, che svolgono una funzione analoga ai controlli dell'integrità di Route 53. Non creare controlli dell'integrità di Route 53 per le istanze EC2 che record con un load balancer ELB. **Bucket S3** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un bucket S3. **Endpoint dell'interfaccia di Amazon VPC** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un endpoint dell'interfaccia Amazon VPC. **Altri record nella stessa zona ospitata** Se la AWS risorsa specificata in **Endpoint** è un record o un gruppo di record (ad esempio, un gruppo di record ponderati) ma non è un altro record di alias, ti consigliamo di associare un controllo dello stato a tutti i record dell'endpoint. Per ulteriori informazioni, consulta [Cosa accade se si omettono i controlli dell'integrità?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID record Immetti un valore che identifichi in modo univoco questo record nel gruppo di record di latenza. # Valori specifici per i record basati su IP Quando crei i record basati su IP, specifica i valori seguenti. **Nota** Sebbene la creazione di record basati su IP in una zona ospitata privata sia consentita, non è supportata. **Topics** + [Policy di routing](#rrsets-values-ipbased-routing-policy) + [Nome record](#rrsets-values-ibased-name) + [Tipo di record](#rrsets-values-ibased-type) + [TTL (secondi)](#rrsets-values-ibased-ttl) + [Valore/instradamento traffico a](#rrsets-values-ibased-value) + [Ubicazione](#rrsets-values-ibased-location) + [Controllo dello stato](#rrsets-values-ibased-associate-with-health-check) + [ID record](#rrsets-values-ipbased-set-id) ## Policy di routing Scegli **IP-based** (Basato su IP). ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della hosted zone. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Inserisci lo stesso nome per tutti i record nel gruppo di record basati su IP. **Registri CNAME** Se stai creando un record che ha lo stesso valore di **CNAME** per **Tipo di record**, il nome del record non può essere uguale al nome della zona ospitata. **Caratteri speciali** Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). **Caratteri jolly** Puoi utilizzare un asterisco (\$1) all'interno del nome. Il DNS considera il carattere \$1 sia come un carattere jolly che come il carattere \$1 (ASCII 42), a seconda della posizione nel nome. Per ulteriori informazioni, consulta [Utilizza un asterisco (\$1) nei nomi di zone ospitate e registri](DomainNameFormat.md#domain-name-format-asterisk). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Selezionare il valore di **Tipo** in base al modo in cui si desidera che Route 53 risponda alle query DNS. Seleziona lo stesso valore per tutti i record del gruppo di record basati su IP. ## TTL (secondi) La quantità di tempo, in secondi, per cui desideri che i resolver ricorsivi DNS memorizzino nella cache le informazioni relative a questo record. Se specifichi un valore più lungo (ad esempio, 172800 secondi o due giorni), riduci il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l'effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se specifichi un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — indirizzo IPv4 ** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni su questi valori, consulta i [Valore/instradamento traffico a](resource-record-sets-values-shared.md#rrsets-values-common-value) [valori comuni per Valore/instradamento traffico a](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Ubicazione Il nome della posizione CIDR in cui la risorsa indicata in questo record è specificata dai valori del blocco CIDR all'interno della posizione. Per ulteriori informazioni sull'utilizzo dei record basati su IP, consulta [Routing basato su IP](routing-policy-ipbased.md). ## Controllo dello stato Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (come il failover o i record ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valuta integrità destinazione) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, basati su IP, di latenza o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## ID record Inserisci un valore che identifichi in modo univoco questo record nel gruppo di record basati su IP. # Valori specifici per i record alias basati su IP Quando crei record alias basati su IP, specifica i valori seguenti. **Nota** Sebbene la creazione di record alias basati su IP in una zona ospitata privata sia consentita, non è supportata. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Policy di routing](#rrsets-values-ipbased-alias-routing-policy) + [Nome record](#rrsets-values-ipbased-alias-name) + [Tipo di record](#rrsets-values-ipbased-alias-type) + [Valore/instradamento traffico a](#rrsets-values-ipbased-alias-alias-target) + [Location (Ubicazione)](#rrsets-values-ipbased-alias-location) + [Controllo dell’integrità](#rrsets-values-ipbased-alias-associate-with-health-check) + [Valutazione dello stato della destinazione](#rrsets-values-ipbased-alias-evaluate-target-health) + [ID record](#rrsets-values-ipbased-alias-set-id) ## Policy di routing Scegli **IP-based** (Basato su IP). **Nota** Sebbene la creazione di record alias basati su IP in una zona ospitata privata sia consentita, non è supportata. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Inserisci lo stesso nome per tutti i record nel gruppo di record basati su IP. **Registri CNAME** Se stai creando un record che ha lo stesso valore di **CNAME** per **Tipo di record**, il nome del record non può essere uguale al nome della zona ospitata. **Alias per CloudFront distribuzioni e bucket Amazon S3** Il valore specificato dipende in parte dalla AWS risorsa verso cui stai instradando il traffico: + **CloudFront distribuzione**: la distribuzione deve includere un nome di dominio alternativo che corrisponda al nome del record. Ad esempio, se il nome del record è **acme.example.com**, la distribuzione CloudFront deve includere **acme.example.com** come uno dei nomi di dominio alternativi. Per ulteriori informazioni, consulta [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) nella *Amazon CloudFront Developer Guide*. + **Bucket Amazon S3**: il nome del record deve corrispondere al nome del bucket Amazon S3. Ad esempio, se il nome del bucket è **acme.example.com**, anche il nome del record deve essere **acme.example.com**. Inoltre, devi configurare il bucket per l'hosting di siti Web. Per ulteriori informazioni, consulta [Configurazione di un bucket per l'hosting di un sito Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) nella *Guida per utenti di Amazon Simple Storage Service*. **Caratteri speciali** Per informazioni su come specificare caratteri diversi da a-z, 0-9 e - (trattino) e come specificare nomi di dominio internazionali, consulta [Formato del nome dominio DNS](DomainNameFormat.md). **Caratteri jolly** Puoi utilizzare un asterisco (\$1) all'interno del nome. Il DNS considera il carattere \$1 sia come un carattere jolly che come il carattere \$1 (ASCII 42), a seconda della posizione nel nome. Per ulteriori informazioni, consulta [Utilizza un asterisco (\$1) nei nomi di zone ospitate e registri](DomainNameFormat.md#domain-name-format-asterisk). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico. Seleziona lo stesso valore per tutti i record nel gruppo di record basati su IP: **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi indirizzare, consulta [Common values for alias records for value/route traffic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target) to. Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). ## Location (Ubicazione) Quando configuri Route 53 per rispondere alle query DNS in base alla posizione da cui provengono, seleziona la posizione CIDR per la quale desideri che Route 53 risponda con le impostazioni di questo record. **Importante** Ti consigliamo di creare un record basato su IP con il valore **Default** (Predefinito) per l'opzione **Location** (Posizione). Questo copre le posizioni per cui non hai creato i record nonché gli indirizzi IP per cui Route 53 non è in grado di identificare una posizione. Non è possibile creare non-IP-based record con gli stessi valori per **Nome record** e **Tipo di record** dei record basati su IP. Per ulteriori informazioni, consulta [Routing basato su IP](routing-policy-ipbased.md). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (come il failover o i record ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valuta integrità destinazione) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, ponderati o alias di routing basati su IP. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. Per i record di alias basati su IP, se un endpoint non è integro, Route 53 cerca un record all'interno della posizione associata più grande. Ad esempio, supponiamo che siano presenti record per un paese degli Stati Uniti, per tutti gli Stati Uniti, per il Nord America e per tutte le località, con l'opzione **Location (Località)** impostata su **Default (Predefinita)**. Se l'endpoint per il record del paese non è integro, Route 53 controlla i record per gli Stati Uniti, per il Nord America e per tutte le località, in quest'ordine, finché non trova un record con un endpoint integro. Se tutti i record applicabili sono in uno stato non integro, incluso il record per tutte le sedi, Route 53 risponde a una query DNS con il valore del record della regione geografica più piccola. ## Valutazione dello stato della destinazione Seleziona **Sì** se desideri che Route 53 determini se rispondere alle query DNS utilizzando questo record controllando l'integrità della risorsa specificata da **Endpoint**. Tenere presente quanto segue: **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un'API regionale personalizzata di API Gateway o un'API ottimizzata per l'edge. **CloudFront distribuzioni** Non è possibile impostare **Evaluate target health** su **Sì** quando l'endpoint è una CloudFront distribuzione. **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se specifichi un ambiente Elastic Beanstalk in Endpoint e **l'ambiente** contiene un load balancer ELB, Elastic Load Balancing indirizza le query solo alle istanze Amazon integre registrate con il EC2 load balancer. (Un ambiente contiene automaticamente un sistema di bilanciamento del carico ELB se include più di un' EC2 istanza Amazon.) Se imposti **Evaluate target health** su **Sì** e nessuna EC2 istanza Amazon è integra o il load balancer stesso non è integro, Route 53 indirizza le query ad altre risorse disponibili che sono integre, se presenti. Se l'ambiente contiene una singola EC2 istanza Amazon, non ci sono requisiti speciali. **Load balancer ELB** Il comportamento del controllo dell'integrità dipende dal tipo di load balancer: + **Classic Load Balancer**: se specifichi un ELB Classic Load Balancer **in** Endpoint, Elastic Load Balancing indirizza le query solo alle istanze EC2 Amazon integre registrate con il load balancer. Se imposti **Evaluate target health** su **Sì** e nessuna EC2 istanza è integra o il load balancer stesso non è integro, Route 53 indirizza le query ad altre risorse. + **Application Load Balancer/Network Load Balancer**: se specifichi un Application Load Balancer/Network Load Balancer ELB e imposti **Valutazione dell'integrità della destinazione** su **Sì**, Route 53 instrada le query al load balancer in base all'integrità dei gruppi di destinazione a esso associati: + Affinché un Application Load Balancer/Network Load Balancer venga considerato integro, ogni gruppo target contenente target deve includere almeno un target integro. Se un gruppo target contiene solo target non integri, il load balancer viene considerato non integro e Route 53 instrada le query ad altre risorse. + Un gruppo target che non include target registrati viene considerato non integro. Quando crei un load balancer, configuri le impostazioni per i controlli dell'integrità di Elastic Load Balancing, che svolgono una funzione analoga ai controlli dell'integrità di Route 53. Non create controlli di integrità di Route 53 per EC2 le istanze registrate con un sistema di bilanciamento del carico ELB. **Bucket S3** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un bucket S3. **Endpoint dell'interfaccia di Amazon VPC** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un endpoint dell'interfaccia Amazon VPC. **Altri record nella stessa zona ospitata** Se la AWS risorsa specificata in **Endpoint** è un record o un gruppo di record (ad esempio, un gruppo di record ponderati) ma non è un altro record di alias, ti consigliamo di associare un controllo dello stato a tutti i record dell'endpoint. Per ulteriori informazioni, consulta [Cosa accade se si omettono i controlli dell'integrità?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID record Inserisci un valore che identifichi in modo univoco questo record nel gruppo di record basati su IP. # Valori specifici per record di risposta multivalore Quando crei record di risposta multivalore, specifichi i valori seguenti. **Nota** La creazione di record alias di risposta multivalore non è supportata. **Topics** + [Policy di routing](#rrsets-values-multivalue-routing-policy) + [Nome record](#rrsets-values-multivalue-name) + [Tipo di record](#rrsets-values-multivalue-type) + [TTL (secondi)](#rrsets-values-multivalue-ttl) + [Valore/instradamento traffico a](#rrsets-values-multivalue-value) + [Controllo dell’integrità](#rrsets-values-multivalue-associate-with-health-check) + [ID record](#rrsets-values-multivalue-set-identifier) ## Policy di routing Scegli **Risposta multivalore**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per tutti i record nel gruppo di record multivalore. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona qualsiasi valore ad eccezione di **NS** o **CNAME**. Seleziona lo stesso valore per tutti i record nel gruppo di record di risposta multivalore. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. **Nota** Se crei due o più record di risposta multivalore con lo stesso nome e tipo, stai utilizzando la consolle e se specifichi diversi valori per **TTL**, Route 53 modifica il valore di **TTL** per tutti i record impostandolo sull'ultimo valore specificato. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Quando inserisci più di un valore, inserisci ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — IPv4 indirizzo** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (ad esempio i record di failover o ponderati) e specifichi il controllo dello stato IDs per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Selezioni **Sì** per **Valutazione dell'integrità della destinazione** per un record alias o i record in un gruppo di alias di failover, alias di geolocalizzazione, alias di latenza o alias ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## ID record Immetti un valore che identifica in modo univoco questo record nel gruppo di record di risposta multivalore. # Valori specifici per record ponderati Quando crei record ponderati, specifichi i valori seguenti. **Topics** + [Policy di routing](#rrsets-values-weighted-routing-policy) + [Nome record](#rrsets-values-weighted-name) + [Tipo di record](#rrsets-values-weighted-type) + [TTL (secondi)](#rrsets-values-weighted-ttl) + [Valore/instradamento traffico a](#rrsets-values-weighted-value) + [Weight](#rrsets-values-weighted-weight) + [Controllo dell’integrità](#rrsets-values-weighted-associate-with-health-check) + [ID record](#rrsets-values-weighted-set-identifier) ## Policy di routing Selezionare **Weighted (Ponderato)**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Nome record**. Immetti lo stesso nome per tutti i record nel gruppo di record ponderati. Per ulteriori informazioni sui nomi record, consultare [Nome record](resource-record-sets-values-shared.md#rrsets-values-common-name). ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona lo stesso valore per tutti i record nel gruppo dei record ponderati. ## TTL (secondi) La quantità di tempo, in secondi, per cui si desidera che i resolver ricorsivi DNS archivino nella cache le informazioni relative a questo record. Se si specifica un valore più lungo (ad esempio, 172800 secondi o due giorni), si riduce il numero di chiamate che i resolver ricorsivi DNS devono eseguire per permettere a Route 53 di ottenere le informazioni più recenti in questo record. Ciò ha l’effetto di ridurre la latenza e i costi per il servizio Route 53. Per ulteriori informazioni, consulta [Come Amazon Route 53 instrada il traffico per il tuo dominio](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). Tuttavia, se si specifica un valore più lungo per TTL, è necessario più tempo perché le modifiche al record (ad esempio, un nuovo indirizzo IP) abbiano effetto in quanto i resolver ricorsivi utilizzano i valori nella cache per periodi più lunghi prima di chiedere a Route 53 le informazioni più recenti. Se stai modificando le impostazioni per un dominio o sottodominio che è già in uso, ti consigliamo di specificare inizialmente un valore più breve, ad esempio 300 secondi, e aumentare il valore dopo aver verificato che le nuove impostazioni siano corrette. Se stai associando questo record a un controllo dell'integrità, ti consigliamo di specificare un TTL di 60 secondi o inferiore in modo che i client rispondano rapidamente alle modifiche dello stato. Devi specificare lo stesso valore **TTL** per tutti i record di questo gruppo di record ponderati. **Nota** Se crei due o più record ponderati con lo stesso nome e tipo e specifichi diversi valori **TTL**, Route 53 modifica il valore **TTL** per tutti i record utilizzando l'ultimo valore specificato. Se un gruppo di record ponderati include uno o più record alias ponderati che instradano il traffico a un load balancer ELB, ti consigliamo di specificare un TTL di 60 secondi per tutti i record non alias ponderati che hanno lo stesso nome e tipo. I valori diversi da 60 secondi (TTL per sistemi di bilanciamento del carico) modificheranno l'effetto dei valori che specifichi per **Weight (Peso)**. ## Valore/instradamento traffico a Scegli **Indirizzo IP o altro valore a seconda del tipo di record**. Immetti un valore appropriato per il valore di **Tipo di record**. Per tutti i tipi ad eccezione di **CNAME**, puoi immettere più di un valore. Immetti ogni valore su una riga distinta. Puoi instradare il traffico verso, o specificare i seguenti valori: + **A — IPv4 indirizzo** + **AAAA — IPv6 indirizzo** + **CAA - Autorizzazione della certification authority** + **CNAME - Nome canonico** + **MX - Scambio di posta** + **NAPTR - Puntatore dell'autorità dei nomi** + **PTR - Puntatore** + **SPF - Sender Policy Framework** + **SRV - Localizzatore di servizi** + **TXT - Testo** Per ulteriori informazioni sui valori precedenti, consulta [Valori comuni per il Value/Route traffico verso](resource-record-sets-values-shared.md#rrsets-values-common-value). ## Weight Un valore che determina la proporzione di query DNS a cui Route 53 risponde utilizzando il record corrente. Route 53 calcola la somma dei pesi per i record che hanno la stessa combinazione di tipo e nome DNS. Route 53 risponde quindi alle domande in base al rapporto tra il peso di una risorsa e il totale. Non puoi creare record non ponderati che hanno gli stessi valori per **Nome record** e **Tipo di record** come record ponderati. Immetti un intero compreso tra 0 e 255. Per disattivare il routing a una risorsa, imposta **Weight (Peso)** su 0. Se imposti **Weight (Peso)** su 0 per tutti i record nel gruppo, il traffico viene instradato a tutte le risorse con una probabilità equivalente. Ciò impedisce la disattivazione accidentale dell’instradamento per un gruppo di record ponderati. L'effetto di impostare **Weight (Peso)** su 0 è differente quando associ controlli dell'integrità a record ponderati. Per ulteriori informazioni, consulta [Come Amazon Route 53 sceglie i record quando viene configurato il controllo dell'integritàCome Route 53 sceglie i record quando viene configurato il controllo dell'integrità](health-checks-how-route-53-chooses-records.md). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (come i record di failover o ponderati) e specifichi il controllo IDs dello stato per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## ID record Immetti un valore che identifichi in modo univoco questo record nel gruppo di record ponderati. # Valori specifici per i record alias ponderati Quando crei record alias ponderati, specifichi i valori seguenti. Per ulteriori informazioni, consulta [Scelta tra record alias e non alias](resource-record-sets-choosing-alias-non-alias.md). **Topics** + [Policy di routing](#rrsets-values-weighted-alias-routing-policy) + [Nome record](#rrsets-values-weighted-alias-name) + [Tipo di record](#rrsets-values-weighted-alias-type) + [Valore/instradamento traffico a](#rrsets-values-weighted-alias-alias-target) + [Weight](#rrsets-values-weighted-alias-weight) + [Controllo dell’integrità](#rrsets-values-weighted-alias-associate-with-health-check) + [Valutazione dello stato della destinazione](#rrsets-values-weighted-alias-evaluate-target-health) + [ID record](#rrsets-values-weighted-alias-set-identifier) ## Policy di routing Scegli **Ponderata**. ## Nome record Immetti il nome del dominio o sottodominio a cui instradare il traffico. Il valore predefinito è il nome della zona ospitata. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo **Name (Nome)**. Immetti lo stesso nome per tutti i record nel gruppo di record ponderati. Per ulteriori informazioni sui nomi dei record, consultare [Nome record](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) ## Tipo di record Il tipo di record DNS. Per ulteriori informazioni, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). Seleziona il valore applicabile in base alla AWS risorsa verso cui stai indirizzando il traffico: **API regionali personalizzate di API Gateway o API con ottimizzate per l'edge** Seleziona **A — IPv4 indirizzo**. **Endpoint dell'interfaccia di Amazon VPC** Seleziona **A — IPv4 indirizzo**. **CloudFront distribuzione** Seleziona **A — IPv4 indirizzo**. Se IPv6 è abilitato per la distribuzione, crea due record, uno con il valore **A - IPv4 indirizzo** per **Tipo** e uno con il valore **AAAA - IPv6 indirizzo**. **Servizio App Runner** Seleziona **A — indirizzo IPv4 ** **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Seleziona **A — IPv4 indirizzo** **Sistema di bilanciamento del carico ELB** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Bucket Amazon S3** Seleziona **A — indirizzo IPv4 ** **OpenSearch Servizio** Seleziona **A — IPv4 indirizzo** o **AAAA — IPv6 ** indirizzo **Un altro record si trova in questa zona ospitata** Seleziona il tipo di record per cui stai creando l'alias. Sono supportati tutti i tipi a eccezione di **NS** e **SOA**. Se stai creando un record alias che ha lo stesso valore della zona ospitata (nota come *Apex di zona*), non puoi instradare il traffico verso un record il cui valore di **Type (Tipo)** è **CNAME**. Questo perché il record alias deve avere lo stesso tipo del record a cui stai instradando il traffico e la creazione di un record CNAME per l'apex di zona non è supportata neanche per un record alias. Seleziona lo stesso valore per tutti i record nel gruppo dei record ponderati. ## Valore/instradamento traffico a Il valore che scegli dall'elenco o che digiti nel campo dipende dalla AWS risorsa verso cui stai indirizzando il traffico. Per informazioni sulle AWS risorse a cui puoi indirizzare, consulta [Common values for alias records for value/route traffic](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target) to. Per ulteriori informazioni su come configurare Route 53 per indirizzare il traffico verso AWS risorse specifiche, consulta[Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). ## Weight Un valore che determina la proporzione di query DNS a cui Route 53 risponde utilizzando il record corrente. Route 53 calcola la somma dei pesi per i record che hanno la stessa combinazione di tipo e nome DNS. Route 53 risponde quindi alle domande in base al rapporto tra il peso di una risorsa e il totale. Non puoi creare record non ponderati che hanno gli stessi valori per **Nome record** e **Tipo di record** come record ponderati. Immetti un intero compreso tra 0 e 255. Per disattivare il routing a una risorsa, imposta **Weight (Peso)** su 0. Se imposti **Weight (Peso)** su 0 per tutti i record nel gruppo, il traffico viene instradato a tutte le risorse con una probabilità equivalente. Ciò impedisce la disattivazione accidentale dell’instradamento per un gruppo di record ponderati. L'effetto di impostare **Weight (Peso)** su 0 è differente quando associ controlli dell'integrità a record ponderati. Per ulteriori informazioni, consulta [Come Amazon Route 53 sceglie i record quando viene configurato il controllo dell'integritàCome Route 53 sceglie i record quando viene configurato il controllo dell'integrità](health-checks-how-route-53-chooses-records.md). ## Controllo dell’integrità Seleziona un controllo dell'integrità se desideri che Route 53 controlli l'integrità di un determinato endpoint e risponda alle query DNS utilizzando questo record solo quando l'endpoint è integro. Route 53 non controlla l'integrità dell'endpoint specificato nel record, ad esempio l'endpoint specificato dall'indirizzo IP nel campo **Valore**. Quando selezioni un controllo dell'integrità per un record, Route 53 controlla l'integrità dell'endpoint specificato nel controllo dell'integrità. Per informazioni su come Route 53 determina se un endpoint è integro, consulta [Come Amazon Route 53 determina se un controllo dell'integrità è integroCome Route 53 determina se un controllo dell'integrità è integro](dns-failover-determining-health-of-endpoints.md). L'associazione di un controllo dell'integrità a un record è utile solo quando Route 53 deve scegliere tra due o più record per rispondere a una query DNS e desideri che Route 53 effettui la scelta in parte in base all'avanzamento di un controllo dell'integrità. Utilizza i controlli dell'integrità solo nelle configurazioni seguenti: + Stai controllando lo stato di tutti i record di un gruppo di record con lo stesso nome, tipo e policy di routing (come i record di failover o ponderati) e specifichi il controllo IDs dello stato per tutti i record. Se il controllo dell'integrità di un record indica un endpoint non integro, Route 53 smette di rispondere alle query utilizzando il valore di tale record. + Seleziona **Yes** (Sì) per l'opzione **Evaluate target health** (Valutazione dello stato target) per un record alias o per i record di un gruppo di alias di failover, di geolocalizzazione, di latenza, basati su IP o ponderati. Se i record alias fanno riferimento a record non alias appartenenti alla stessa zona ospitata, devi specificare anche i controlli dell'integrità per i record a cui viene fatto riferimento. Se associ un controllo dell'integrità a un record alias e selezioni anche **Yes** (Sì) per **Evaluate Target Health** (Valuta integrità destinazione), entrambi devono essere veri. Per ulteriori informazioni, consulta [Cosa accade se si associa un controllo dell'integrità a un record alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias). Se i controlli dell'integrità specificano l'endpoint solo in base al nome del dominio, ti consigliamo di creare un controllo dell'integrità separato per ciascun endpoint. Ad esempio, puoi creare un controllo dell'integrità per ciascun server HTTP che gestisce contenuti per www.esempio.com. Come valore di **Nome dominio**, specifica il nome di dominio del server (ad esempio, us-east-2-www.esempio.com), anziché il nome dei record (esempio.com). **Importante** In questa configurazione, se crei un controllo dell'integrità per il quale il valore di **Domain Name (Nome dominio)** corrisponde al nome dei record e quindi associ il controllo dell'integrità a quei record, i risultati del controllo dell'integrità saranno imprevedibili. ## Valutazione dello stato della destinazione Seleziona **Sì** se desideri che Route 53 determini se rispondere alle query DNS utilizzando questo record controllando l'integrità della risorsa specificata da **Endpoint**. Tenere presente quanto segue: **API Gateway personalizzato, regionale APIs e ottimizzato per l'edge APIs** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un'API regionale personalizzata di API Gateway o un'API ottimizzata per l'edge. **CloudFront distribuzioni** Non è possibile impostare **Evaluate target health** su **Sì** quando l'endpoint è una CloudFront distribuzione. **Ambienti Elastic Beanstalk con sottodomini regionalizzati** Se specifichi un ambiente Elastic Beanstalk in **Endpoint** e l'ambiente contiene un load balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. (Un ambiente contiene automaticamente un load balancer ELB se include più di un'istanza Amazon EC2.) Se imposti **Valutazione dell'integrazione della destinazione** su **Sì** e nessuna istanza Amazon EC2 è integra o lo stesso load balancer non è integro, Route 53 instrada le query ad altre risorse disponibili integre, se presenti. Se l'ambiente contiene una sola istanza Amazon EC2, non sono previsti requisiti speciali. **Load balancer ELB** Il comportamento del controllo dell'integrità dipende dal tipo di load balancer: + **Classic Load Balancer**: se in **Endpoint** specifichi un Classic Load Balancer ELB, Elastic Load Balancing instrada le query solo alle istanze Amazon EC2 integre registrate con il load balancer. Se imposti **Valutazione dell'integrità della destinazione** su **Sì** e né le istanze EC2 né il load balancer risultano integri, Route 53 instrada le query ad altre risorse. + **Application Load Balancer/Network Load Balancer**: se specifichi un Application Load Balancer/Network Load Balancer ELB e imposti **Valutazione dell'integrità della destinazione** su **Sì**, Route 53 instrada le query al load balancer in base all'integrità dei gruppi di destinazione a esso associati: + Affinché un Application Load Balancer/Network Load Balancer venga considerato integro, ogni gruppo target contenente target deve includere almeno un target integro. Se un gruppo target contiene solo target non integri, il load balancer viene considerato non integro e Route 53 instrada le query ad altre risorse. + Un gruppo target che non include target registrati viene considerato non integro. Quando crei un load balancer, configuri le impostazioni per i controlli dell'integrità di Elastic Load Balancing, che svolgono una funzione analoga ai controlli dell'integrità di Route 53. Non creare controlli dell'integrità di Route 53 per le istanze EC2 che record con un load balancer ELB. **Bucket S3** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un bucket S3. **Endpoint dell'interfaccia di Amazon VPC** Non sono previsti requisiti speciali per impostare **Valutazione dell'integrità della destinazione** su **Sì** quando l'endpoint è un endpoint dell'interfaccia Amazon VPC. **Altri record nella stessa zona ospitata** Se la AWS risorsa specificata in **Endpoint** è un record o un gruppo di record (ad esempio, un gruppo di record ponderati) ma non è un altro record di alias, ti consigliamo di associare un controllo dello stato a tutti i record dell'endpoint. Per ulteriori informazioni, consulta [Cosa accade se si omettono i controlli dell'integrità?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting). ## ID record Immetti un valore che identifichi in modo univoco questo record nel gruppo di record ponderati. # Creazione di record mediante importazione di un file di zona Se esegui la migrazione da un altro fornitore di servizi DNS, e se il tuo attuale fornitore di servizi DNS consente di esportare le impostazioni DNS correnti a un file di zona, puoi creare rapidamente tutti i record per una zona ospitata di Amazon Route 53 tramite l'importazione di un file di zona. **Nota** Un file di zona utilizza un formato standard noto come BIND per rappresentare i record in un formato di testo. Per ulteriori informazioni sul formato di un file di zona, consulta la voce Wikipedia relativa ai [file di zona](https://en.wikipedia.org/wiki/Zone_file). Ulteriori informazioni sono disponibili in [RFC 1034, Nomi di dominio - Concetti e funzionalità](https://datatracker.ietf.org/doc/html/rfc1034) sezione 3.6.1 e [RFC 1035, Nome di dominio - Implementazione e specifica](https://datatracker.ietf.org/doc/html/rfc1035) sezione 5. Se desideri creare record importando un file di zona, tieni presente quanto segue: + Il file di zona deve essere in formato conforme a RFC. + Il nome di dominio dei record nel file di zona deve corrispondere al nome della zona ospitata. + Route 53 supporta le parole chiave `$ORIGIN` e `$TTL`. Se il file di zona include parole chiave `$GENERATE` o `$INCLUDE`, l'importazione ha esito negativo e Route 53 restituisce un errore. + Quando importi il file di zona, Route 53 ignora il record SOA nel file di zona. Route 53 ignora inoltre qualsiasi record NS che ha lo stesso nome della zona ospitata. + Puoi importare un massimo di 1.000 record. + Se la zona ospitata contiene già record visualizzati nel file di zona, il processo di importazione ha esito negativo e non viene creato alcun record. + Per i record TXT che contengono caratteri di barra rovesciata, il processo di importazione dei file di zona interpreta determinate sequenze di barre rovesciate come caratteri di controllo. Per includere caratteri letterali di barra rovesciata nei valori dei record TXT: + Utilizzate la doppia barra rovesciata (`\\\\`) nel file di zona per rappresentare una singola barra rovesciata letterale nel record TXT finale. + Ad esempio, se il record TXT deve contenere `\\jYTDWqH...` (con una barra rovesciata letterale e j), specificalo nel file di zona. `\\\\jYTDWqH...` Ciò è particolarmente importante per i record delle sfide ACME e altri record TXT che contengono caratteri letterali con barra rovesciata. + Per i record TXT lunghi (come i record DKIM), il processo di importazione dei file di zona supporta la suddivisione del contenuto in più stringhe. Per creare record TXT con più stringhe: + Usa righe separate nel tuo file di zona con lo stesso nome e tipo di record. **Example** ``` example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC" example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f" example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x" ``` Il processo di importazione li combina automaticamente in un unico record TXT con più stringhe. Ogni singola stringa può contenere fino a 65.535 caratteri. Non concatenate stringhe lunghe in un unico valore tra virgolette. + Ti consigliamo di esaminare i contenuti del file di zona per verificare che i nomi dei record includano o escludano un punto finale come appropriato: + Quando il nome di un record nel file di zona include un punto finale (`example.com.`), il processo di importazione interpreta il nome come nome di dominio completo e crea un record Route 53 con questo nome. + Quando il nome di un record nel file di zona non include un punto finale (`www`), il processo di importazione concatena il nome con il nome di dominio nel file di zona (`example.com`) e crea un record Route 53 con il nome concatenato (`www.example.com`). Il processo di esportazione non aggiunge un punto finale ai nomi di dominio completi di un record, perciò il processo di importazione di Route 53 aggiunge il nome di dominio al nome del record. Supponiamo ad esempio di importare record nella zona ospitata `example.com` e il nome di un record MX nel file di zona è `mail.example.com`, senza punto finale. Il processo di importazione di Route 53 crea un record MX denominato `mail.example.com.example.com`. **Importante** Per i record CNAME, MX, PTR e SRV, questo comportamento, inoltre, è valido per il nome di dominio che è incluso nel valore RDATA. Supponiamo ad esempio che tu abbia un file di zona per `example.com`. Se un record CNAME nel file di zona (`support`, senza un punto finale) ha un valore RDATA di `www.example.com` (anch'esso senza un punto finale), il processo di importazione crea un record Route 53 con il nome `support.example.com` che consente di instradare il traffico a `www.example.com.example.com`. Prima di importare il tuo file di zona, rivedi i valori RDATA e aggiornali come applicabile. Per i record TXT contenenti caratteri di barra rovesciata, utilizzate le barre rovesciate doppie () `\\\\` nel file di zona per rappresentare le barre rovesciate letterali. Route 53 non supporta l'esportazione di record a un file di zona. **Nota** Se stai creando un record con lo stesso nome della zona ospitata, non immettere un valore (ad esempio, il simbolo @) nel campo Name (Nome). **Come creare record mediante importazione di un file di zona** 1. Ottieni un file di zona dal fornitore di servizi DNS che serve attualmente il dominio. Il processo e la terminologia variano da un fornitore di servizi all'altro. Fai riferimento all'interfaccia del fornitore e alla relativa documentazione per informazioni sull'esportazione o il salvataggio dei record in un file di zona o un file BIND. Se il processo non è ovvio, prova a chiedere al servizio di assistenza clienti del tuo attuale fornitore di DNS informazioni su *elenco di record* o *file di zona*. 1. Accedi a e apri la console Route 53 all'indirizzo. Console di gestione AWS [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Nel pannello di navigazione, scegli **Zone ospitate**. 1. Nella pagina **Zone ospitate**, crea una nuova zona ospitata: 1. Scegli **Crea zona ospitata**. 1. Inserisci il nome del tuo dominio e, facoltativamente, un commento. 1. Scegli **Create** (Crea). 1. Scegli **Importa file di zona**. 1. Nel riquadro **Importa file di zona**, incolla il contenuto del file di zona nella casella di testo **File di zona**. 1. Scegli **Importa**. **Nota** A seconda del numero di record nel file di zona, potrebbe essere necessario attendere alcuni minuti prima che vengano creati i record. 1. Se usi un altro servizio DNS per il dominio (cosa comune se hai registrato il dominio con un altro registrar), migra il servizio DNS a Route 53. Al termine di questa fase, il tuo registrar inizierà a identificare Route 53 come servizio DNS in risposta alle query DNS per il tuo dominio e le query inizieranno a essere inviate ai server DNS di Route 53. (Normalmente, ci sono uno o due giorni di ritardo prima che le query DNS vengano instradate a Route 53 perché le informazioni sul servizio DNS precedente sono memorizzate nella cache nel resolver DNS per quel periodo.) Per ulteriori informazioni, consulta [Rendere Amazon Route 53 il servizio DNS per un dominio esistenteRendere il Route 53 il servizio DNS per un dominio esistente](MigratingDNS.md). # Modifica di record La procedura seguente spiega come modificare i record utilizzando la console Amazon Route 53. Per informazioni su come modificare i record utilizzando l'API Route 53, consulta [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)*Amazon Route 53 API Reference*. **Nota** Le modifiche ai registri richiedono tempo per propagarsi ai server DNS di Route 53. Attualmente, l'unico modo per verificare che le modifiche si siano propagate è utilizzare l'azione [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi. **Come modificare i record utilizzando la console Route 53** 1. Se non stai modificando record alias, passa al punto 2. Se stai modificando record alias che instradano il traffico a Classic Load Balancer, Application Load Balancer o Network Load Balancer Elastic Load Balancing e se hai creato la zona ospitata Route 53 e il sistema di bilanciamento del carico utilizzando account diversi, esegui la procedura [Come ottenere il nome DNS per un sistema di bilanciamento del carico Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) per ottenere il nome DNS per il sistema di bilanciamento del carico. Se stai modificando i record di alias per qualsiasi altra AWS risorsa, vai al passaggio 2. 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**. 1. Nella pagina **Hosted Zones (Zone ospitate)**, scegliere la riga per la zona ospitata che contiene i record che da modificare. 1. Seleziona la riga per il record da modificare e immetti le modifiche nel riquadro **Modifica record**. 1. Immetti i valori applicabili. Per ulteriori informazioni, consulta [Di seguito sono descritti i valori che devi specificare durante la creazione o la modifica di record di Amazon Route 53.](resource-record-sets-values.md). 1. Scegli **Salva modifiche**. 1. Se si stanno modificando più record, ripetere le fasi da 5 a 7. # Eliminazione di record La procedura seguente spiega come eliminare record utilizzando la console Route 53. Per informazioni su come eliminare i record utilizzando l'API Route 53, consulta [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)*Amazon Route 53 API Reference*. **Nota** Le modifiche ai registri richiedono tempo per propagarsi ai server DNS di Route 53. Attualmente, l'unico modo per verificare che le modifiche si siano propagate è utilizzare l'azione [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi. **Come eliminare record** 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. Nella pagina Hosted Zones (Zone ospitate), scegliere la riga per la zona ospitata che contiene i record da eliminare. 1. Nell'elenco dei record, seleziona il record che desideri eliminare. Per selezionare più record consecutivi, selezionare la prima riga, tenere premuto il tasto **MAIUSC** e selezionare l'ultima riga. Per selezionare più record non consecutivi, selezionare la prima riga, tenere premuto il tasto **Ctrl** e selezionare righe aggiuntive. Non è possibile eliminare i record con un valore di **NS** o **SOA** per **Type (Tipo)**. 1. Scegli **Elimina**. 1. Scegli **Elimina** per chiudere la finestra di dialogo. # Elencazione di record La procedura seguente spiega come usare la console Amazon Route 53 per elencare i record in una zona ospitata. Per informazioni su come elencare i record utilizzando l'API Route 53, consulta [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)*Amazon Route 53 API Reference*. **Come elencare record** 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**. 1. Nella pagina **Hosted zones (Zone ospitate) **, scegli il nome di una zona ospitata. 1. Per modificare la modalità di ricerca, scegli l'icona a forma di ingranaggio in alto a destra della tabella **Record**. Scegli una delle seguenti opzioni: + **Automatica** In questa modalità, il servizio utilizza un filtro basato su una serie di record. Completa per meno di 2.000 record e veloce per più di 2.000 record. + **Completa** In questa modalità, tutti i filtri di ricerca sono disponibili, ma le prestazioni di ricerca potrebbero essere più lente. + **Veloce** In questa modalità, alcune funzionalità avanzate non sono disponibili, ma le prestazioni di ricerca saranno più veloci. Per visualizzare solo i record selezionati, immetti i criteri di ricerca applicabili sopra l'elenco dei record. Nella modalità automatica, il comportamento di ricerca varia a seconda che la zona ospitata zone contenga fino a 2.000 record o più di 2.000 record: **Fino a 2.000 record e modalità completa** + Per visualizzare i record che hanno valori specifici, immetti un valore nella barra di ricerca e premi **Invio**. Ad esempio, per visualizzare i record che hanno un indirizzo IP che inizia con **192.0**, digita il valore nel campo **di ricerca** e premi **Invio**. + Per visualizzare solo i record con lo stesso tipo di record DNS, seleziona **Tipo di record** dall'elenco a discesa, quindi specifica il tipo di record. + Per visualizzare solo record alias, seleziona **Alias** nell'elenco a discesa e specifica **Yes**. + Per visualizzare solo record ponderati, seleziona **Policy di routing** nell'elenco a discesa e specifica **WEIGHTED**. **Più di 2.000 record e modalità veloce** + È possibile eseguire la ricerca solo su nomi di record, non sui valori dei record. Inoltre, non è possibile filtrare in base al tipo di record o sui record alias o ponderati. A tale scopo, posiziona il cursore nella casella di testo **Filtro**, seleziona **Proprietà**, quindi **Nome record**. + Per i record che hanno tre etichette (tre parti separate da punti), quando specifichi un valore nel campo di ricerca e premi **Invio**, la console Route 53 esegue automaticamente una ricerca jolly nella terza etichetta da destra nel nome del record. Ad esempio, supponiamo che la zona ospitata, ad esempio esempio.com contenga 100 record denominati record1.esempio.com tramite record100.esempio.com. (Record1 è la terza etichetta da destra.) Ecco cosa succede quando si ricercano i seguenti valori: + **record1** - La console Route 53 cerca **record1\$1.esempio.com**, che restituisce **record1.esempio.com**, **record10.esempio.com** tramite **record19.esempio.com** e **record100.esempio.com**. + **record1.esempio.com**: come nell'esempio precedente, la console cerca **record1\$1.example.com** e restituisce lo stesso record. + **1**: la console ricerca **1\$1.example.com** e non restituisce alcun record. + **example**: la console cerca **example\$1.example.com** e non restituisce alcun record. + **esempio.com**: in questo esempio, la console non esegue una ricerca con caratteri jolly. Si restituiscono tutti i record nella zona ospitata. + **Modalità di ricerca automatica**: quando utilizzi questa modalità di ricerca, per poter effettuare la ricerca è necessario prima fornire una proprietà, ad esempio il nome del record. **Nota** Se la terza etichetta da destra contiene uno o più trattini (ad esempio `third-label.example.com`) e si cerca la parte della terza etichetta immediatamente prima del trattino (`third` in questo esempio), Route 53 non restituirà alcun record. Al contrario, includere il trattino (cercare `third-`) o omettere il carattere immediatamente prima del trattino (cercare `third`). + Per i record che hanno quattro o più etichette, è necessario specificare il nome esatto del record. Non sono supportate ricerche con caratteri jolly.. Ad esempio, se le zone ospitate includono un record denominato label4.record1.esempio.com, è possibile individuare quel record solo se si specifica **label4.record1.esempio.com** nel campo di ricerca. # 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**. # Utilizzo AWS Cloud Map per creare record e controlli sanitari Se si desidera instradare il traffico Internet o il traffico all'interno di un Amazon VPC a componenti dell'applicazione o di microservizi, puoi utilizzare AWS Cloud Map per creare automaticamente i record e, facoltativamente, i controlli dell'integrità. Per ulteriori informazioni, consulta la [Guida per gli sviluppatori di AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/). # Comportamenti e limitazioni di DNS La messaggistica DNS è soggetta a fattori che influiscono su come si creano e utilizzano zone ospitate e record. Questa sezione descrive questi fattori. ## Dimensioni massime della risposta Per la conformità agli standard DNS, le dimensioni delle risposte inviate su UDP non superano i 512 byte. Le risposte che superano 512 byte vengono troncate e il resolver deve emettere di nuovo la richiesta su TCP. Se il resolver supporta EDNS0 (secondo quanto definito nella specifica [RFC 2671](https://tools.ietf.org/html/rfc2671)) e pubblicizza l'opzione di EDNS0 ad Amazon Route 53, Route 53 consente risposte fino a 4.096 byte su UDP, senza troncamento. ## Elaborazione della sezione autorevole Per query dall'esito positivo, Route 53 collega record di server di nomi (NS) per le zone ospitate alla sezione Authority della risposta DNS. Per i nomi che non vengono trovati (risposte NXDOMAIN), Route 53 collega il record origine di autorità (SOA) (secondo quanto definito nella specifica [RFC 1035](https://tools.ietf.org/html/rfc1035)) per la zona ospitata pertinente alla sezione Authority della risposta DNS. ## Elaborazione di sezioni aggiuntive Route 53 collega record alla sezione aggiuntiva. Se i record sono noti e appropriati, il servizio collega record A o AAAA per qualsiasi target di un record MX, CNAME, NS o SRV citato nella sezione delle risposte. Per ulteriori informazioni su questi tipi di record DNS, consulta [Tipi di record DNS supportati](ResourceRecordTypes.md). # Argomenti correlati Per informazioni sul trasferimento della registrazione del dominio (non solo dell'hosting DNS) su Route 53, consulta i seguenti argomenti: + [Lista di controllo prima del trasferimento per i trasferimenti di dominio](domain-transfer-checklist.md)— Completa questa lista di controllo prima di trasferire la registrazione del dominio per evitare errori di trasferimento comuni. + [Trasferimento della registrazione per un dominio ad Amazon Route 53](domain-transfer-to-route-53.md)— Step-by-step procedura per il trasferimento della registrazione del dominio da un altro registrar a Route 53. + [Trasferimento dei domini](domain-transfer.md)— Panoramica di tutte le opzioni di trasferimento del dominio, compresi i trasferimenti tra AWS account.