Bakit ang Pribadong Route 53 Zone ay Nagbabalik ng NXDOMAIN para sa mga Pampublikong Pangalan

Pinapalitan ng mga pribadong Route 53 zone ang sagot para sa isang pangalan sa halip na pagsamahin ito sa pampublikong record, at nakakagulat ito sa mga tao sa pinakamasamang sandali. Magdagdag ng isang panloob na record para sa api.example.net sa isang pribadong zone para sa example.net, iugnay ito sa isang VPC, at lahat ng iba pang pangalan sa ilalim ng magulang na iyon ay sinasagot na ngayon mula sa pribadong zone lamang. Ang kliyenteng nakakaabot sa www.example.net kahapon ay nakakatanggap ngayon ng negatibong sagot. Ang paglalakad sa ibaba ay nagsisimula sa nabigong query na iyon at lumalabas patungo sa zone na sumagot nito.

Magsimula sa query, hindi sa console

Ulitin ang pagkabigo sa kliyenteng nag-ulat nito, at itala ang eksaktong pangalan at uri ng record. Ang pangalang nabibigo para sa A ay maaari pa ring malutas para sa AAAA, at ang browser na muling sumusubok ng naka-cache na pangalan ay nagtatago kung alin sa dalawa ang nasira. Patakbuhin ang query nang dalawang beses: isang beses sa resolver na aktwal na ginagamit ng kliyente, at isang beses sa tracing na lumalampas dito.

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

Ang ikalawang utos ang mahalaga. Pinapangalanan ng linya ng status at seksyon ng authority nito ang zone na gumawa ng sagot, kaya matutukoy mo ang negatibong sagot mula sa pribadong zone kaysa sa timeout, nakaharangang port o resolver na hindi kailanman nakatanggap ng query. resolvectl ay nagpapakita kung aling upstream ang tinanong, at kadalasan hindi ito ang resolver na inakala mong ipinadala ng VPN.

Kung ang na-trace na query ay nagbabalik ng pampublikong address at ang normal ay hindi, buo ang pampublikong record at ang pribadong view ang sumasagot. Ang nag-iisang paghahambing na iyon ang nagpapasya kung aling kalahati ng natitirang bahagi ng pahinang ito ang naaangkop sa iyo.

Basahin kung aling zone ang sumagot

Ang sagot na may NXDOMAIN at may SOA ng pribadong zone sa seksyon ng authority ay tiyak na sagot mula sa zone na iyon, hindi nabigong lookup. Pinili ng Route 53 Resolver ang pribadong naka-host na zone dahil tumugma ang pangalan, pagkatapos ay walang nahanap na record ng hiniling na uri, at ang dokumentadong pag-uugali ay ibalik ang negatibong sagot sa halip na ipasa ang tanong sa pampublikong DNS.

Ang pagpili ay sumusunod sa pagiging tiyak. Kapag maraming pribadong namespace ang nagsasapawan, nananalo ang pinakatiyak na tumutugmang zone, at ang mas malawak na pribadong magulang ay hindi nakakakuha ng ikalawang pagkakataon para sa pangalang wala sa napiling child zone. Ang mga panuntunan sa pagpapasa ay nagdaragdag ng isa pang antas, dahil ang panuntunan ng Resolver na partikular sa domain ay maaaring manaig sa association ng pribadong naka-host na zone. Ilahad ang mga association at panuntunan bago ka magpasya na walang laman ang isang zone.

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

Ang parehong utos ay nangangailangan ng mga kredensyal para sa account na nagmamay-ari ng zone, at ang pangalawa ay nangangailangan ng zone ID mula sa una. Palitan ito ng sarili mong ID; ang placeholder sa itaas ay sadyang hindi totoo.

Bakit nananalo ang pribadong zone

Ang association ang nagpapakita ng zone sa isang VPC, at ang resolver sa VPC na iyon ang naglalapat nito. Ang pribadong zone na hindi nakaugnay sa VPC na pinanggagalingan ng trapiko ng kliyente ay walang anumang epekto, samantalang ang association sa maling VPC ay gumagawa ng pribadong sagot para sa maling populasyon. Suriin ang listahan ng association bago mag-edit ng mga record, dahil ang isang zone ay maaaring tama ngunit hindi pa rin nakikita.

Ang magkakasapaw na namespace ang ikalawang pinagmumulan ng kalituhan. Isang pribadong zone para sa example.net at isang pribadong zone para sa api.example.net ay parehong tumutugma sa isang query ng API, at ang mas tiyak ang sumasagot. Kapaki-pakinabang iyon kapag gusto mo ng makitid na panloob na namespace, at mapanganib kapag kulang ang makitid na zone ng record na mayroon ang mas malawak. Ang mga pagsasaalang-alang sa pribadong naka-host na zone sa dokumentasyon ng Route 53 ay naglalarawan ng pag-uugali ng pagbagsak at ng pagiging una ng mga panuntunan, at sulit itong basahin bago ka magdagdag ng ikalawang magkakasapaw na zone.

Wala sa mga ito ang nagbabago sa pampublikong zone. Ang mga pampublikong resolver ay sumasagot pa rin nang tama sa mga pampublikong record, at iyon ang dahilan kung bakit sa lahat ng nasa labas ng VPC ay mukhang problema ng kliyente ang pagkabigo.

Piliin ang namespace bago ka magdagdag ng mga record

Kung isang bagong pamilya lamang ng mga panloob na serbisyo ang nangangailangan ng mga pribadong pangalan, bigyan ito ng dedikadong pribadong subdomain at iwanan ang pampublikong magulang. Ang pangalang tulad ng internal.example.net ay hindi maaaring magtakip sa www.example.net, at ang saklaw ng epekto ng nawawalang record ay limitado sa mga pangalang inimbento mo para sa layuning iyon. Ang halaga ay maaaring hindi tumugma ang mga umiiral na URL at sertipiko sa bagong pangalan.

Kapag ang mga pampubliko at pribadong user ay kailangang panatilihin ang parehong hostname, ang DNS na may split view ang sinusuportahang disenyo at kailangan mong panatilihin ang mga record sa bawat view nang tahasan. Ang malawak na pribadong zone na may isang record ay hindi pinapanatili ang mga pampublikong dependency sa ilalim ng zone na iyon; pinapalitan ito ng zone na may isang record.

Ilahad ang mga pangalang aktwal na tinatawag ng isang application bago mo ituro ang populasyon ng kliyente sa pribadong view. Ang mga host ng pag-login, host ng static na asset, target ng redirect at API endpoint ang unang nasisira, at kadalasan ay nakakalat sa mga record ng ilang team.

Sundan ang landas ng resolver, pagkatapos ang ruta

Nakikita lamang ng laptop ang pribadong view kung ang mga query nito ay umabot sa resolver na may association. Ang pag-edit ng hosts file sa VPN server ay walang naipapasa sa mga konektadong kliyente, at ang kliyenteng naka-configure sa pampublikong resolver ay patuloy na makakatanggap ng pampublikong sagot habang nakaangat ang tunnel. Kumpirmahin ang address ng resolver na natanggap ng kliyente, pagkatapos ay ulitin ang query mula sa kliyente at hindi mula sa server.

Kapag nalutas na ang pangalan, subukan ang landas patungo sa ibinalik na address bilang hiwalay na hakbang, halimbawa gamit ang ip route get laban sa address na ibinalik ng query. Ang tamang pribadong sagot na walang ruta patungo sa address ay problema sa routing, at ang sagot na nawawalang record ay problema sa DNS view; ang ituring silang isang isyu ay gumagawa ng mga pagtatama na hindi tumatagal. Iwanang hindi nagbabago ang mga pagsusuri ng TLS hostname at sertipiko ng serbisyo, dahil binabago ng pribadong address kung saan pupunta ang koneksyon at wala tungkol sa kung aling sertipiko ang wasto.

Tapusin sa pamamagitan ng pagtatala ng zone, association, resolver at mga pangalang na-verify mo sa change note. Sa gayon, malalaman ng susunod na taong magdadagdag ng record kung aling namespace ang may awtoridad para sa populasyon ng kliyente na iyon.