De ce o zonă privată Route 53 returnează NXDOMAIN pentru nume publice

Zonele private Route 53 înlocuiesc răspunsul pentru un nume în loc să îl unească cu înregistrarea publică, iar asta surprinde oamenii în cel mai prost moment. Adăugați o înregistrare internă pentru api.example.net într-o zonă privată pentru example.net, asociați-o cu un VPC, iar orice alt nume de sub acel părinte primește acum răspuns doar din zona privată. Un client care ieri putea ajunge la www.example.net primește astăzi un răspuns negativ. Turul de mai jos pornește de la acea interogare eșuată și merge spre exterior până la zona care i-a răspuns.

Începeți cu interogarea, nu cu consola

Reproduceți defecțiunea pe clientul care a raportat-o și notați numele exact și tipul înregistrării. Un nume care eșuează pentru A se poate totuși rezolva pentru AAAA, iar un browser care reîncearcă un nume din cache ascunde care dintre cele două s-a stricat. Rulați interogarea de două ori: o dată prin resolverul pe care clientul îl folosește cu adevărat și o dată cu o urmărire care îl ocolește.

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

A doua comandă este cea importantă. Linia sa de stare și secțiunea de autoritate numesc zona care a produs răspunsul, astfel încât puteți distinge un răspuns negativ din zona privată de un timeout, un port blocat sau un resolver care nu a primit niciodată interogarea. resolvectl arată care server superior a fost întrebat, iar acesta nu este adesea resolverul despre care ați presupus că l-a trimis VPN-ul.

Dacă interogarea urmărită returnează adresa publică, iar cea normală nu, înregistrarea publică este intactă și răspunde vizualizarea privată. Acea singură comparație decide care jumătate a restului acestei pagini vi se aplică.

Citiți ce zonă a răspuns

Un răspuns care poartă NXDOMAIN cu SOA-ul zonei private în secțiunea de autoritate este un răspuns definitiv din acea zonă, nu o căutare eșuată. Route 53 Resolver a ales zona găzduită privată pentru că numele se potrivea, apoi nu a găsit nicio înregistrare de tipul cerut, iar comportamentul documentat este să returneze răspunsul negativ în loc să trimită întrebarea către DNS-ul public.

Selecția urmează specificitatea. Cu mai multe spații de nume private suprapuse, câștigă zona potrivită cea mai specifică, iar un părinte privat mai larg nu primește o a doua șansă pentru un nume pe care zona copil selectată nu îl are. Regulile de redirecționare adaugă un alt strat, deoarece o regulă Resolver specifică unui domeniu poate învinge asocierea zonei găzduite private. Enumerați asocierile și regulile înainte de a concluziona că o zonă este goală.

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]"

Ambele comenzi au nevoie de acreditări pentru contul care deține zona, iar a doua are nevoie de ID-ul zonei din prima. Înlocuiți-l cu al dumneavoastră; substituentul de mai sus nu este real în mod intenționat.

De ce câștigă zona privată

Asocierea este cea care face zona vizibilă pentru un VPC, iar resolverul din acel VPC o aplică. O zonă privată care nu este asociată cu VPC-ul din care vine traficul clientului nu are niciun efect, în timp ce o asociere cu VPC-ul greșit produce un răspuns privat pentru populația greșită. Verificați lista de asocieri înainte de a edita înregistrări, pentru că o zonă poate fi corectă și totuși invizibilă.

Spațiile de nume suprapuse sunt a doua sursă de confuzie. O zonă privată pentru example.net și o zonă privată pentru api.example.net se potrivesc amândouă cu o interogare API, iar cea mai specifică răspunde. Acest lucru este util când doriți un spațiu de nume intern îngust și periculos când zonei înguste îi lipsește o înregistrare pe care o are cea mai largă. Considerațiile privind zonele găzduite private din documentația Route 53 descriu atât comportamentul de cădere, cât și precedența regulilor, și merită citite înainte de a adăuga o a doua zonă suprapusă.

Nimic din toate acestea nu schimbă zona publică. Resolvere publice răspund în continuare corect înregistrărilor publice, și de aceea defecțiunea pare o problemă a clientului pentru toți cei din afara VPC-ului.

Alegeți spațiul de nume înainte de a adăuga înregistrări

Dacă doar o nouă familie de servicii interne are nevoie de nume private, dați-i un subdomeniu privat dedicat și lăsați părintele public în pace. Un nume precum internal.example.net nu poate umbri www.example.net, iar raza de impact a unei înregistrări lipsă este limitată la numele pe care le-ați inventat în acest scop. Costul este că URL-urile și certificatele existente pot să nu corespundă noului nume.

Când utilizatorii publici și privați trebuie să păstreze același nume de gazdă, DNS cu vizualizare divizată este proiectul acceptat și necesită să întrețineți înregistrările în fiecare vizualizare în mod explicit. O zonă privată largă cu o singură înregistrare nu păstrează dependențele publice de sub acea zonă; le înlocuiește cu o zonă care are o înregistrare.

Inventariați numele pe care o aplicație le apelează efectiv înainte de a direcționa o populație de clienți către vizualizarea privată. Gazdele de autentificare, gazdele de resurse statice, țintele de redirecționare și punctele finale API sunt primele care se strică și sunt de obicei împrăștiate prin înregistrările mai multor echipe.

Urmați calea resolverului, apoi ruta

Un laptop vede vizualizarea privată doar dacă interogările sale ajung la resolverul care are asocierea. Editarea unui fișier hosts pe serverul VPN nu publică nimic către clienții conectați, iar un client configurat cu un resolver public va primi în continuare răspunsuri publice cât timp tunelul este activ. Confirmați adresa resolverului primită de client, apoi repetați interogarea de pe client, nu de pe server.

Odată ce numele se rezolvă, testați calea către adresa returnată ca pas separat, de exemplu cu ip route get față de adresa pe care a returnat-o interogarea. Un răspuns privat corect fără rută către adresă este o problemă de rutare, iar un răspuns despre o înregistrare lipsă este o problemă de vizualizare DNS; tratarea lor ca o singură problemă produce corecturi care nu rezistă. Lăsați verificările numelui de gazdă TLS și ale certificatului serviciului neschimbate, pentru că o adresă privată schimbă unde merge conexiunea și nimic despre ce certificat este valid.

Încheiați notând în nota de modificare zona, asocierea, resolverul și numele pe care le-ați verificat. Astfel, următoarea persoană care adaugă o înregistrare va ști ce spațiu de nume este autoritar pentru acea populație de clienți.