Du retejoj, unu privata DNS-zono: kiu posedas la rikordojn?

Vi aldonas gastiganton ĉe la verda retejo, ĝi solviĝas por verdaj uzantoj, kaj la flava oficejo ankoraŭ ricevas NXDOMAIN. Tio ne estas VPN-fiasko kaj ne difektita solvilo; ĝi estas manko de posedo ene de la privata zono. Du sendepende redaktitaj rikordaj listoj ne fariĝas unu zono nur ĉar la retejoj povas atingi unu la alian. La solvo estas publikiga plano, ne alia fajroŝirma regulo.

La simptomo nomas la mankan posedanton

Ĉiu retejo verŝajne havas lokan anstataŭigon, Pi-hole-eniron aŭ dnsmasq-linion, kiun iu aldonis kiam nomo necesis. La verda rikordo ekzistas nur en la verda solvilo, do kliento ĉe la flava demandas sian propran solvilon kaj ricevas veran "neniu tia nomo". Malnova respondo aspektas alie: la gastiganto translokiĝis, unu retejo ĝisdatigis sian kopion, kaj la alia ankoraŭ resendas la malnovan adreson.

Nek unu modelo longe ripariĝas per malplenigo de kaŝmemoro. La kaŝmemoro de plusendanta solvilo estas kopio de respondo, kiun ĝi iam ricevis, ne aŭtoritato, kiu publikigas novajn nomojn, do kaŝmemoro, kiu funkcias hodiaŭ, diras nenion pri la morgaŭa gastiganto. La dokumentaro de BIND priskribas la rolojn ĉefa, duaranga, rekursia kaj plusenda aparte ĝuste pro ĉi tiu kialo.

Do la dezajna demando estas mallarĝa kaj respondebla: kiu rajtas krei rikordon, kaj kiel tiu rikordo atingas ĉiun solvilon, kiu devas respondi pri ĝi?

Opcio A: unu aŭtoritata zono kun duarangaj

Funkciigu ĉefan por internal.example.com kaj lasu subtenatajn duarangajn akiri la zonon ĉe ĉiu retejo. La rekursia solvilo de ĉiu retejo demandas sian lokan duarangan, do respondoj venas de aŭtoritata fonto anstataŭ kaŝmemoro, kaj ŝanĝo farita unufoje translokiĝas anstataŭ retajpiĝi.

Tiu aranĝo postulas eksplicitajn decidojn, kiujn oni facile prokrastas kaj multekoste preterlasas. Kiu rajtas redakti la zonon? Kiuj serviloj rajtas translokigi ĝin, kaj per kiuj adresoj? Kion klientoj vidu dum la tunelo inter retejoj estas malaktiva? Duaranga daŭre respondas el sia lasta kopio, kio kutime estas la konduto, kiun vi volas, sed ĝi devas esti deklarita elekto, ne surprizo dum elfalŝtato.

Limigu zonajn translokigojn al la konataj duarangaj laŭ adreso kaj uzu transakciajn subskribojn tie, kie la efektivigo subtenas ilin. Malferma translokigo estas kopio de via interna nomspaco por ĉiu, kiu povas atingi la pordon.

La kosto estas kunordigado: unu redakta vojo, unu ŝanĝa revizio, kaj komuna kompreno pri tio, kiu estas deĵora kiam rikordo malĝustas.

Opcio B: subdomajno por ĉiu retejo

Delegu green.internal.example.com al la verda retejo kaj yellow.internal.example.com al la flava. Ĉiu retejo fariĝas aŭtoritata pri siaj propraj nomoj, kaj la gepatra zono portas nur la delegajn rikordojn. Konkurenco pri unu dosiero malaperas, kaj loka teamo povas aldoni gastiganton sen atendi centran ŝanĝon.

La delegado devas ekzisti en la gepatra zono, kun NS-rikordoj, kiuj montras al la aŭtoritataj serviloj de la retejo. Kondiĉa plusendo por la subdomajno estas valida alternativo, kiam plena delegado ne praktikas, sed ĝi estas solvila agordo, ne publikigita fakto, do ĉiu solvilo bezonas la saman regulon.

La kosto translokiĝas anstataŭ manĝiĝi: la gepatra zono ankoraŭ bezonas posedanton, kaj krei novan retejon nun estas ŝanĝo en du lokoj anstataŭ unu.

Igu ĉiun solvilon sekvi la elekton

Donu al klientoj la aprobitan solvilon kaj la serĉan domajnon per sia subtenata agordo, kaj certiĝu, ke la solvilo havas permesitan VPN-vojon al iu ajn fora DNS-servilo, kiun ĝi devas demandi. Aplikoj ankaŭ bezonas vojojn al la privataj adresoj, kiujn tiuj respondoj resendas, ĉar ĝusta nomo sen vojo ankoraŭ estas rompita konekto.

Se Pi-hole provizas lokan solvon, notu, kiujn rikordojn ĝi posedas kaj kiujn demandojn ĝi plusendas. Du sendepende redaktitaj Pi-hole-listoj ankoraŭ ne replikiĝas. En Pi-hole v6, propraj dnsmasq-linioj agordiĝas per opcioj ĉe la gastiganta flanko kiel TOML, CLI aŭ mediaj variabloj kaj ne estas elmontritaj per la API; ŝargi dosierojn de /etc/dnsmasq.d/ estas aparta opcio, kiu estas malŝaltita defaŭlte.

Poste testu de ambaŭ flankoj per nomo, kiu devus esti videbla ĉie:

$ 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

La SOA-respondo diras al vi, ĉu la flava solvilo kredas esti aŭtoritata, demandas duarangan, aŭ nur plusendas. Tiuj estas malsamaj dezajnoj kun malsamaj fiaskmanieroj, kaj la respondo kutime identigas, kiun vi efektive starigis.

Finu per tri akceptaj kazoj: unu nomo el ĉiu retejo, unu rikordo ŝanĝita ene de la horo, kaj la interreteja ligilo neatingebla. Dezajno, kiu trapasas nur la unuan, havas publikigan planon surpapere kaj lokan anstataŭigon en produktado.