Come posso risolvere i problemi di instradamento basati sulla geolocalizzazione di Route 53?
Le mie query DNS restituiscono un indirizzo IP di un server Web in una regione AWS diversa. Ad esempio, un utente negli Stati Uniti viene indirizzato a un indirizzo IP di un server Web situato in Europa.
Risoluzione
I problemi di instradamento basati sulla geolocalizzazione di Route 53 sono causati dai seguenti problemi:
- Manca una posizione predefinita nella configurazione dell’instradamento basato sulla geolocalizzazione.
- Il resolver DNS non supporta l'estensione edns0-client-subnet di EDNS0. Ciò porta a una determinazione imprecisa della posizione.
- I resolver DNS sono geograficamente diversi.
- Sono state apportate modifiche al DNS per i record di risorse che non si sono propagati a livello globale.
Per risolvere questi problemi, procedi come segue:
- Verifica che i record di risorse per la tua zona ospitata di Route 53 siano configurati correttamente per il tuo caso d'uso. Inoltre, verifica che sia presente un set di record di risorse predefinito. Dalla consoleRoute 53, controlla la posizione predefinita specificata nella configurazione della zona ospitata di Route 53.
**Esempio:**Considera il seguente esempio di output:
>> dig images.example.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> images.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51385 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION ;images.example.com. IN A ;; AUTHORITY SECTION: images.example.com. 60 IN SOA ns-1875.awsdns-42.co.uk.awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 65 msec ;; SERVER: 172.31.0.2#53(172.31.0.2) ;; WHEN: Tue Feb 7 22:02:30 2017 ;; MSG SIZE rcvd: 124
Nell'esempio precedente, non esiste una posizione predefinita specificata nella configurazione dell’instradamento basato sulla geolocalizzazione. Quindi, per una geolocalizzazione non corrispondente, la risposta DNS restituisce NOERROR per il campo rcode e non ci sono risultati nella sezione ANSWER. Per risolvere questo problema, aggiungi una posizione predefinita nella configurazione dell’instradamento basato sulla geolocalizzazione.
- Per verificare l'intervallo di indirizzi IP del resolver DNS, esegui i seguenti comandi, quindi annota l'output.
Su Linux o macOS, usa dig:
for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;
Su Windows, usa nslookup:
for /l %i in (1,1,10) do (nslookup resolver-identity.cloudfront.net && timeout /t 11 /nobreak)
- Controlla se il resolver DNS supporta edns0-Client-Subnet utilizzando uno dei seguenti comandi e annota l'output.
Su Linux o macOS, usa dig:
dig +nocl TXT o-o.myaddr.l.google.com
Su Windows, usa nslookup:
nslookup -type=txt o-o.myaddr.l.google.com
Esamina il primo record TXT restituito nella sezione Risposta dell'output. Il primo valore del record TXT è l'indirizzo IP del resolver DNS. 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 fornisce un indirizzo IP troncato della sottorete del client (/24 o /32) al server dei nomi autoritativo di Route 53. Per ulteriori informazioni, consulta Come posso determinare se il mio resolver DNS pubblico supporta l'estensione EDNS Client Subnet (ECS)?
- Utilizza il set di record di prova di Route 53 dallo strumento di controllo per determinare i record di risorse restituiti per una richiesta specifica. Per ulteriori informazioni, consulta Utilizzo dello strumento di controllo per vedere come Amazon Route 53 risponde alle query DNS.
Se il resolver DNS non supporta edns0-client-subnet, specifica l'indirizzo IP del resolver DNS come valore nello strumento.
Se il resolver DNS supporta edns0-client-subnet, specifica l'indirizzo IP di EDNS0 client subnet come valore nello strumento. Scegli Altre opzioni, quindi specifica lasubnet mask. Non specificare un indirizzo IP del Resolver.
- (Facoltativo) Se non hai accesso allo strumento di controllo, usa dig per interrogare i server dei nomi autoritativi di Route 53 per la tua zona ospitata con EDNS0-Client-Subnet. Utilizza l'output per determinare la risposta autorevole del record di geolocalizzazione per il tuo indirizzo IP di origine:
dig geo.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short
- I server dei nomi di Route 53 supportano l'estensione ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html)edns0-client-subnet[ di EDNS0. Il resolver o il server DNS locale aggiunge edns0-client-subnet alla query DNS per effettuare una ricerca DNS basata sulla sottorete IP di origine del client. Se questi dati non vengono trasmessi con la richiesta, Route 53 utilizza l'indirizzo IP di origine del resolver DNS per approssimare la posizione del client. Quindi, Route 53 risponde alle richieste di geolocalizzazione con il record DNS per la posizione del resolver. I dati EDNS0 devono essere passati a Route 53 e il client deve utilizzare un server dei nomi ricorsivo geograficamente più vicino. In caso contrario, il risultato è una posizione non ottimale che fornisce il record di risorse errato alla query DNS.
Per correggere questa configurazione, modifica il server DNS ricorsivo che supporta edns0-client-subnet. Esegui la risoluzione DNS, quindi condividi l'output. Se il server DNS ricorsivo non supporta la subnet edns0-client-subnet, prova a utilizzarne uno che lo faccia. Le opzioni che supportano edns0-client-subnet includono i resolver Google DNS e OpenDNS.
-
Controlla la posizione geografica dell'indirizzo IP della sottorete del client utilizzando il database GeoIP di MaxMind sul sito Web MaxMind o il tuo database GeoIP preferito. Verifica che il resolver DNS sia geograficamente vicino all'indirizzo IP pubblico del client. Se la risposta o il paese sul sito Web MaxMind non corrispondono alla risposta fornita da Route 53, i dati geografici di produzione di Route 53 potrebbero essere obsoleti. Se il routing è obsoleto, contatta il supporto AWS.
-
Verifica eventuali problemi con la propagazione del DNS utilizzando uno strumento come CacheCheck sul sito OpenDNS.
-
(Facoltativo) Determina se i record di routing basati sull'area geografica sono associati a un controllo dell’integrità di Route 53. Inoltre, stabilisci se Evaluate target health (ETH) è attivato per i record di alias. Se entrambi sono veri, Route 53 restituisce l'endpoint integro che meglio corrisponde alla posizione di origine.
Verifica lo stato del controllo dell’integrità di Route 53 nella console Route 53. Se ETH è attivato, controlla lo stato di integrità 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 l’Application Load Balancer e il Network Load Balancer, ogni gruppo target con obiettivi deve contenere almeno un obiettivo integro per essere considerato integro. Un gruppo target senza obiettivi registrati è considerato non integro. Se un gruppo target contiene solo obiettivi non integri, il sistema di bilanciamento del carico viene considerato non integro.
**Esempio:**Sono disponibili record per il Texas negli Stati Uniti, per gli Stati Uniti, per il Nord America e per tutte le località (la posizione è predefinita). Inoltre, ci sono query che provengono dal Texas con un endpoint non integro. La Route 53 controlla gli Stati Uniti, il Nord America e poi tutte le località, in quest'ordine, fino a quando non viene trovato un record con un endpoint integro. Se il record statunitense è integro, Route 53 restituisce questo endpoint. Altrimenti, Route 53 restituisce un record predefinito. Se tutti i record applicabili non sono integri, Route 53 risponde alla query DNS utilizzando il valore del record per la regione geografica più piccola.
Nota: le modifiche ai record alias delle risorse di geolocalizzazione potrebbero richiedere fino a 60 secondi per propagarsi.
Informazioni correlate
Come posso risolvere i problemi relativi ai controlli dell’integrità di Route 53 non integri?
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata un anno fa