Come posso risolvere i problemi relativi ai record di risorse basati sulla latenza e alla Route 53?

Breve descrizione

Route 53 si risolve nella regione con la latenza più bassa in base alla posizione della query DNS se si verifica quanto segue:

• Hai associato endpoint in più Regioni AWS allo stesso record di risorse.
• Stai utilizzando una politica di routing basata sulla latenza.

Route 53 prende decisioni di routing basato sulla latenza in base a:

• L'indirizzo IP di origine del resolver DNS ricorsivo che invia la query al nameserver autorevole Route 53.
• La versione troncata dell'indirizzo IP del client (se il resolver DNS supporta l'estensione edns00-client-subnet).

Per impostazione predefinita, i nameserver Route 53 supportano edns0-client-subnet. Se un resolver DNS ricorsivo supporta edns0-client-subnet, il resolver DNS invia a Route 53 una versione troncata dell'indirizzo IP del client. Route 53 utilizza quindi quell'indirizzo IP troncato per determinare la regione con la latenza più bassa.

La regione con la latenza più bassa potrebbe non essere fisicamente più vicina al resolver DNS. È possibile che si verifichi un comportamento di routing indesiderato se il client non si trova nella stessa posizione del resolver DNS. È inoltre possibile che si verifichi un comportamento di routing indesiderato se l'indirizzo IP del resolver contiene informazioni sulla posizione diverse.

Scenario di esempio

Un'azienda dispone di record di routing basati sulla latenza per due Elastic Load Balancer, uno in Virginia (us-east-1) e l'altro in Irlanda (eu-west-1). Gli utenti negli Stati Uniti utilizzano un resolver DNS aziendale situato in Europa o si connettono alla sede aziendale in Europa tramite una VPN.

Il resolver DNS aziendale non può inviare dati edns0-client-subnet ai nameserver autorevoli. Pertanto, Route 53 considera l'indirizzo IP del resolver DNS in Europa come origine della query. Route 53 esegue quindi una ricerca nel suo database di latenza e determina erroneamente che il sistema di bilanciamento del carico in Irlanda ha la latenza più bassa.

Se il resolver DNS aziendale è in grado di inviare dati edns0-client-subnet, Route 53 considera l'indirizzo IP del client troncato negli Stati Uniti come origine della query. Route 53 esegue quindi una ricerca nel proprio database di latenza e determina correttamente che il sistema di bilanciamento del carico in Virginia ha la latenza più bassa.

Risoluzione

Utilizza i seguenti passaggi per risolvere i problemi di routing basato sulla latenza indesiderati:

1. Controlla l'intervallo di indirizzi IP utilizzato dal resolver DNS. Su Linux e macOS, esegui il comando dig in un ciclo continuo. In Windows, esegui il comando nslookup più volte. Assicurati di annotare l'output ogni volta.

Su Linux o macOS, esegui il comando dig in un ciclo continuo.

for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

In Windows, esegui il comando nslookup più volte. Assicurati di annotare l'output ogni volta.

nslookup -type=txt o-o.myaddr.l.google.com

2. Verifica che il resolver DNS supporti Anycast utilizzando l'output del comando precedente. Se l'output contiene sempre lo stesso indirizzo IP singolo, il resolver DNS non supporta Anycast. Se l'indirizzo IP cambia quando esegui il comando più volte, il resolver DNS supporta Anycast.

Quando un resolver DNS supporta Anycast, esistono più posizioni edge per i resolver DNS. La posizione edge di un utente viene selezionata in base alla latenza ottimale, che potrebbe comportare una posizione imprevista per l'indirizzo IP del resolver.

3. Trova l'indirizzo IP del client. Dal computer client, apri un browser Internet e quindi accedi a https://checkip.amazonaws.com/.

Oppure usa curl:

curl https://checkip.amazonaws.com/

4. Controlla se il resolver DNS supporta edns0-client-subnet utilizzando uno dei seguenti comandi. Assicurati di annotare l'output.

Su Linux o macOS, usa dig:

dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

Su Windows, usa nslookup:

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5. Controlla il primo record TXT restituito nella sezione Answer (Risposta) dell'output. Questo valore è il server DNS più vicino che pubblicizza Anycast. Se non è presente un secondo record TXT, il resolver DNS non supporta edns0-client-subnet. Se è presente un secondo record TXT, il resolver DNS supporta edns0-client-subnet. Il resolver invia una sottorete client troncata (/24 o /32) al nameserver autorevole Route 53.

(Facoltativo) Se hai attivato la registrazione delle query DNS di Route 53 nella tua zona ospitata, crea un record di test. Esegui una ricerca DNS per il nuovo record. Controlla i log delle query per confermare l'indirizzo IP del resolver e la subnet edns0-client-subnet (se presente) presentati ai nameserver di Route 53.

6. Verifica che il valore TTL della risposta sia di 60 secondi. Se il TTL non è di 60 secondi, la risposta è una risposta memorizzata nella cache. Ripeti il comando dig o nslookup finché il valore TTL della risposta non è di 60 secondi.

7. Se riesci ad accedere allo strumento di controllo DNS di Route 53, simula le query da uno specifico resolver DNS o indirizzo IP del client. Usa queste query per scoprire quale set di record di risorse di latenza restituisce Route 53.

Se il resolver DNS non supporta edns0-client-subnet, specifica il Resolver IP address (Indirizzo IP del resolver) come valore nello strumento.

Se il resolver DNS supporta edns0-client-subnet, specifica l'IP della sottorete del client EDNS0 come valore nello strumento. Scegli Additional configuration (Configurazione aggiuntiva), quindi specifica la Subnet mask (Maschera di sottorete).

Nota: Lo strumento di controllo DNS di Route 53 interroga direttamente il database di misurazione della latenza di Route 53. La query determina la latenza precalcolata tra le regioni AWS e una rete basata su Internet. Lo strumento non invia query DNS su Internet o ai resolver DNS. Lo strumento non verifica se il resolver DNS supporta edns0-client-subnet. I risultati dello strumento e una query DNS effettiva potrebbero differire.

8. (Facoltativo) Se non riesci ad accedere allo strumento di controllo DNS di Route 53, usa dig. Usando dig, interroga i nameserver autorevoli di Route 53 per la tua zona ospitata con edns0-client-subnet. Usa l'output per determinare la regione con la latenza più bassa dal tuo indirizzo IP di origine.

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

Nota: La latenza tra gli host su Internet può cambiare nel tempo a causa di cambiamenti nella connettività di rete e nel routing. Ad esempio, una richiesta indirizzata alla regione dell'Oregon questa settimana potrebbe essere indirizzata alla regione dell'Ohio la settimana prossima.

9. Per i resolver che non supportano edns0-client-subnet: Cambia il resolver DNS del client con un altro resolver DNS ricorsivo situato geograficamente più vicino al client. Se il resolver non supporta edns0-client-subnet, le query DNS del client potrebbero utilizzare un resolver DNS in una posizione geografica diversa da quella del client. Il risultato in questo scenario è un comportamento di routing imprevisto.

Se gestisci il resolver DNS, controlla la configurazione di inoltro. Verifica che non stai inoltrando le query DNS a un altro resolver più lontano dalla posizione geografica del client.

Per i resolver che supportano edns0-client-subnet: Verifica la posizione geografica dell'indirizzo IP della sottorete del client. Per verificare la posizione, utilizza il database GeoIP sul sito Web MaxMind o il tuo database GeoIP preferito. Se la posizione dell'indirizzo IP della sottorete del client si trova in una posizione geografica diversa da quella del client, è possibile che si verifichi un comportamento di routing imprevisto.

10. (Facoltativo) Se il resolver DNS non supporta edns0-client-subnet, passa a un resolver DNS ricorsivo pubblico che supporti edns0-client-subnet. Quindi, confronta i vecchi risultati della risposta al routing a latenza di Route 53 con i nuovi risultati. Ad esempio, due resolver DNS pubblici che attualmente supportano edns0-client-subnet sono GoogleDNS (8.8.8.8 e 8.8.4.4) e OpenDNS (208.67.222.222 e 208.67.220.220).

11. (Facoltativo) Determina se i record di routing basati sulla latenza sono associati a un controllo dell’integrità di Route 53. Inoltre, determina se Evaluate Target Health (ETH) è attivato (per i record degli alias). Se uno o entrambi sono veri, Route 53 restituisce l'endpoint integro con la latenza più bassa. Se tutti i controlli dell’integrità falliscono, viene presa in considerazione solo la politica di routing.

Controlla lo stato del controllo dell’integrità di Route 53 nella console Route 53. Se ETH è attivato, controlla lo stato dell'endpoint del record. Route 53 considera integro un endpoint per un Classic Load Balancer con ETH attivato se almeno un'istanza di backend è integra. Per Application Load Balancer e Network Load Balancer, ogni gruppo di destinazione con obiettivi deve contenere almeno un obiettivo integro per essere considerato integro. Un gruppo di destinazione senza destinazioni registrate è considerato non integro. Se un gruppo di destinazione contiene solo destinazioni non integre, il sistema di bilanciamento del carico viene considerato non integro.

Eccezione: Se un Application Load Balancer ha almeno un gruppo di destinazione integro e tutti i gruppi di destinazione rimanenti sono vuoti, Route 53 lo considera integro.

Esempio

Hai due record di routing basati sulla latenza con i controlli dell’integrità di Route 53 associati, uno in Oregon e l'altro in North Virginia. Quando il controllo dell’integrità dell'endpoint dell’Oregon fallisce, tutte le richieste vengono indirizzate all'endpoint del North Virginia indipendentemente dalla posizione del client.

Informazioni correlate

Verifica delle risposte DNS da Route 53

Come posso determinare se il mio resolver DNS pubblico supporta l'estensione Sottorete client o EDNS client submet?

Come posso risolvere i problemi relativi ai controlli dell’integrità di Route 53 non integri?

Perché il mio record di alias rimanda a un Application Load Balancer contrassegnato come non integro quando utilizzo «Evaluate Target Health» (Valuta integrità di destinazione)?