Kial privata Route 53-zono redonas NXDOMAIN por publikaj nomoj

Privataj Route 53-zonoj anstataŭigas la respondon por nomo anstataŭ kunfandi ĝin kun la publika rikordo, kaj tio surprizas homojn en la plej malbona momento. Aldonu unu internan rikordon por api.example.net en privata zono por example.net, ligu ĝin al VPC, kaj ĉiu alia nomo sub tiu patro nun respondiĝas nur el la privata zono. Kliento, kiu hieraŭ povis atingi www.example.net hodiaŭ ricevas negativan respondon. La sekva trairo komenciĝas ĉe tiu malsukcesa peto kaj iras eksteren al la zono, kiu respondis ĝin.

Komencu ĉe la peto, ne ĉe la konzolo

Reproduktu la malsukceson sur la kliento, kiu raportis ĝin, kaj notu la precizan nomon kaj rikordan tipon. Nomo, kiu malsukcesas por A tamen povas solviĝi por AAAA, kaj retumilo, kiu ripetas kaŝmemorigitan nomon, kaŝas, kiu el la du rompiĝis. Rulu la peton dufoje: unufoje tra la solvilo, kiun la kliento efektive uzas, kaj unufoje kun spurilo, kiu preterpasas ĝin.

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

La dua komando estas la grava. Ĝia statuslinio kaj aŭtoritata sekcio nomas la zonon, kiu produktis la respondon, do vi povas distingi negativan respondon el la privata zono disde tempolimo, blokita pordo aŭ solvilo, kiu neniam ricevis la peton. resolvectl montras, kiun supran servilon oni demandis, kaj tio ofte ne estas la solvilo, kiun vi supozis, ke la VPN sendis.

Se la spurita peto redonas la publikan adreson dum la normala ne, la publika rikordo estas sendifekta kaj la privata vido respondas. Tiu sola komparo decidas, kiun duonon de la resto de ĉi tiu paĝo koncernas vin.

Legu, kiu zono respondis

Respondo portanta NXDOMAIN kun la SOA de la privata zono en la aŭtoritata sekcio estas definitiva respondo de tiu zono, ne malsukcesa serĉo. Route 53 Resolver elektis la privatan gastigatan zonon ĉar ĝia nomo kongruis, poste trovis neniun rikordon de la petita tipo, kaj la dokumentita konduto estas redoni la negativan respondon anstataŭ plusendi la demandon al publika DNS.

La elekto sekvas specifecon. Kun pluraj interkovraj privataj nomspacoj venkas la plej specifa kongrua zono, kaj pli vasta privata patro ne ricevas duan ŝancon por nomo, kiun la elektita idozono ne havas. Plusendaj reguloj aldonas plian tavolon, ĉar domajnspecifa Resolver-regulo povas venki la ligon de la privata gastigata zono. Listigu la ligojn kaj regulojn antaŭ ol konkludi, ke zono estas malplena.

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

Ambaŭ komandoj bezonas akreditaĵojn por la konto, kiu posedas la zonon, kaj la dua bezonas la zonan identigilon el la unua. Anstataŭigu ĝin per via propra identigilo; la anstataŭilo supre intence ne estas reala.

Kial la privata zono venkas

La ligo estas tio, kio faras la zonon videbla al VPC, kaj la solvilo en tiu VPC aplikas ĝin. Privata zono, kiu ne estas ligita al la VPC, de kiu venas la trafiko de la kliento, havas neniun efikon, dum ligo al la malĝusta VPC produktas privatan respondon por la malĝusta loĝantaro. Kontrolu la liston de ligoj antaŭ ol redakti rikordojn, ĉar zono povas esti ĝusta kaj tamen nevidebla.

Interkovraj nomspacoj estas la dua fonto de konfuzo. Privata zono por example.net kaj privata zono por api.example.net ambaŭ kongruas kun API-peto, kaj la pli specifa respondas. Tio utilas, kiam vi volas mallarĝan internan nomspacon, kaj danĝeras, kiam la mallarĝa zono mankas rikordon, kiun la pli vasta havas. La konsideroj pri privataj gastigataj zonoj en la Route 53-dokumentaro priskribas kaj la fal-konduton kaj la regulan prioritaton, kaj indas legi ilin antaŭ ol aldoni duan interkovran zonon.

Nenio el tio ŝanĝas la publikan zonon. Publikaj solviloj ankoraŭ ĝuste respondas la publikajn rikordojn, kaj tial la malsukceso aspektas kiel klienta problemo por ĉiuj ekster la VPC.

Elektu la nomspacon antaŭ ol aldoni rikordojn

Se nur nova familio de internaj servoj bezonas privatajn nomojn, donu al ĝi dediĉitan privatan subdomajnon kaj lasu la publikan patron trankvila. Nomo kiel internal.example.net ne povas ombrigi www.example.net, kaj la efiko de mankanta rikordo limiĝas al nomoj, kiujn vi elpensis por la celo. La kosto estas, ke ekzistantaj URL-oj kaj atestiloj eble ne kongruos kun la nova nomo.

Kiam publikaj kaj privataj uzantoj devas konservi la saman gastignomon, DNS kun dividita vido estas la subtenata dezajno kaj postulas, ke vi eksplicite prizorgu la rikordojn en ĉiu vido. Vasta privata zono kun unu rikordo en ĝi ne konservas la publikajn dependecojn sub tiu zono; ĝi anstataŭigas ilin per zono, kiu havas unu rikordon.

Inventaru la nomojn, kiujn aplikaĵo efektive vokas, antaŭ ol direkti klientan loĝantaron al la privata vido. Ensalutaj gastigantoj, gastigantoj de statikaj rimedoj, alidirektaj celoj kaj API-finpunktoj rompiĝas unue, kaj ili kutime disiĝas tra la rikordoj de pluraj teamoj.

Spuru la solvilan vojon, poste la itineron

Tekkomputilo vidas la privatan vidon nur se ĝiaj petoj atingas la solvilon, kiu havas la ligon. Redakti hosts-dosieron sur la VPN-servilo publikigas nenion al ligitaj klientoj, kaj kliento agordita kun publika solvilo daŭre ricevos publikajn respondojn dum la tunelo estas supre. Konfirmu la solvilan adreson, kiun la kliento ricevis, poste ripetu la peton de la kliento anstataŭ de la servilo.

Post kiam la nomo solviĝas, testu la vojon al la redonita adreso kiel apartan paŝon, ekzemple per ip route get kontraŭ la adreso, kiun la peto redonis. Ĝusta privata respondo sen itinero al la adreso estas itinera problemo, kaj respondo pri mankanta rikordo estas DNS-vida problemo; trakti ilin kiel unu aferon produktas korektojn, kiuj ne teniĝas. Lasu la kontrolojn de TLS-gastignomo kaj atestilo senŝanĝaj, ĉar privata adreso ŝanĝas, kien iras la konekto, kaj nenion pri tio, kiu atestilo validas.

Finu registrante en la ŝanĝnoto la zonon, la ligon, la solvilon kaj la nomojn, kiujn vi kontrolis. Tiam la sekva persono, kiu aldonos rikordon, scios, kiu nomspaco estas aŭtoritata por tiu klienta loĝantaro.