Dvi vietos, viena privati DNS zona: kam priklauso įrašai?

Pridedate hostą žalioje vietoje, jis išsprendžiamas žaliems naudotojams, o geltonas biuras vis dar gauna NXDOMAIN. Tai ne VPN gedimas ir ne sugedęs resolveris; tai nuosavybės spraga privačioje zonoje. Du nepriklausomai redaguojami įrašų sąrašai netampa viena zona vien todėl, kad vietos gali pasiekti viena kitą. Sprendimas yra publikavimo planas, o ne dar viena ugniasienės taisyklė.

Simptomas įvardija trūkstamą savininką

Kiekviena vieta tikriausiai turi vietinį perrašymą, Pi-hole įrašą arba dnsmasq eilutę, kurią kas nors pridėjo, kai prireikė vardo. Žalias įrašas egzistuoja tik žaliame resolveryje, todėl klientas geltonoje vietoje klausia savo resolverio ir gauna teisingą "tokio vardo nėra". Pasenęs atsakymas atrodo kitaip: hostas persikėlė, viena vieta atnaujino savo kopiją, o kita vis dar grąžina seną adresą.

Nė vienas modelis ilgai nesutvarkomas išvalius talpyklą. Persiuntimo resolverio talpykla yra kadaise gauto atsakymo kopija, o ne naujus vardus publikuojanti valdžia, todėl šiandien veikianti talpykla nieko nesako apie rytojaus hostą. BIND dokumentacija pirminį, antrinį, rekursyvų ir persiuntimo vaidmenis aprašo atskirai būtent dėl šios priežasties.

Taigi dizaino klausimas siauras ir atsakomas: kas gali sukurti įrašą ir kaip tas įrašas pasiekia kiekvieną resolverį, kuris turi į jį atsakyti?

A variantas: viena autoritetinga zona su antriniais

Paleiskite pirminį internal.example.com ir leiskite palaikomiems antriniams gauti zoną kiekvienoje vietoje. Kiekvienos vietos rekursyvus resolveris klausia savo vietinio antrinio, todėl atsakymai ateina iš autoritetingo šaltinio, o ne iš talpyklos, ir vieną kartą padarytas pakeitimas perkeliamas, o ne perrašomas.

Tokia tvarka reikalauja aiškių sprendimų, kuriuos lengva atidėti ir brangu praleisti. Kas gali redaguoti zoną? Kuriems serveriams leidžiama ją perduoti ir kokiais adresais? Ką klientai turėtų matyti, kol tunelis tarp vietų neveikia? Antrinis toliau atsakinėja iš savo paskutinės kopijos, o tai paprastai yra norimas elgesys, tačiau tai turi būti pareikštas pasirinkimas, o ne netikėtumas sutrikimo metu.

Apribokite zonos perdavimus žinomais antriniais pagal adresą ir naudokite operacijų parašus ten, kur įgyvendinimas juos palaiko. Atviras perdavimas yra jūsų vidinės vardų erdvės kopija kiekvienam, kuris pasiekia prievadą.

Kaina yra koordinavimas: vienas redagavimo kelias, viena pakeitimų peržiūra ir bendras supratimas, kas budi, kai įrašas neteisingas.

B variantas: subdomenas kiekvienai vietai

Deleguokite green.internal.example.com žaliai vietai ir yellow.internal.example.com geltonai. Kiekviena vieta tampa autoritetinga savo vardams, o pagrindinė zona neša tik delegavimo įrašus. Ginčas dėl vieno failo išnyksta, ir vietinė komanda gali pridėti hostą nelaukdama centrinio pakeitimo.

Delegavimas turi egzistuoti pagrindinėje zonoje su NS įrašais, rodančiais į vietos autoritetingus serverius. Sąlyginis persiuntimas subdomenui yra galiojanti alternatyva, kai visas delegavimas nepraktiškas, bet tai resolverio nustatymas, o ne paskelbtas faktas, todėl kiekvienam resolveriui reikia tos pačios taisyklės.

Kaina persikelia, o ne išnyksta: pagrindinei zonai vis dar reikia savininko, o naujos vietos kūrimas dabar yra pakeitimas dviejose vietose, o ne vienoje.

Leiskite kiekvienam resolveriui laikytis pasirinkimo

Perduokite klientams patvirtintą resolverį ir paieškos domeną per jų palaikomą konfigūraciją ir įsitikinkite, kad resolveris turi leidžiamą VPN maršrutą į bet kurį nuotolinį DNS serverį, kurio turi klausti. Programoms taip pat reikia maršrutų į privačius adresus, kuriuos grąžina tie atsakymai, nes teisingas vardas be kelio vis tiek yra nutrūkęs ryšys.

Jei Pi-hole teikia vietinį sprendimą, užrašykite, kuriuos įrašus jis turi ir kuriuos užklausas persiunčia. Du nepriklausomai redaguojami Pi-hole sąrašai vis tiek nesireplikuoja. Pi-hole v6 pasirinktinės dnsmasq eilutės nustatomos hosto pusės parinktimis, tokiomis kaip TOML, CLI arba aplinkos kintamieji, ir nėra atskleidžiamos per API; /etc/dnsmasq.d/ failų įkėlimas yra atskira parinktis, kuri pagal nutylėjimą išjungta.

Tada išbandykite iš abiejų pusių vardu, kuris turėtų būti matomas visur:

$ 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 atsakymas pasako, ar geltonas resolveris laiko save autoritetingu, klausia antrinio, ar tik persiunčia. Tai skirtingi dizainai su skirtingais gedimo režimais, ir atsakymas paprastai nurodo, kurį iš tikrųjų įdiegėte.

Užbaikite trimis priėmimo atvejais: vienas vardas iš kiekvienos vietos, per valandą pakeistas įrašas ir nepasiekiama jungtis tarp vietų. Dizainas, kuris praeina tik pirmąjį, turi publikavimo planą popieriuje ir vietinį perrašymą gamyboje.