Kaks asukohta, üks privaatne DNS-tsoon: kellele kirjed kuuluvad?

Lisate hosti rohelises asukohas, see lahendatakse roheliste kasutajate jaoks, ja kollane kontor saab endiselt NXDOMAINi. See ei ole VPN-i rike ega katkine resolver; see on omandiõiguse lünk privaatses tsoonis. Kaks sõltumatult muudetud kirjeloendit ei muutu üheks tsooniks ainult seetõttu, et asukohad pääsevad teineteisele ligi. Lahendus on avaldamisplaan, mitte veel üks tulemüürireegel.

Sümptom nimetab puuduva omaniku

Igas asukohas on tõenäoliselt kohalik alistamine, Pi-hole'i kirje või dnsmasqi rida, mille keegi lisas, kui nime oli vaja. Roheline kirje on ainult rohelises resolveris, seega kollases asuv klient küsib oma resolverilt ja saab tõese "sellist nime ei ole". Aegunud vastus näeb välja teistsugune: host liikus, üks asukoht uuendas oma koopiat ja teine tagastab endiselt vana aadressi.

Kumbki muster ei parane kauaks vahemälu tühjendamisega. Edastava resolveri vahemälu on kunagi saadud vastuse koopia, mitte uusi nimesid avaldav volitus, seega täna töötav vahemälu ei ütle homse hosti kohta midagi. BIND-i dokumentatsioon kirjeldab primaarse, sekundaarse, rekursiivse ja edastava rolli eraldi täpselt sel põhjusel.

Seega on disainiküsimus kitsas ja vastatav: kes tohib kirje luua ja kuidas see kirje jõuab igasse resolverisse, mis peab selle kohta vastama?

Valik A: üks autoriteetne tsoon sekundaarsetega

Käivitage primaarne server internal.example.com jaoks ja laske toetatud sekundaarsetel tsoon igas asukohas hankida. Iga asukoha rekursiivne resolver küsib oma kohalikku sekundaarset, seega tulevad vastused autoriteetsest allikast, mitte vahemälust, ja üks kord tehtud muudatus edastatakse, mitte ei kirjutata uuesti.

Selline korraldus nõuab selgesõnalisi otsuseid, mida on lihtne edasi lükata ja kallis vahele jätta. Kes tohib tsooni muuta? Millistel serveritel on lubatud seda edastada ja milliste aadresside kaudu? Mida peaksid kliendid nägema, kui asukohtade vaheline tunnel on maas? Sekundaarne jätkab vastamist oma viimasest koopiast, mis on tavaliselt soovitud käitumine, kuid see peab olema väljaöeldud valik, mitte katkestuse ajal tekkiv üllatus.

Piirake tsooni edastused aadressi järgi teadaolevate sekundaarsetega ja kasutage tehinguallkirju seal, kus teostus neid toetab. Avatud edastus on teie sisemise nimeruumi koopia kõigile, kes pääsevad pordile ligi.

Hind on koordineerimine: üks muutmise tee, üks muudatuse ülevaatus ja ühine arusaam sellest, kes on valves, kui kirje on vale.

Valik B: alamdomeen iga asukoha kohta

Delegeerige green.internal.example.com rohelisele asukohale ja yellow.internal.example.com kollasele. Iga asukoht muutub autoriteetseks oma nimede jaoks ja vanemtsoon kannab ainult delegeerimiskirjeid. Võitlus ühe faili pärast kaob ning kohalik meeskond saab hosti lisada ilma keskse muudatuse ootamiseta.

Delegeerimine peab olema vanemtsoonis, NS-kirjetega, mis osutavad asukoha autoriteetsetele serveritele. Tingimuslik edastamine alamdomeeni jaoks on kehtiv alternatiiv, kui täielik delegeerimine on ebapraktiline, kuid see on resolveri seade, mitte avaldatud fakt, seega vajab iga resolver sama reeglit.

Hind liigub, mitte ei kao: vanemtsoon vajab endiselt omanikku ja uue asukoha loomine on nüüd muudatus kahes kohas, mitte ühes.

Las iga resolver järgib valikut

Andke klientidele kinnitatud resolver ja otsingudomeen nende toetatud konfiguratsiooni kaudu ning veenduge, et resolveril on lubatud VPN-marsruut kõigi kaugemate DNS-serveriteni, mida ta peab küsima. Rakendused vajavad marsruute ka privaatsete aadressideni, mida need vastused tagastavad, sest õige nimi ilma teeta on endiselt katkine ühendus.

Kui Pi-hole pakub kohalikku lahendust, kirjutage üles, milliseid kirjeid see omab ja milliseid päringuid edastab. Kaks sõltumatult muudetud Pi-hole'i loendit ei replikeeru endiselt. Pi-hole v6-s seatakse kohandatud dnsmasqi read hostipoolsete valikutega nagu TOML, CLI või keskkonnamuutujad ja neid ei avalikustata API kaudu; failide laadimine kaustast /etc/dnsmasq.d/ on eraldi valik, mis on vaikimisi välja lülitatud.

Seejärel testige mõlemalt poolt nimega, mis peaks olema nähtav kõikjal:

$ 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

SOA-vastus ütleb, kas kollane resolver peab end autoriteetseks, küsib sekundaarset või lihtsalt edastab. Need on erinevad disainid erinevate rikkerežiimidega ja vastus näitab tavaliselt, millise te tegelikult juurutasite.

Lõpetage kolme vastuvõtujuhtumiga: üks nimi igast asukohast, tunni jooksul muudetud kirje ja asukohtadevaheline link kättesaamatu. Disain, mis läbib ainult esimese, on paberil avaldamisplaaniga ja tootmises kohaliku alistamisega.