Dalawang site, isang pribadong DNS zone: kanino ang mga record?

Nagdadagdag ka ng host sa berdeng site, nareresolba ito para sa berdeng user, at tumatanggap pa rin ng NXDOMAIN ang dilaw na opisina. Hindi ito pagkabigo ng VPN at hindi sirang resolver; ito ay puwang sa pagmamay-ari sa loob ng pribadong zone. Ang dalawang listahan ng record na hiwalay na inedit ay hindi nagiging isang zone dahil lang kayang maabot ng mga site ang isa't isa. Ang solusyon ay plano sa paglalathala, hindi isa pang tuntunin ng firewall.

Pinapangalanan ng sintomas ang nawawalang may-ari

Malamang may lokal na override, entry sa Pi-hole o linya ng dnsmasq ang bawat site na idinagdag ng isang tao nang kailangan ang isang pangalan. Ang berdeng record ay umiiral lamang sa berdeng resolver, kaya ang client sa dilaw ay nagtatanong sa sarili nitong resolver at tumatanggap ng totoong "walang ganoong pangalan". Ang lumang sagot ay iba ang hitsura: lumipat ang host, in-update ng isang site ang kopya nito, at ibinabalik pa rin ng isa ang lumang address.

Wala sa dalawang pattern ang naaayos nang matagal sa pamamagitan ng paglilinis ng cache. Ang cache ng forwarding resolver ay kopya ng sagot na natanggap nito minsan, hindi awtoridad na naglalathala ng bagong pangalan, kaya ang cache na gumagana ngayon ay walang sinasabi tungkol sa host bukas. Inilalarawan ng dokumentasyon ng BIND nang hiwalay ang mga papel na primary, secondary, recursive at forwarding dahil mismo sa kadahilanang ito.

Kaya ang tanong sa disenyo ay makitid at masasagot: sino ang maaaring gumawa ng record, at paano naaabot ng record na iyon ang bawat resolver na dapat sumagot para dito?

Opsyon A: isang awtoritatibong zone na may mga secondary

Magpatakbo ng primary para sa internal.example.com at hayaang makuha ng mga sinusuportahang secondary ang zone sa bawat site. Ang recursive resolver ng bawat site ay nagtatanong sa lokal nitong secondary, kaya galing sa awtoritatibong pinagmulan ang mga sagot at hindi sa cache, at ang pagbabagong ginawa nang isang beses ay inililipat sa halip na i-type muli.

Ang kaayusang iyon ay nangangailangan ng malinaw na desisyon na madaling ipagpaliban at magastos na laktawan. Sino ang maaaring mag-edit ng zone? Aling mga server ang pinapayagang maglipat nito, at sa aling mga address? Ano ang dapat makita ng mga client habang down ang tunnel sa pagitan ng mga site? Ang secondary ay patuloy na sumasagot mula sa huling kopya nito, na kadalasan ang gustong pag-uugali, ngunit dapat itong ipinahayag na pagpipilian at hindi sorpresa habang may outage.

Limitahan ang mga transfer ng zone sa mga kilalang secondary ayon sa address at gumamit ng mga lagda ng transaksyon kung saan sinusuportahan ito ng implementasyon. Ang bukas na transfer ay kopya ng iyong panloob na namespace ng pangalan para sa sinumang makakaabot sa port.

Ang halaga ay koordinasyon: isang landas ng pag-edit, isang pagsusuri ng pagbabago, at pinagsamang pag-unawa kung sino ang naka-duty kapag mali ang isang record.

Opsyon B: isang subdomain bawat site

I-delegate ang green.internal.example.com sa berdeng site at yellow.internal.example.com sa dilaw. Bawat site ay nagiging awtoritatibo para sa sarili nitong mga pangalan, at ang parent zone ay nagdadala lamang ng mga record ng delegasyon. Nawawala ang tunggalian sa isang file, at makakapagdagdag ng host ang lokal na koponan nang hindi naghihintay ng sentral na pagbabago.

Dapat umiiral ang delegasyon sa parent zone, na may mga NS record na tumuturo sa mga awtoritatibong server ng site. Ang conditional forward para sa subdomain ay balidong alternatibo kapag hindi praktikal ang buong delegasyon, ngunit setting ito ng resolver at hindi nailathalang katotohanan, kaya kailangan ng bawat resolver ng parehong tuntunin.

Lumilipat ang halaga sa halip na mawala: kailangan pa rin ng may-ari ang parent zone, at ang paggawa ng bagong site ay pagbabago na ngayon sa dalawang lugar sa halip na isa.

Hayaang sumunod ang bawat resolver sa pinili

Ibigay sa mga client ang aprubadong resolver at search domain sa pamamagitan ng sinusuportahang configuration, at tiyakin na may pinapayagang ruta ng VPN ang resolver patungo sa anumang remote na DNS server na kailangan nitong tanungin. Kailangan din ng mga application ng ruta patungo sa mga pribadong address na ibinabalik ng mga sagot na iyon, dahil ang tamang pangalan na walang landas ay putol pa ring koneksyon.

Kung nagbibigay ang Pi-hole ng lokal na resolusyon, isulat kung aling mga record ang pagmamay-ari nito at aling mga query ang ipinapasa nito. Ang dalawang listahan ng Pi-hole na hiwalay na inedit ay hindi pa rin nagre-replicate. Sa Pi-hole v6, ang mga custom na linya ng dnsmasq ay itinatakda sa pamamagitan ng mga opsyon sa panig ng host tulad ng TOML, CLI o mga environment variable at hindi inilalantad sa API; ang paglo-load ng mga file ng /etc/dnsmasq.d/ ay hiwalay na opsyon na patay bilang default.

Pagkatapos ay subukan mula sa magkabilang panig gamit ang pangalang dapat makita sa lahat ng dako:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

Sinasabi ng sagot ng SOA kung itinuturing ng dilaw na resolver na awtoritatibo ito, nagtatanong sa secondary, o nagpapasa lamang. Ito ay magkaibang disenyo na may magkaibang paraan ng pagkasira, at karaniwang tinutukoy ng sagot kung alin ang tunay mong inilagay.

Tapusin sa tatlong kaso ng pagtanggap: isang pangalan mula sa bawat site, isang record na binago sa loob ng isang oras, at ang link sa pagitan ng mga site ay hindi available. Ang disenyong pumasa lamang sa una ay may plano sa paglalathala sa papel at lokal na override sa produksyon.