Twee liggings, een private DNS-sone: wie besit die rekords?

Jy voeg 'n gasheer by die groen ligging, dit los op vir groen gebruikers, en die geel kantoor kry steeds NXDOMAIN. Dit is nie 'n VPN-fout nie en ook nie 'n stukkende resolver nie; dit is 'n leemte in eienaarskap in die private sone. Twee onafhanklik geredigeerde rekordlyste word nie een sone net omdat die liggings mekaar kan bereik nie. Die oplossing is 'n publikasieplan, nie nog 'n vuurmuurreël nie.

Die simptoom noem die ontbrekende eienaar

Elke ligging het waarskynlik 'n plaaslike oorheersing, 'n Pi-hole-inskrywing of 'n dnsmasq-reël wat iemand bygevoeg het toe 'n naam nodig was. Die groen rekord bestaan net op die groen resolver, so 'n kliënt by geel vra sy eie resolver en kry 'n waaragtige "geen sodanige naam nie". 'n Verouderde antwoord lyk anders: die gasheer het geskuif, een ligging het sy kopie opgedateer, en die ander gee steeds die ou adres terug.

Nie een van die twee patrone word lank deur 'n kas skoonmaak opgelos nie. 'n Aanstuur-resolver se kas is 'n kopie van 'n antwoord wat dit eens ontvang het, nie 'n gesag wat nuwe name publiseer nie, so 'n kas wat vandag werk sê niks oor môre se gasheer nie. Die BIND-dokumentasie beskryf primêre, sekondêre, rekursiewe en aanstuur-rolle afsonderlik juis om hierdie rede.

Dus is die ontwerpvraag smal en beantwoordbaar: wie mag 'n rekord skep, en hoe bereik daardie rekord elke resolver wat daarop moet antwoord?

Opsie A: een gesaghebbende sone met sekondêres

Begin 'n primêre vir internal.example.com en laat ondersteunde sekondêres die sone by elke ligging verkry. Elke ligging se rekursiewe resolver vra sy plaaslike sekondêre, so antwoorde kom van 'n gesaghebbende bron eerder as 'n kas, en 'n verandering wat een keer gemaak is, word oorgedra eerder as oorgetik.

Daardie reëling vereis eksplisiete besluite wat maklik is om uit te stel en duur om oor te slaan. Wie mag die sone redigeer? Watter bedieners mag dit oordra, en oor watter adresse? Wat moet kliënte sien terwyl die tonnel tussen liggings af is? 'n Sekondêre hou aan om uit sy laaste kopie te antwoord, wat gewoonlik die gedrag is wat jy wil hê, maar dit moet 'n verklaarde keuse wees eerder as 'n verrassing tydens 'n onderbreking.

Beperk sone-oordragte tot die bekende sekondêres per adres en gebruik transaksiehandtekeninge waar die implementering dit ondersteun. 'n Oop oordrag is 'n kopie van jou interne naamruimte vir enigiemand wat die poort kan bereik.

Die koste is koördinering: een redigeringspad, een veranderingshersiening, en 'n gedeelde begrip van wie op diens is wanneer 'n rekord verkeerd is.

Opsie B: 'n subdomein per ligging

Delegeer green.internal.example.com aan die groen ligging en yellow.internal.example.com aan die geel ligging. Elke ligging word gesaghebbend vir sy eie name, en die ouer sone dra net die delegasierekords. Wedywering oor een lêer verdwyn, en 'n plaaslike span kan 'n gasheer byvoeg sonder om vir 'n sentrale verandering te wag.

Die delegasie moet in die ouer bestaan, met NS-rekords wat na die ligging se gesaghebbende bedieners wys. 'n Voorwaardelike aanstuur vir die subdomein is 'n geldige alternatief wanneer 'n volle delegasie onprakties is, maar dit is 'n resolver-instelling eerder as 'n gepubliseerde feit, so elke resolver het dieselfde reël nodig.

Die koste skuif eerder as om te verdwyn: die ouer sone het steeds 'n eienaar nodig, en die skep van 'n nuwe ligging is nou 'n verandering op twee plekke in plaas van een.

Laat elke resolver die keuse volg

Gee kliënte die goedgekeurde resolver en soekdomein deur hul ondersteunde konfigurasie, en maak seker die resolver het 'n toegelate VPN-roete na enige afgeleë DNS-bediener wat dit moet navraag doen. Toepassings het ook roetes nodig na die private adresse wat daardie antwoorde teruggee, want 'n korrekte naam sonder 'n pad is steeds 'n gebreekte verbinding.

As Pi-hole plaaslike oplossing verskaf, skryf neer watter rekords dit besit en watter navrae dit aanstuur. Twee onafhanklik geredigeerde Pi-hole-lyste repliseer steeds nie. In Pi-hole v6 word pasgemaakte dnsmasq-reëls deur gasheer-kant-opsies soos TOML, CLI of omgewingsveranderlikes gestel en word nie deur die API blootgestel nie; die laai van /etc/dnsmasq.d/-lêers is 'n aparte opsie wat by verstek af is.

Toets dan van beide kante met 'n naam wat oral sigbaar moet wees:

$ 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

Die SOA-antwoord sê vir jou of die geel resolver glo dat dit gesaghebbend is, 'n sekondêre navraag doen, of net aanstuur. Dit is verskillende ontwerpe met verskillende foutmodusse, en die antwoord identifiseer gewoonlik watter een jy werklik ontplooi het.

Sluit af met drie aanvaardingsgevalle: een naam van elke ligging, een rekord binne die uur verander, en die skakel tussen liggings onbeskikbaar. 'n Ontwerp wat net die eerste slaag, het 'n publikasieplan op papier en 'n plaaslike oorheersingsreël in produksie.