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à. # Best practice per Amazon Route 53 Questa sezione fornisce le best practice per vari componenti di Amazon Route 53, tra cui: 1. **Le migliori pratiche DNS:** + Comprendi i compromessi tra i valori TTL (time to live) e la reattività rispetto all'affidabilità. + Se possibile, utilizza i record alias anziché i record CNAME per migliorare le prestazioni e risparmiare sui costi. + Configura le politiche di routing predefinite per garantire che tutti i client ricevano una risposta. + Sfrutta il routing basato sulla latenza per ridurre al minimo la latenza delle applicazioni e il routing per garantire stabilità e prevedibilità. geolocation/geoproximity + Verifica la propagazione delle modifiche utilizzando l'API per flussi di lavoro automatizzati. `GetChange` + Delega i sottodomini dalla zona principale per un routing coerente. + Evita risposte singole di grandi dimensioni utilizzando il routing delle risposte multivalore. 1. **Le migliori pratiche di Resolver:** + Previeni i loop di routing evitando di associare lo stesso VPC sia a una regola Resolver che al relativo endpoint in ingresso. + Implementa le regole dei gruppi di sicurezza per ridurre il sovraccarico di tracciamento delle connessioni e massimizzare la velocità di trasmissione delle query. + Configura gli endpoint in entrata con indirizzi IP in più zone di disponibilità per la ridondanza. + Fai attenzione ai potenziali attacchi DNS zone walking e contatta l' AWS assistenza se i tuoi endpoint subiscono un throttling. 1. **Le migliori pratiche per i controlli sanitari:** + Segui i consigli per ottimizzare i controlli di integrità di Amazon Route 53 per garantire un monitoraggio affidabile delle tue risorse Aderendo a queste best practice, puoi ottimizzare le prestazioni, l'affidabilità e la sicurezza della tua infrastruttura DNS, garantendo un instradamento efficiente ed efficace del traffico verso le tue applicazioni e i tuoi servizi **Topics** + [Le best practice per il DNS Amazon Route 53](best-practices-dns.md) + [Le migliori pratiche per VPC Resolver](best-practices-resolver.md) + [Best practice per i controlli dell'integrità di Amazon Route 53](best-practices-healthchecks.md) # Le best practice per il DNS Amazon Route 53 Segui queste best practice per avere risultati ottimali utilizzando il DNS Amazon Route 53. **Utilizza le funzioni del piano dati per il failover DNS e il ripristino delle app** I piani dati per Route 53, compresi i controlli dello stato, e il controllo del routing di Amazon Application Recovery Controller (ARC) sono distribuiti a livello globale e sono progettati per garantire disponibilità e funzionalità al 100%, anche in caso di eventi gravi. Si integrano tra loro e non dipendono dalla funzionalità del piano di controllo. Pur essendo i piani di controllo per questi servizi, comprese le console, generalmente molto affidabili, sono progettati in modo più centralizzato e danno priorità alla durata e alla coerenza anziché all'elevata disponibilità. Per scenari come il failover durante il disaster recovery, ti consigliamo di utilizzare funzionalità come i controlli dello stato di Route 53 e il controllo del routing ARC che si basano sulla funzionalità del piano dati per aggiornare il DNS. Per ulteriori informazioni, consulta [Nozioni sul piano di controllo e sul piano dati](route-53-concepts.md#route-53-concepts-control-and-data-plane) e [Blog: Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/). **Scelta dei valori TTL per i registri DNS** Il TTL del DNS è il valore numerico (in secondi) utilizzato dai resolver DNS per decidere la durata di memorizzazione di un registro nella cache senza effettuare un'altra query su Route 53. Tutti i record DNS devono specificare un TTL. L'intervallo suggerito per i valori TTL è compreso tra 60 e 172.800 secondi. La scelta di un TTL è un compromesso tra latenza, affidabilità e reattività al cambiamento. Se un record è più breve TTLs , i resolver DNS notano gli aggiornamenti del record più rapidamente in quanto devono eseguire query più frequentemente. Ciò aumenterà il volume (e il costo) della query. Man mano che il TTL si allunga, i resolver DNS rispondono alle query dalla cache più spesso, il che in genere è più veloce, più economico e, in alcune situazioni, più affidabile, perché evita le query su Internet. Non esiste un valore corretto, ma vale la pena riflettere su quanto sono importanti per i tuoi fini la reattività o l'affidabilità. Aspetti da considerare durante l'impostazione dei valori TTL: + Imposta il record DNS TTLs per il periodo di tempo che puoi permetterti di aspettare che una modifica abbia effetto. Ciò vale specialmente per le deleghe (set di registri NS) o altri registri che raramente cambiano, ad esempio i registri MX. Per questi record, si consiglia un periodo più lungo TTLs . I valori comunemente usati sono compresi tra un'ora (3600 secondi) e un giorno (86.400 secondi). + Per i record che devono essere modificati nell'ambito di un meccanismo di failover rapido (in particolare i record sottoposti a verifica dello stato di integrità), è consigliabile utilizzare un valore inferiore TTLs. Per questo scenario, è comune impostare un TTL di 60 o 120 secondi. + Quando si desidera apportare modifiche alle voci DNS critiche, si consiglia di abbreviare temporaneamente le. TTLs Quindi puoi apportare le modifiche, osservare e ripristinare allo stato precedente se necessario. Dopo aver finalizzato le modifiche e se funzionano come previsto, puoi aumentare il TTL. Per ulteriori informazioni, consulta [TTL (secondi)](resource-record-sets-values-shared.md#rrsets-values-common-ttl). **Registri CNAME** I registri CNAME del DNS sono un modo per passare da un nome dominio a un altro. Se un resolver DNS risolve domain-1.example.com e trova un CNAME che indica domain-2.example.com, il resolver DNS, prima di rispondere, procede alla risoluzione di domain-2.example.com. Questi registri sono utili in molte situazioni, ad esempio per garantire la coerenza quando un sito Web ha più di un nome dominio. Tuttavia, i resolver DNS devono effettuare più query a cui rispondere CNAMEs, il che aumenta la latenza e i costi. Ove possibile, un'alternativa più veloce ed economica consiste nell'utilizzare un registro alias di Route 53. I record di alias consentono a Route 53 di rispondere con una risposta diretta per AWS le risorse (ad esempio, un sistema di bilanciamento del carico) e per altri domini all'interno della stessa zona ospitata. Per ulteriori informazioni, consulta [Instradamento del traffico Internet verso le tue risorse AWS](routing-to-aws-resources.md). **Routing DNS avanzato** + Quando uutilizzi il routing basato sulla geolocalizzazione, sulla geoprossimità o sulla latenza, imposta sempre un valore di default, a meno che non desideri che alcuni client ricevano *nessuna risposta*. + Per minimizzare la latenza delle applicazioni, utilizza il routing basato sulla latenza. Questo tipo di dati di routing può cambiare frequentemente. + Per assicurare la stabilità e la prevedibilità del routing, utilizza il routing basato sulla geolocalizzazione o sulla geoprossimità. Per ulteriori informazioni, consulta [Routing di geolocalizzazione](routing-policy-geo.md), [Geoproximity routing](routing-policy-geoproximity.md) e [Routing basato sulla latenza](routing-policy-latency.md). **Propagazione della modifica DNS** Quando crei o aggiorni un record o una zona ospitata utilizzando la console o l'API Route 53, occorre del tempo prima che la modifica venga riflessa su Internet. Il processo si chiama *propagazione delle modifiche*. Sebbene di solito la propagazione richieda globalmente meno di un minuto, a volte può capitare che una modifica abbia un ritardo, ad esempio per problemi di sincronizzazione in una posizione o, in rari casi, per problemi interni al piano di controllo centrale. Se state creando flussi di lavoro di provisioning automatizzato ed è importante attendere il completamento della propagazione delle modifiche prima di procedere con la fase successiva del flusso di lavoro, utilizzate l'[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API per verificare che le modifiche al DNS siano entrate in vigore (). `Status =INSYNC` **Delega DNS** Quando si delegano più livelli di sottodomini nel DNS, è importante che la delega venga effettuata sempre dalla zona madre. Ad esempio, se si sta delegando www.dept.example.com, è necessario farlo dalla zona dept.example.com, non dalla example.com. Le deleghe da una zona *nonna* a una zona *figlia* potrebbero non funzionare o solo a tratti. Per ulteriori informazioni, consulta [Routing del traffico per sottodomini](dns-routing-traffic-for-subdomains.md). **Dimensioni della risposta del DNS** Evita di creare singole risposte di grandi dimensioni. Se le risposte eccedono i 512 byte, molti resolver DNS devono ripetere il tentativo su TCP anziché su UDP, il che può ridurre l'affidabilità e portare a un rallentamento delle risposte. Ti suggeriamo di utilizzare routing di risposte multivalore che scelgono 8 indirizzi IP integri e casuali per mantenere le risposte entro il limite di 512 byte. Per ulteriori informazioni, consulta [Routing di risposta multivalore](routing-policy-multivalue.md) e [Test server delle dimensioni della risposta del DNS](https://www.dns-oarc.net/oarc/services/replysizetest/). # Le migliori pratiche per VPC Resolver Questa sezione fornisce le best practice per ottimizzare Amazon Route 53 VPC Resolver, trattando i seguenti argomenti: 1. **Evitare configurazioni di loop con Resolver Endpoints:** + Previeni i loop di routing assicurandoti che lo stesso VPC non sia associato sia a una regola Resolver che al relativo endpoint in ingresso. + Utilizzalo per condividere tra account mantenendo le configurazioni AWS RAM di routing corrette VPCs . Per ulteriori informazioni, consulta [Evitare configurazioni loop con endpoint di Resolver](best-practices-resolver-endpoints.md) 1. **Scalabilità degli endpoint Resolver:** + Implementa regole di gruppo di sicurezza che consentano il traffico in base allo stato della connessione per ridurre il sovraccarico di tracciamento della connessione + Segui le regole consigliate sui gruppi di sicurezza per gli endpoint Resolver in entrata e in uscita per massimizzare la velocità di trasmissione delle query. + Monitora le combinazioni uniche di indirizzi IP e porte che generano traffico DNS per evitare limiti di capacità. Per ulteriori informazioni, consulta [Dimensionamento dell'endpoint di Resolver](best-practices-resolver-endpoint-scaling.md) 1. **Alta disponibilità per gli endpoint Resolver:** + Crea endpoint in entrata con indirizzi IP in almeno due zone di disponibilità per la ridondanza. + Fornisci interfacce di rete aggiuntive per garantire la disponibilità durante la manutenzione o i picchi di traffico Per ulteriori informazioni, consulta [Alta disponibilità di endpoint di Resolver](best-practices-resolver-endpoint-high-availability.md) 1. **Prevenzione degli attacchi DNS Zone Walking:** + Fai attenzione ai potenziali attacchi DNS zone walking, in cui gli aggressori tentano di recuperare tutti i contenuti dalle zone DNS con firma DNSSEC. + Se i tuoi endpoint subiscono un rallentamento dovuto alla sospetta camminata in zona, contatta il Supporto AWS per ricevere assistenza. Per ulteriori informazioni, consulta [Zona DNS](best-practices-resolver-zone-walking.md) Seguendo queste best practice, puoi ottimizzare le prestazioni, la scalabilità e la sicurezza delle tue implementazioni VPC Resolver, garantendo una risoluzione DNS affidabile ed efficiente per le tue applicazioni e risorse. # Evitare configurazioni loop con endpoint di Resolver Non associare lo stesso VPC a una regola del Resolver e al relativo endpoint in entrata (sia che si tratti di una destinazione diretta dell'endpoint o tramite un server DNS on-premise). Quando l'endpoint in uscita in una regola Resolver punta a un endpoint in ingresso che condivide un VPC con la regola, può causare un ciclo in cui la query viene continuamente passata tra gli endpoint in entrata e in uscita. La regola di inoltro può ancora essere associata ad altre regole VPCs condivise con altri account utilizzando (). AWS Resource Access Manager AWS RAM Le zone ospitate private associate all'hub o a un VPC centrale verranno comunque risolte dalle query agli endpoint in ingresso perché una regola del resolver di inoltro non modifica questa risoluzione. # Dimensionamento dell'endpoint di Resolver I gruppi di sicurezza dell'endpoint di Resolver utilizzano il monitoraggio delle connessioni per raccogliere informazioni sul traffico da e verso gli endpoint. Ogni interfaccia di endpoint dispone di un numero massimo di connessioni che possono essere monitorate e un volume elevato di query DNS può superare le connessioni e causare limitazione e perdita di query. Il tracciamento delle connessioni AWSè il comportamento predefinito per il monitoraggio dello stato del traffico che scorre attraverso i gruppi di sicurezza (). SGs L'utilizzo del tracciamento delle connessioni SGs ridurrà la velocità effettiva del traffico, tuttavia è possibile implementare connessioni non tracciate per ridurre il sovraccarico e migliorare le prestazioni. [Per ulteriori informazioni, consulta Connessioni non tracciate.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections) Se il tracciamento delle connessioni viene applicato utilizzando regole restrittive dei gruppi di sicurezza o le query vengono instradate tramite Network Load Balancer (vedere [Connessioni tracciate automaticamente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), il numero massimo complessivo di query al secondo per indirizzo IP per un endpoint può essere pari a 1500. **Raccomandazioni sulle regole del Security Group in ingresso e in uscita per l'endpoint Resolver in entrata** **** | | | **Regole di ingresso** | | --- | | Tipo di protocollo | Numero della porta | IP di origine | | TCP | 53 | 0.0.0.0/0 | | UDP | 53 | 0.0.0.0/0 | | **Regole di uscita** | | --- | | Tipo di protocollo | Numero della porta | IP di destinazione | | TCP | Tutti | 0.0.0.0/0 | | UDP | Tutti | 0.0.0.0/0 | **Raccomandazioni sulle regole del gruppo di sicurezza in ingresso e in uscita per l'endpoint Resolver in uscita** **** | | | **Regole di ingresso** | | --- | | Tipo di protocollo | Numero della porta | IP di origine | | TCP | Tutti | 0.0.0.0/0 | | UDP | Tutti | 0.0.0.0/0 | | **Regole di uscita** | | --- | | Tipo di protocollo | Numero della porta | IP di destinazione | | TCP | 53 | 0.0.0.0/0 | | UDP | 53 | 0.0.0.0/0 | **Nota** **Requisiti delle porte del gruppo di sicurezza:** **Gli endpoint in entrata** richiedono regole di ingresso che consentano a TCP e UDP sulla porta 53 di ricevere query DNS dalla rete. Le regole di uscita possono consentire tutte le porte poiché l'endpoint potrebbe dover rispondere alle query provenienti da varie porte di origine. Gli **endpoint in uscita** richiedono regole di uscita che consentano l'accesso TCP e UDP alle porte utilizzate per le query DNS sulla rete. La porta 53 è mostrata nell'esempio precedente perché è la porta DNS più comune, ma la rete potrebbe utilizzare porte diverse. Le regole di ingresso possono consentire a tutte le porte di accogliere le risposte dei server DNS. **Endpoint di Resolver in entrata** Per i client che utilizzano un endpoint di Resolver in ingresso, la capacità dell'interfaccia di rete elastica sarà influenzata se si dispone di oltre 40.000 combinazioni di indirizzi IP e porte univoche che generano il traffico DNS. # Alta disponibilità di endpoint di Resolver Quando crei gli endpoint in entrata VPC Resolver, Route 53 richiede la creazione di almeno due indirizzi IP a cui i resolver DNS della tua rete inoltreranno le query. Devi inoltre specificare gli indirizzi IP in almeno due zone di disponibilità per assicurare la ridondanza. Se necessiti che siano sempre disponibili più endpoint dell'interfaccia di rete elastica, ti suggeriamo di creare almeno un'interfaccia di rete in più del necessario, così da disporre di capacità aggiuntiva per gestire eventuali picchi di traffico. L'interfaccia di rete aggiuntiva garantisce inoltre la disponibilità durante le operazioni di servizio, come la manutenzione o gli aggiornamenti. Per ulteriori informazioni, consulta questo articolo dettagliato del blog: [Come](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) ottenere un'elevata disponibilità DNS con gli endpoint Resolver e. [Valori specificati durante la creazione o la modifica di endpoint in entrata](resolver-forwarding-inbound-queries-values.md) # Zona DNS Un attacco di zona DNS prova a ottenere tutto il contenuto dalle zone DNS firmate da DNSSEC. Se il team di VPC Resolver rileva uno schema di traffico che corrisponde a quello generato quando si visitano zone DNS sul tuo endpoint, il team di assistenza limiterà il traffico sull'endpoint. Di conseguenza, potresti osservare un'alta percentuale di query DNS che scadono. Se osservi una capacità ridotta sui tuoi endpoint e ritieni che l'endpoint sia stato limitato erroneamente, vai su home\$1/ per creare una richiesta di assistenza. https://console.aws.amazon.com/support/ # Best practice per i controlli dell'integrità di Amazon Route 53 Una configurazione efficace per il controllo dello stato di salute è essenziale per mantenere un'infrastruttura ad alta disponibilità e resilienza. Ecco alcune best practice da prendere in considerazione durante la configurazione e la gestione dei controlli sanitari di Amazon Route 53: 1. **Utilizza indirizzi IP elastici per gli endpoint di controllo dello stato:** + Utilizza indirizzi IP elastici per i tuoi endpoint di controllo sanitario per garantire un monitoraggio coerente. + Se non utilizzi più un'istanza Amazon EC2, ricordati di eliminare tutti i controlli di integrità associati per evitare potenziali rischi per la sicurezza o compromissione dei dati. Per ulteriori informazioni, consulta[Valori che specifichi durante la creazione o l'aggiornamento dei controlli dell'integrità](health-checks-creating-values.md). 1. **Configura gli intervalli appropriati per i controlli sanitari:** + Imposta gli intervalli di controllo dello stato in base ai requisiti dell'applicazione e alla criticità delle risorse monitorate. + Intervalli più brevi garantiscono un rilevamento più rapido dei guasti, ma possono aumentare i costi della Route 53 e il carico di risorse. + Intervalli più lunghi riducono i costi e il carico di risorse, ma possono ritardare il rilevamento dei guasti. Per ulteriori informazioni, vedere[Configurazione avanzata (solo "Monitor an endpoint" (Monitora un endpoint))](health-checks-creating-values.md#health-checks-creating-values-advanced). 1. **Implementa le notifiche di allarme:** + Configura Amazon CloudWatchalarms per ricevere notifiche quando i controlli sanitari falliscono o si ripristinano. + Imposta le soglie di allarme appropriate in base ai requisiti dell'applicazione e al comportamento previsto delle risorse. + Integra le notifiche con i tuoi processi di monitoraggio e risposta agli incidenti. Per ulteriori informazioni, consulta[Monitoraggio dei controlli sanitari tramite CloudWatch](monitoring-health-checks.md). 1. **Utilizza strategicamente le regioni per il controllo dello stato di salute:** + Scegli le regioni per il controllo dello stato di salute in base alla distribuzione geografica degli utenti e delle risorse. + Valuta la possibilità di utilizzare più aree di controllo dello stato di salute per le risorse essenziali, al fine di migliorare l'affidabilità e ridurre l'impatto delle interruzioni regionali. 1. **Monitora i registri e le metriche dei controlli sanitari:** + Esamina regolarmente i registri e le CloudWatch metriche dei controlli dello stato di Route 53 per identificare potenziali problemi o rallentamenti delle prestazioni + Analizza i motivi del fallimento dei controlli sanitari e intraprendi le azioni appropriate per risolvere i problemi sottostanti. 1. **Implementa strategie di failover e failback:** + Sfrutta le policy di routing di failover di Route 53 per indirizzare automaticamente il traffico verso risorse integre in caso di guasti. + Pianifica e testa i processi di failover e failback per garantire una transizione senza interruzioni durante le interruzioni e il ripristino. Per ulteriori informazioni, vedere. [Configurazione di un failover DNS](dns-failover-configuring.md) 1. **Rivedi e aggiorna regolarmente gli Health Checks:** + Aggiorna gli endpoint, gli intervalli e le soglie di allarme dei controlli di integrità secondo necessità per mantenere il monitoraggio e le prestazioni ottimali. Seguendo queste best practice, puoi sfruttare efficacemente i controlli dello stato di Amazon Route 53 per monitorare lo stato e la disponibilità delle nostre risorse, garantendo un'infrastruttura affidabile e ad alte prestazioni per le tue applicazioni e i tuoi servizi.