Perché una zona privata di Route 53 restituisce NXDOMAIN per nomi pubblici

Le zone private di Route 53 sostituiscono la risposta di un nome invece di fondersi con il record pubblico, e questo sorprende le persone nel momento peggiore. Aggiungete un record interno per api.example.net in una zona privata per example.net, associatela a una VPC e tutti gli altri nomi sotto quel padre ora rispondono solo dalla zona privata. Un client che ieri poteva raggiungere www.example.net oggi riceve una risposta negativa. Il percorso seguente parte da quella query fallita e va verso l’esterno fino alla zona che l’ha risposta.

Partite dalla query, non dalla console

Riproducete il guasto sul client che l’ha segnalato e annotate il nome esatto e il tipo di record. Un nome che fallisce per A può ancora risolversi per AAAA, e un browser che ritenta un nome in cache nasconde quale dei due si è rotto. Eseguite la query due volte: una attraverso il resolver che il client usa davvero e una con una traccia che lo aggira.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Il secondo comando è quello importante. La sua riga di stato e la sezione autoritativa nominano la zona che ha prodotto la risposta, così potete distinguere una risposta negativa della zona privata da un timeout, da una porta bloccata o da un resolver che non ha mai ricevuto la query. resolvectl mostra quale server superiore è stato interrogato, e spesso non è il resolver che avete supposto inviato dalla VPN.

Se la query tracciata restituisce l’indirizzo pubblico e quella normale no, il record pubblico è intatto e risponde la vista privata. Quella singola comparazione decide quale metà del resto di questa pagina vi riguarda.

Leggete quale zona ha risposto

Una risposta che porta NXDOMAIN con il SOA della zona privata nella sezione autoritativa è una risposta definitiva di quella zona, non un errore di ricerca. Route 53 Resolver ha scelto la zona ospitata privata perché il nome corrispondeva, poi non ha trovato alcun record del tipo richiesto, e il comportamento documentato è restituire la risposta negativa invece di inoltrare la domanda al DNS pubblico.

La selezione segue la specificità. Con più spazi di nomi privati sovrapposti vince la zona corrispondente più specifica, e un padre privato più ampio non ha una seconda occasione per un nome che la zona figlia scelta non ha. Le regole di inoltro aggiungono un altro livello, perché una regola del resolver specifica per dominio può vincere l’associazione della zona ospitata privata. Elencate le associazioni e le regole prima di concludere che una zona è vuota.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Entrambi i comandi richiedono credenziali per l’account che possiede la zona, e il secondo richiede l’ID della zona dal primo. Sostituitelo con il vostro; il segnaposto qui sopra non è reale di proposito.

Perché vince la zona privata

È l’associazione che rende la zona visibile a una VPC, e il resolver in quella VPC è ciò che la applica. Una zona privata non associata alla VPC da cui arriva il traffico del client non ha alcun effetto, mentre un’associazione alla VPC sbagliata produce una risposta privata per la popolazione sbagliata. Controllate l’elenco delle associazioni prima di modificare i record, perché una zona può essere corretta e comunque invisibile.

Gli spazi di nomi sovrapposti sono la seconda fonte di confusione. Una zona privata per example.net e una zona privata per api.example.net corrispondono entrambe a una query API, e risponde la più specifica. È utile quando volete uno spazio di nomi interno stretto, e pericoloso quando alla zona stretta manca un record che la più ampia ha. Le considerazioni sulle zone ospitate private nella documentazione di Route 53 descrivono sia il comportamento di caduta sia la precedenza delle regole, e vale la pena leggerle prima di aggiungere una seconda zona sovrapposta.

Niente di tutto questo cambia la zona pubblica. I resolver pubblici continuano a rispondere correttamente ai record pubblici, ed è per questo che il guasto sembra un problema del client a chiunque sia fuori dalla VPC.

Scegliete lo spazio di nomi prima di aggiungere record

Se solo una nuova famiglia di servizi interni ha bisogno di nomi privati, datele un sottodominio privato dedicato e lasciate in pace il padre pubblico. Un nome come internal.example.net non può oscurare www.example.net, e il raggio d’impatto di un record mancante si limita ai nomi che avete inventato per lo scopo. Il costo è che URL e certificati esistenti potrebbero non corrispondere al nuovo nome.

Quando utenti pubblici e privati devono mantenere lo stesso nome host, il DNS a vista divisa è la progettazione supportata e richiede che manteniate i record in ogni vista in modo esplicito. Una zona privata ampia con un solo record non conserva le dipendenze pubbliche sotto quella zona; le sostituisce con una zona che ha un record.

Inventariate i nomi che un’applicazione chiama davvero prima di indirizzare una popolazione di client verso la vista privata. Gli host di accesso, gli host delle risorse statiche, le destinazioni di reindirizzamento e gli endpoint API sono i primi a rompersi, e di solito sono sparsi tra i record di più team.

Seguite il percorso del resolver, poi la rotta

Un portatile vede la vista privata solo se le sue query raggiungono il resolver che ha l’associazione. Modificare un file hosts sul server VPN non pubblica nulla ai client connessi, e un client configurato con un resolver pubblico continuerà a ricevere risposte pubbliche finché il tunnel è attivo. Confermate l’indirizzo del resolver ricevuto dal client, poi ripetete la query dal client invece che dal server.

Una volta che il nome si risolve, provate la rotta verso l’indirizzo restituito come passaggio separato, per esempio con ip route get contro l’indirizzo restituito dalla query. Una risposta privata corretta senza rotta verso l’indirizzo è un problema di routing, e una risposta di record mancante è un problema di vista DNS; trattarli come un solo problema produce correzioni che non tengono. Lasciate invariate le verifiche del nome host TLS e del certificato del servizio, perché un indirizzo privato cambia dove va la connessione e nulla su quale certificato sia valido.

Concludete annotando nella nota di modifica la zona, l’associazione, il resolver e i nomi che avete verificato. Così la prossima persona che aggiunge un record saprà quale spazio di nomi è autoritativo per quella popolazione di client.