Private Route 53-soner erstattar svaret for eit namn i staden for å slå det saman med den offentlege posten, og det overraskar folk på det verste tidspunktet. Legg til ein intern post for api.example.net i ei privat sone for example.net, knyt henne til ein VPC, og alle andre namn under den forelderen blir no svara berre frå den private sona. Ein klient som i går kunne nå www.example.net får i dag eit negativt svar. Gjennomgangen nedanfor byrjar ved den mislukka spørjinga og arbeider utover til sona som svara på henne.

Byrja ved spørjinga, ikkje ved konsollen

Reproduser feilen på klienten som rapporterte han, og noter det nøyaktige namnet og posttypen. Eit namn som feilar for A kan framleis slåast opp for AAAA, og ein nettlesar som prøver eit bufra namn på nytt, gøymer kva av dei som er øydelagd. Køyr spørjinga to gonger: éin gong gjennom resolvaren klienten faktisk brukar, og éin gong med sporing som omgår han.

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

Den andre kommandoen er den viktige. Statuslinja og autoritetsdelen nemner sona som produserte svaret, slik at du kan skilje eit negativt svar frå den private sona frå ein tidsavbrot, ein blokkert port eller ein resolver som aldri fekk spørjinga. resolvectl viser kva oppstraums tenar som vart spurd, og det er ofte ikkje resolvaren du antok at VPN-en sende.

Viss den spora spørjinga returnerer den offentlege adressa medan den vanlege ikkje gjer det, er den offentlege posten intakt og den private visa svarar. Den eine samanlikninga avgjer kva halvdel av resten av denne sida som gjeld for deg.

Les kva sone som svara

Eit svar som ber NXDOMAIN med SOA-en til den private sona i autoritetsdelen, er eit endeleg svar frå den sona, ikkje eit mislukka oppslag. Route 53 Resolver valde den private vertssona fordi namnet samsvara, fann deretter ingen post av den førespurde typen, og den dokumenterte åtferda er å returnere det negative svaret i staden for å senda spørsmålet vidare til offentleg DNS.

Valet følgjer spesifisitet. Med fleire overlappande private namnerom vinn den mest spesifikke samsvarande sona, og ein breiare privat forelder får ikkje ein ny sjanse for eit namn som den valde undertsona ikkje har. Vidaresendingsreglar legg til eit ekstra lag, fordi ein domenespesifikk Resolver-regel kan slå knytinga til den private vertssona. List opp knytingane og reglane før du konkluderer med at ei sone er tom.

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

Båe kommandoane krev innloggingsopplysningar for kontoen som eig sona, og den andre treng sone-ID-en frå den fyrste. Byt han ut med din eigen; plasshaldaren ovanfor er med vilje ikkje ekte.

Kvifor den private sona vinn

Det er knytinga som gjer sona synleg for ein VPC, og resolvaren i den VPC-en er det som brukar henne. Ei privat sone som ikkje er knytt til VPC-en trafikken til klienten kjem frå, har ingen verknad i det heile, medan ei knyting til feil VPC gir eit privat svar til feil populasjon. Kontroller knytingslista før du redigerer postar, fordi ei sone kan vere rett og likevel usynleg.

Overlappande namnerom er den andre kjelda til forvirring. Ei privat sone for example.net og ei privat sone for api.example.net samsvarar båe med ei API-spørjing, og den mest spesifikke svarar. Det er nyttig når du vil ha eit smalt internt namnerom, og farleg når den smale sona manglar ein post som den breiare har. Vurderingane for private vertssoner i Route 53-dokumentasjonen skildrar både gjennomfallsåtferda og regelføretråd, og dei er verd å lese før du legg til ei andre overlappande sone.

Ingenting av dette endrar den offentlege sona. Offentlege resolverar svarar framleis rett på dei offentlege postane, og difor ser feilen ut som eit klientproblem for alle utanfor VPC-en.

Vel namnerommet før du legg til postar

Viss berre ein ny familie av interne tenester treng private namn, gi han eit eige privat underdomene og lat den offentlege forelderen vere. Eit namn som internal.example.net kan ikkje skyggje for www.example.net, og slagradiusen for ein manglande post er avgrensa til namna du fann opp for føremålet. Prisen er at eksisterande URL-ar og sertifikat kanskje ikkje samsvarar med det nye namnet.

Når offentlege og private brukarar må halde same vertsnamn, er DNS med delt vise det støtta designet, og det krev at du vedlikeheld postane i kvar vise eksplisitt. Ei brei privat sone med éin post i seg bevarar ikkje dei offentlege avhengnadene under sona; ho erstattar dei med ei sone som har éin post.

Kartlegg namna ein applikasjon faktisk kallar, før du peikar ein klientpopulasjon mot den private visa. Innloggingsvertar, vertar for statiske ressursar, omdirigeringsmål og API-endepunkt er dei som ryker fyrst, og dei er vanlegvis spreidde over postane til fleire team.

Følg resolvarstien, deretter ruta

Ein berbar PC ser berre den private visa viss spørjingane hans når resolvaren som har knytinga. Redigering av ei hosts-fil på VPN-tenaren publiserer ingenting til tilkopla klientar, og ein klient sett opp med ein offentleg resolver vil framleis få offentlege svar medan tunnelen er oppe. Stadfest resolveradressa klienten fekk, og gjer deretter spørjinga om att frå klienten i staden for frå tenaren.

Når namnet er slått opp, test ruta til den returnerte adressa som eit eige steg, til dømes med ip route get mot adressa spørjinga returnerte. Eit rett privat svar utan rute til adressa er eit ruteproblem, og eit svar om ein manglande post er eit DNS-viseproblem; å handsame dei som eitt problem gir rettingar som ikkje held. Lat TLS-vertsnamnet og sertifikatkontrollane til tenesta vere uendra, fordi ei privat adresse endrar kvar tilkoplinga går og ingenting om kva sertifikat som er gyldig.

Avslutt med å notere sona, knytinga, resolvaren og namna du stadfesta i endringsnotatet. Då veit neste person som legg til ein post kva namnerom som er autoritativt for den klientpopulasjonen.

Relaterte artiklar