Zašto privatna Route 53 zona vraća NXDOMAIN za javna imena

Privatne Route 53 zone zamjenjuju odgovor za ime umjesto da se spajaju s javnim zapisom, i to iznenadi ljude u najgorem trenutku. Dodajte jedan interni zapis za api.example.net u privatnoj zoni za example.net, povežite je s VPC-om, i svako drugo ime pod tim roditeljem sada odgovara samo iz privatne zone. Klijent koji je jučer mogao doći do www.example.net danas dobija negativan odgovor. Pregled ispod počinje od tog neuspjelog upita i ide prema van do zone koja je na njega odgovorila.

Počnite od upita, a ne od konzole

Reproducirajte kvar na klijentu koji ga je prijavio i zapišite tačno ime i tip zapisa. Ime koje ne radi za A možda se ipak razrješava za AAAA, a preglednik koji ponovo pita keširano ime skriva koje je od njih pokvareno. Pokrenite upit dvaput: jednom kroz resolver koji klijent stvarno koristi i jednom s praćenjem koje ga zaobilazi.

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

Druga naredba je važna. Njen redak stanja i odjeljak autoriteta navode zonu koja je proizvela odgovor, pa možete razlikovati negativan odgovor iz privatne zone od isteka vremena, blokiranog porta ili resolvera koji upit nikada nije primio. resolvectl pokazuje koji je gornji server pitan, a to često nije resolver za koji ste pretpostavili da ga je VPN poslao.

Ako praćeni upit vraća javnu adresu, a normalni upit ne, javni zapis je netaknut i odgovara privatni pregled. To jedno poređenje odlučuje koja se polovina ostatka ove stranice na vas odnosi.

Pročitajte koja je zona odgovorila

Odgovor koji nosi NXDOMAIN sa SOA-om privatne zone u odjeljku autoriteta definitivan je odgovor te zone, a ne neuspjelo traženje. Route 53 Resolver odabrao je privatnu hostovanu zonu jer se ime poklopilo, zatim nije našao zapis traženog tipa, a dokumentovano ponašanje je da vrati negativan odgovor umjesto da pitanje proslijedi javnom DNS-u.

Odabir slijedi specifičnost. Kada se preklapa nekoliko privatnih imenskih prostora, pobjeđuje najspecifičnija zona koja se poklapa, a širi privatni roditelj ne dobija drugu šansu za ime koje odabrana podzona nema. Pravila prosljeđivanja dodaju još jedan sloj, jer pravilo resolvera za određenu domenu može pobijediti povezanost s privatnom hostovanom zonom. Nabrojite povezanosti i pravila prije nego zaključite da je zona prazna.

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

Obje naredbe traže akreditive za račun koji posjeduje zonu, a drugoj treba ID zone iz prve. Zamijenite ga svojim ID-om; rezervisano mjesto iznad namjerno nije stvarno.

Zašto privatna zona pobjeđuje

Povezanost je ono što zonu čini vidljivom VPC-u, a resolver u tom VPC-u je primjenjuje. Privatna zona koja nije povezana s VPC-om iz kojeg dolazi promet klijenta nema nikakav učinak, dok povezanost s pogrešnim VPC-om daje privatan odgovor pogrešnoj populaciji. Provjerite listu povezanosti prije uređivanja zapisa, jer zona može biti ispravna i ipak nevidljiva.

Preklapanje imenskih prostora drugi je izvor zabune. Privatna zona za example.net i privatna zona za api.example.net obje odgovaraju upitu za API, a odgovara specifičnija. To je korisno kada želite uzak interni imenski prostor, a opasno kada uskoj zoni nedostaje zapis koji šira ima. Razmatranja privatnih hostovanih zona u dokumentaciji Route 53 opisuju i ponašanje pri prelasku na širu zonu i prioritet pravila, i vrijedi ih pročitati prije nego dodate drugu zonu koja se preklapa.

Ništa od ovoga ne mijenja javnu zonu. Javni resolveri i dalje ispravno odgovaraju na javne zapise, i zato svima izvan VPC-a kvar izgleda kao problem klijenta.

Odaberite imenski prostor prije nego dodate zapise

Ako samo nova porodica internih servisa treba privatna imena, dajte joj namjensku privatnu poddomenu i ostavite javnog roditelja na miru. Ime poput internal.example.net ne može zasjeniti www.example.net, a radijus štete od zapisa koji nedostaje ograničen je na imena koja ste izmislili za tu svrhu. Cijena je da se postojeći URL-ovi i certifikati možda neće poklopiti s novim imenom.

Kada javni i privatni korisnici moraju zadržati isto ime hosta, DNS s podijeljenim pregledom podržani je dizajn i traži da zapise u svakom pregledu održavate izričito. Široka privatna zona s jednim zapisom u sebi ne čuva javne zavisnosti ispod te zone; ona ih zamjenjuje zonom koja ima jedan zapis.

Popišite imena koja aplikacija stvarno poziva prije nego populaciju klijenata usmjerite na privatni pregled. Hostovi za prijavu, hostovi statičkih resursa, odredišta preusmjerenja i API krajnje točke prvi se lome i obično su razasuti po zapisima nekoliko timova.

Pratite put resolvera, zatim rutu

Prijenosnik vidi privatni pregled samo ako njegovi upiti stignu do resolvera koji ima povezanost. Uređivanje datoteke hosts na VPN serveru ništa ne objavljuje povezanim klijentima, a klijent podešen s javnim resolverom nastavit će dobijati javne odgovore dok je tunel podignut. Potvrdite adresu resolvera koju je klijent dobio, pa ponovite upit s klijenta, a ne sa servera.

Kada se ime razriješi, provjerite put do vraćene adrese kao zaseban korak, na primjer s ip route get prema adresi koju je upit vratio. Ispravan privatan odgovor bez rute do adrese je problem usmjeravanja, a odgovor o zapisu koji nedostaje problem je DNS pregleda; ako ih tretirate kao jedan problem, popravke se ne zadržavaju. Ostavite provjere TLS imena hosta i certifikata nepromijenjenima, jer privatna adresa mijenja kamo ide veza, a ništa o tome koji je certifikat valjan.

Završite tako što ćete u bilješku o promjeni zapisati zonu, povezanost, resolver i imena koja ste provjerili. Sljedeća osoba koja doda zapis tada će znati koji je imenski prostor mjerodavan za tu populaciju klijenata.