Twa lokaasjes, ien privee DNS-sône: wa hat de records?

Jo foegje in host ta by it griene lokaasje, dy wurdt oplost foar griene brûkers, en it giele kantoar krijt noch altyd NXDOMAIN. Dat is gjin VPN-flater en gjin stikken resolver; it is in eignerskipgat yn 'e privee sône. Twa apart bewurke recordlisten wurde net ien sône allinnich om't de lokaasjes elkoar berikke kinne. De oplossing is in publikaasjeplan, net noch in firewallregel.

It symptoom neamt de ûntbrekkende eigner

Elk lokaasje hat wierskynlik in lokale oerskriuwing, in Pi-hole-ynstjoer of in dnsmasq-rigel dy't immen tafoege doe't in namme nedich wie. It griene record bestiet allinnich op 'e griene resolver, dus in klant by giel freget syn eigen resolver en krijt in wier "gjin sa'n namme". In ferâldere antwurd sjocht der oars út: de host is ferhuze, ien lokaasje hat syn kopy bywurke, en de oare jout noch altyd it âlde adres werom.

Gjin fan beide patroanen wurdt lang oplost troch in cache te leegjen. De cache fan in trochstjoerende resolver is in kopy fan in antwurd dat er ea krige, gjin autoriteit dy't nije nammen publisearret, dus in cache dy't hjoed wurket seit neat oer de host fan moarn. De BIND-dokumintaasje beskriuwt primêre, sekundêre, rekursive en trochstjoerende rollen apart krekt om dy reden.

Dus de ûntwerpfraach is smel en te beantwurdzjen: wa mei in record oanmeitsje, en hoe berikt dat record elke resolver dy't derop antwurdzje moat?

Opsje A: ien autoritative sône mei sekundêren

Start in primêre foar internal.example.com en lit stipe sekundêren de sône by elk lokaasje krije. De rekursive resolver fan elk lokaasje freget syn lokale sekundêre, dus antwurden komme fan in autoritative boarne ynstee fan in cache, en in feroaring dy't ien kear dien is, wurdt oerdroegen ynstee fan oertikke.

Dy regeling freget eksplisite besluten dy't maklik útsteld wurde en djoer om oer te slaan. Wa mei de sône bewurkje? Hokker servers meie dy oerdrage, en oer hokker adressen? Wat moatte klanten sjen wylst de tunnel tusken lokaasjes del is? In sekundêre bliuwt antwurdzje út syn lêste kopy, dat is meastentiids it gedrach dat jo wolle, mar it moat in ferklearre kar wêze en gjin ferrassing by in steuring.

Behein sône-oerdrachten ta de bekende sekundêren op adres en brûk transaksje-ûndertekeningen wêr't de ymplemintaasje dy stipet. In iepen oerdracht is in kopy fan jo ynterne nammeromte foar elkenien dy't de poarte berikke kin.

De kosten binne koördinaasje: ien bewurkingspaad, ien feroaringsresinsje, en in mienskiplik begryp fan wa't tsjinst hat as in record ferkeard is.

Opsje B: in subdomein per lokaasje

Delegearje green.internal.example.com oan it griene lokaasje en yellow.internal.example.com oan it giele. Elk lokaasje wurdt autoritatyf foar syn eigen nammen, en de âlderlike sône draacht allinnich de delegasjerecords. Striid oer ien bestân ferdwynt, en in lokaal team kin in host tafoegje sûnder op in sintrale feroaring te wachtsjen.

De delegasje moat yn 'e âlder bestean, mei NS-records dy't nei de autoritative servers fan it lokaasje wize. In betingst trochstjoeren foar it subdomein is in jildich alternatyf as in folsleine delegasje net praktysk is, mar it is in resolverynstelling en gjin publisearre feit, dus elke resolver hat deselde regel nedich.

De kosten ferpleatse har ynstee fan te ferdwinen: de âlderlike sône hat noch altyd in eigner nedich, en in nij lokaasje meitsje is no in feroaring op twa plakken ynstee fan ien.

Lit elke resolver de kar folgje

Jou klanten de goedkarde resolver en it sykdomein fia har stipe konfiguraasje, en soargje derfoar dat de resolver in tastiene VPN-route hat nei elke fiere DNS-server dêr't er oan freegje moat. Tapassingen hawwe ek routes nedich nei de privee adressen dy't dy antwurden weromjouwe, want in korrekte namme sûnder paad is noch altyd in brutsen ferbining.

As Pi-hole lokale oplossing leveret, skriuw dan op hokker records it hat en hokker queries it trochstjoert. Twa apart bewurke Pi-hole-listlisten replikearje noch altyd net. Yn Pi-hole v6 wurde oanpaste dnsmasq-rigels ynsteld fia opsjes oan 'e hostkant lykas TOML, CLI of omjouwingsfariabelen en wurde se net fia de API bleatsteld; it laden fan /etc/dnsmasq.d/-bestannen is in aparte opsje dy't standert út is.

Test dan fan beide kanten mei in namme dy't oeral sichtber wêze moat:

$ 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

It SOA-antwurd fertelt jo oft de giele resolver tinkt dat er autoritatyf is, in sekundêre freget, of gewoan trochstjoert. Dat binne ferskillende ûntwerpen mei ferskillende flatermodi, en it antwurd identifisearret meastentiids hokker jo echt útein set hawwe.

Einigje mei trije akseptaasjefallen: ien namme fan elk lokaasje, ien record binnen it oere feroare, en de skeakel tusken lokaasjes net beskikber. In ûntwerp dat allinnich it earste hellet, hat in publikaasjeplan op papier en in lokale oerskriuwing yn produksje.