Miks privaatne Route 53 tsoon tagastab avalike nimede jaoks NXDOMAINi

Privaatsed Route 53 tsoonid asendavad nime vastuse, selle asemel et avaliku kirjega liituda, ja see üllatab inimesi kõige halvemal hetkel. Lisage üks sisemine kirje api.example.net jaoks privaatsesse tsooni example.net, siduge see VPC-ga ja kõik muud nimed selle ülemnime all vastatakse nüüd ainult privaatsest tsoonist. Klient, mis eile pääses aadressile www.example.net täna saab eitava vastuse. Alljärgnev ülevaade algab sellest ebaõnnestunud päringust ja liigub väljapoole tsooni, mis sellele vastas.

Alustage päringust, mitte konsoolist

Korrake tõrget kliendil, mis selle esitas, ja kirjutage üles täpne nimi ja kirje tüüp. Nimi, mis ei lahene A jaoks, võib siiski laheneda AAAA jaoks, ja vahemällu salvestatud nime uuesti prooviv brauser varjab, kumb neist katki on. Käivitage päring kaks korda: üks kord läbi resolveri, mida klient tegelikult kasutab, ja üks kord jälgimisega, mis sellest mööda läheb.

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

Teine käsk on tähtis. Selle olekurida ja autoriteedi sektsioon nimetavad tsooni, mis vastuse tekitas, nii et saate eristada privaatsest tsoonist tulnud eitavat vastust ajapiirangust, blokeeritud portist või resolverist, mis päringut kunagi ei saanud. resolvectl näitab, millist ülemist serverit küsiti, ja sageli ei ole see resolver, mille VPN saatis, nagu te eeldasite.

Kui jälgitud päring tagastab avaliku aadressi, tavaline aga mitte, on avalik kirje terve ja vastab privaatne vaade. See üks võrdlus otsustab, milline pool ülejäänud leheküljest teid puudutab.

Lugege, milline tsoon vastas

Vastus, mis kannab NXDOMAIN ja mille autoriteedi sektsioonis on privaatse tsooni SOA, on selle tsooni lõplik vastus, mitte ebaõnnestunud otsing. Route 53 Resolver valis privaatse hostitud tsooni, sest nimi klappis, ei leidnud seejärel nõutud tüüpi kirjet, ja dokumenteeritud käitumine on tagastada eitav vastus, selle asemel et suunata küsimus avalikku DNS-i.

Valik järgib spetsiifilisust. Mitme kattuva privaatse nimeruumi korral võidab kõige spetsiifilisem sobiv tsoon, ja laiem privaatne ülemnimi ei saa teist võimalust nime jaoks, mida valitud alamtaanil pole. Suunamisreeglid lisavad veel ühe kihi, sest domeenipõhine Resolveri reegel võib privaatse hostitud tsooni seostamise üle võita. Loetlege seosed ja reeglid enne, kui järeldate, et tsoon on tühi.

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

Mõlemad käsud vajavad selle konto mandaate, mis tsooni omab, ja teine vajab esimesest tsooni ID-d. Asendage see oma ID-ga; ülalolev kohatäide ei ole meelega päris.

Miks privaatne tsoon võidab

Seostamine on see, mis teeb tsooni VPC jaoks nähtavaks, ja selle VPC resolver rakendab seda. Privaatne tsoon, mis ei ole seotud selle VPC-ga, kust kliendi liiklus tuleb, ei oma üldse mõju, samas kui seostamine vale VPC-ga annab vale sihtrühma jaoks privaatse vastuse. Kontrollige seoste loendit enne kirjete muutmist, sest tsoon võib olla õige ja siiski nähtamatu.

Kattuvad nimeruumid on teine segaduse allikas. Privaatne tsoon domeeni example.net jaoks ja privaatne tsoon domeeni api.example.net jaoks sobivad mõlemad API päringuga, ja vastab spetsiifilisem. See on kasulik, kui soovite kitsast sisemist nimeruumi, ja ohtlik, kui kitsal tsoonil puudub kirje, mis laiemal on. Privaatsete hostitud tsoonide kaalutlused Route 53 dokumentatsioonis kirjeldavad nii läbikukkumise käitumist kui ka reeglite tähtsust, ja neid tasub lugeda enne teise kattuva tsooni lisamist.

Miski sellest ei muuda avalikku tsooni. Avalikud resolverid vastavad avalikele kirjetele endiselt õigesti, ja seetõttu tundub tõrge kõigile väljaspool VPC-d kliendi probleemina.

Valige nimeruum enne kirjete lisamist

Kui privaatseid nimesid vajab ainult uus sisemiste teenuste perekond, andke sellele eraldi privaatne alamdomeen ja jätke avalik ülemnimi puutumata. Nimi nagu internal.example.net ei saa varjutada nime www.example.net, ja puuduva kirje mõjuraadius piirdub nimedega, mille te selleks otstarbeks välja mõtlesite. Hind on see, et olemasolevad URL-id ja sertifikaadid ei pruugi uue nimega sobida.

Kui avalikud ja privaatsed kasutajad peavad säilitama sama hostinime, on jaotatud vaatega DNS toetatud lahendus ja see nõuab, et hoiaksite kirjeid igas vaates selgesõnaliselt. Lai privaatne tsoon ühe kirjega ei säilita selle tsooni all olevaid avalikke sõltuvusi; see asendab need tsooniga, milles on üks kirje.

Enne kui suunate kliendirühma privaatsesse vaatesse, loendage nimed, mida rakendus tegelikult kutsub. Sisselogimishostid, staatiliste ressursside hostid, ümbersuunamise sihid ja API otspunktid lähevad esimesena katki ja need on tavaliselt mitme meeskonna kirjete vahel laiali.

Jälgige resolveri teed, seejärel marsruuti

Sülearvuti näeb privaatset vaadet ainult siis, kui tema päringud jõuavad resolverini, millel on seostamine. Hosts-faili muutmine VPN serveris ei avalda ühendatud klientidele midagi ja avaliku resolveriga seadistatud klient saab jätkuvalt avalikke vastuseid seni, kuni tunnel on üleval. Kinnitage resolveri aadress, mille klient sai, ja korrake seejärel päringut kliendist, mitte serverist.

Kui nimi on lahendatud, testige teed tagastatud aadressini eraldi sammuna, näiteks käsuga ip route get päringu tagastatud aadressi vastu. Õige privaatne vastus ilma marsruudita aadressini on marsruutimise probleem ja puuduva kirje vastus on DNS-vaate probleem; nende käsitlemine ühe probleemina annab parandusi, mis ei püsi. Jätke teenuse TLS-i hostinime ja sertifikaadi kontrollid muutmata, sest privaatne aadress muudab seda, kuhu ühendus läheb, ja mitte midagi sellest, milline sertifikaat kehtib.

Lõpetage sellega, et kirjutate muudatuse märkmesse tsooni, seostamise, resolveri ja nimed, mida kontrollisite. Siis teab järgmine inimene, kes kirje lisab, milline nimeruum on selle kliendirühma jaoks autoriteetne.