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à.
Le migliori pratiche per Amazon Route 53 DNS
Segui queste best practice per ottenere i migliori risultati quando usi il DNS servizio Amazon Route 53.
- Utilizza le funzioni del piano dati per il DNS failover 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 ARC routing, che si basano sulla funzionalità del piano dati per l'aggiornamento. DNS 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 TTL valori per i record DNS
-
DNSTTLè il valore numerico (in secondi) utilizzato DNS dai resolver per decidere per quanto tempo un record può essere memorizzato nella cache senza effettuare un'altra interrogazione su Route 53. Tutti i DNS record devono avere un nome specifico. TTL L'intervallo consigliato per TTL i valori è compreso tra 60 e 172.800 secondi.
La scelta di a TTL è un compromesso tra latenza e affidabilità e reattività al cambiamento. Con un record più breveTTLs, i DNS resolver 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 si allunga il termineTTL, DNS i resolver rispondono più spesso alle query dalla cache, 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à.
Gli aspetti da considerare quando si impostano i valori includono: TTL
-
Imposta il DNS record 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, TTLs si consiglia un periodo più lungo. 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 inferioreTTLs. L'impostazione TTL di un valore di 60 o 120 secondi è una scelta comune in questo scenario.
-
Quando si desidera apportare modifiche alle DNS voci critiche, si consiglia di abbreviare temporaneamente leTTLs. Quindi puoi apportare le modifiche, osservare e ripristinare allo stato precedente se necessario. Dopo che le modifiche sono state finalizzate e hanno funzionato come previsto, è possibile aumentare il. TTL
Per ulteriori informazioni, consulta TTL (secondi).
-
- CNAMEregistri
-
DNSCNAMEi record sono un modo per indirizzare un nome di dominio a un altro. Se un DNS resolver risolve domain-1.example.com e trova un CNAME punto adomain-2.example.com, deve procedere alla risoluzione prima di poter rispondere. DNS 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 DNS resolver devono fare più domande a cui rispondere, il che aumenta la latenza e i costi. CNAMEs 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.
- DNSRouting 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.
- DNSpropagazione delle modifiche
-
Quando si crea o si aggiorna un record o una zona ospitata utilizzando la console Route 53 oppureAPI, è necessario del tempo prima che la modifica si rifletta 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 la GetChangeAPIper verificare che le DNS modifiche siano entrate in vigore ()
Status =INSYNC. - DNSdelegazione
-
Quando deleghi più livelli di sottodominiDNS, è importante delegare sempre dalla zona principale. 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.
- Dimensione della risposta DNS
Evita di creare singole risposte di grandi dimensioni. Se le risposte superano i 512 byte, molti DNS resolver devono riprovare TCP invece di farloUDP, il che può ridurre l'affidabilità e portare a risposte più lente. 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 Reply Size Test Server. DNS
