Zakaj zasebna cona Route 53 vrne NXDOMAIN za javna imena

Zasebne cone Route 53 nadomestijo odgovor za ime, namesto da bi se združile z javnim zapisom, in to ljudi preseneti v najslabšem trenutku. Dodajte en notranji zapis za api.example.net v zasebni coni za example.net, povežite jo z VPC in vsako drugo ime pod tem nadrejenim zdaj odgovarja samo iz zasebne cone. Odjemalec, ki je včeraj lahko dosegel www.example.net danes prejme negativen odgovor. Spodnji pregled se začne pri tej neuspešni poizvedbi in gre navzven do cone, ki je nanjo odgovorila.

Začnite s poizvedbo, ne s konzolo

Ponovite napako na odjemalcu, ki jo je prijavil, in zapišite natančno ime ter vrsto zapisa. Ime, ki ne deluje za A se lahko še vedno razreši za AAAA, brskalnik, ki znova poskusi predpomnjeno ime, pa skrije, katero od obeh se je pokvarilo. Zaženite poizvedbo dvakrat: enkrat prek resolverja, ki ga odjemalec dejansko uporablja, in enkrat s sledenjem, ki ga obide.

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

Drugi ukaz je tisti pomembni. Njegova vrstica stanja in razdelek authority navajata cono, ki je ustvarila odgovor, zato lahko negativni odgovor iz zasebne cone ločite od časovne prekinitve, blokiranih vrat ali resolverja, ki poizvedbe ni nikoli prejel. resolvectl prikaže, kateri nadrejeni strežnik je bil vprašan, in to pogosto ni resolver, za katerega ste domnevali, da ga je poslal VPN.

Če sledena poizvedba vrne javni naslov, običajna pa ne, je javni zapis nedotaknjen in odgovarja zasebni pogled. Prav ta ena primerjava odloči, katera polovica preostanka te strani velja za vas.

Preberite, katera cona je odgovorila

Odgovor, ki nosi NXDOMAIN s SOA zasebne cone v razdelku authority, je dokončen odgovor te cone, ne neuspešno iskanje. Route 53 Resolver je izbral zasebno gostujočo cono, ker se je ime ujemalo, nato ni našel zapisa zahtevane vrste in dokumentirano vedenje je vrniti negativni odgovor, namesto da bi vprašanje posredoval javnemu DNS.

Izbira sledi specifičnosti. Pri več prekrivajočih se zasebnih imenskih prostorih zmaga najbolj specifična ujemajoča cona, širši zasebni nadrejeni element pa ne dobi druge priložnosti za ime, ki ga izbrana podrejena cona nima. Pravila posredovanja dodajo še eno plast, saj lahko pravilo resolverja za določeno domeno premaga povezavo zasebne gostujoče cone. Naštejte povezave in pravila, preden sklepate, da je cona 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]"

Oba ukaza potrebujeta poverilnice za račun, ki ima cono, drugi pa potrebuje ID cone iz prvega. Zamenjajte ga s svojim; nadomestni znak zgoraj namenoma ni resničen.

Zakaj zmaga zasebna cona

Povezava je tisto, kar naredi cono vidno za VPC, in resolver v tem VPC jo uporabi. Zasebna cona, ki ni povezana z VPC, od koder prihaja promet odjemalca, nima nobenega učinka, medtem ko povezava z napačnim VPC ustvari zasebni odgovor za napačno populacijo. Preverite seznam povezav, preden urejate zapise, ker je cona lahko pravilna in vendar nevidna.

Prekrivajoči se imenski prostori so drugi vir zmede. Zasebna cona za example.net in zasebna cona za api.example.net se obe ujemata s poizvedbo API in odgovori bolj specifična. To je koristno, ko želite ozek notranji imenski prostor, in nevarno, ko ozki coni manjka zapis, ki ga ima širša. Premisleki o zasebnih gostujočih conah so v dokumentaciji Route 53 opisujejo tako vedenje pri padcu kot prednost pravil, in vredno jih je prebrati, preden dodate drugo prekrivajočo se cono.

Nič od tega ne spremeni javne cone. Javni resolverji še vedno pravilno odgovarjajo na javne zapise, in zato se vsem zunaj VPC napaka zdi kot težava odjemalca.

Izberite imenski prostor, preden dodate zapise

Če zasebna imena potrebuje le nova družina notranjih storitev, ji dajte namensko zasebno poddomeno in pustite javnega nadrejenega pri miru. Ime, kot je internal.example.net ne more zasenčiti www.example.net, in doseg manjkajočega zapisa je omejen na imena, ki ste si jih izmislili za ta namen. Cena je, da se obstoječi URL-ji in potrdila morda ne bodo ujemali z novim imenom.

Ko morajo javni in zasebni uporabniki ohraniti isto ime gostitelja, je DNS z razdeljenim pogledom podprta zasnova in zahteva, da zapise v vsakem pogledu vzdržujete izrecno. Široka zasebna cona z enim zapisom ne ohrani javnih odvisnosti pod to cono; nadomesti jih s cono, ki ima en zapis.

Preden usmerite populacijo odjemalcev v zasebni pogled, popišite imena, ki jih aplikacija dejansko kliče. Gostitelji prijave, gostitelji statičnih virov, cilji preusmeritve in končne točke API se pokvarijo prvi in so običajno razpršeni po zapisih več ekip.

Sledite poti resolverja, nato poti

Prenosnik vidi zasebni pogled le, če njegove poizvedbe dosežejo resolver, ki ima povezavo. Urejanje datoteke hosts na strežniku VPN ne objavi ničesar povezanim odjemalcem, odjemalec, nastavljen z javnim resolverjem, pa bo še naprej prejemal javne odgovore, dokler je tunel vzpostavljen. Potrdite naslov resolverja, ki ga je prejel odjemalec, in nato poizvedbo ponovite z odjemalca, ne s strežnika.

Ko je ime razrešeno, preizkusite pot do vrnjenega naslova kot ločen korak, na primer z ip route get proti naslovu, ki ga je vrnila poizvedba. Pravilen zasebni odgovor brez poti do naslova je težava usmerjanja, odgovor o manjkajočem zapisu pa težava pogleda DNS; če ju obravnavate kot eno težavo, popravki ne zdržijo. Pustite preverjanja imena gostitelja TLS in potrdila storitve nespremenjena, ker zasebni naslov spremeni, kam gre povezava, in nič o tem, katero potrdilo je veljavno.

Končajte tako, da v opombo o spremembi zapišete cono, povezavo, resolver in imena, ki ste jih preverili. Nato bo naslednja oseba, ki doda zapis, vedela, kateri imenski prostor je merodajen za to populacijo odjemalcev.