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 del Route 53, inclusi i controlli dell'integrità, e il controllo del routing del Controller di ripristino delle applicazioni Amazon Route 53 sono globalmente distribuiti e progettati per garantire disponibilità e funzionalità al 100% anche durante 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 ripristino di emergenza, ti consigliamo di aggiornare il DNS mediante funzioni come i controlli dell'integrità di Route 53 e il controllo del routing di Route 53 ARC, che si basano sulla funzionalità del piano dati. Per ulteriori informazioni, consulta Nozioni sul piano di controllo e sul piano dati e Blog: 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 registro ha TTL più brevi, i resolver DNS notano più rapidamente gli aggiornamenti del registro, dato che eseguono le 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 i TTL dei registri DNS sul tempo massimo puoi attendere affinché 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 registri, suggeriamo TTL più lunghi. I valori comunemente usati sono compresi tra un'ora (3600 secondi) e un giorno (86.400 secondi).

• Per i registri da modificare come parte di un meccanismo di failover rapido (in particolare i registri controllati per l'integrità), è meglio impostare TTL inferiori. Per questo scenario, è comune impostare un TTL di 60 o 120 secondi.

• Quando desideri modificare le voci DNS critiche, ti suggeriamo di abbreviare temporaneamente i TTL. 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).

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 eseguire più query per rispondere ai CNAME, aumentando 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 Routing del traffico Internet alle risorse AWS.

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 di geoprossimità e Routing basato sulla latenza.

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'GetChangeAPI 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.

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 e Test server delle dimensioni della risposta del DNS.