Dve lokality, jedna privátna zóna DNS: komu patria záznamy?

Pridáte hostiteľa v zelenej lokalite, vyrieši sa pre zelených používateľov a žltá kancelária stále dostáva NXDOMAIN. To nie je zlyhanie VPN ani pokazený resolver; je to medzera vo vlastníctve v rámci privátnej zóny. Dva nezávisle upravované zoznamy záznamov sa nestanú jednou zónou len preto, že lokality sa navzájom dosiahnu. Riešením je plán publikovania, nie ďalšie pravidlo firewallu.

Príznak pomenúva chýbajúceho vlastníka

Každá lokalita má pravdepodobne lokálne prepísanie, záznam v Pi-hole alebo riadok dnsmasq, ktorý niekto pridal, keď bolo potrebné meno. Zelený záznam existuje len na zelenom resolveri, takže klient v žltej lokalite sa pýta svojho resolvera a dostane pravdivé "také meno neexistuje". Zastaraná odpoveď vyzerá inak: hostiteľ sa presunul, jedna lokalita aktualizovala svoju kópiu a druhá stále vracia starú adresu.

Ani jeden vzor sa dlho nevyrieši vyčistením medzipamäte. Medzipamäť preposielajúceho resolvera je kópia odpovede, ktorú kedysi dostal, nie autorita, ktorá publikuje nové mená, takže medzipamäť, ktorá dnes funguje, nič nehovorí o zajtrajšom hostiteľovi. Dokumentácia BIND opisuje roly primárny, sekundárny, rekurzívny a preposielajúci oddelene práve z tohto dôvodu.

Otázka návrhu je teda úzka a zodpovedateľná: kto smie vytvoriť záznam a ako sa ten záznam dostane ku každému resolveru, ktorý zaň musí odpovedať?

Možnosť A: jedna autoritatívna zóna so sekundárnymi servermi

Spustite primárny server pre internal.example.com a nechajte podporované sekundárne servery získať zónu v každej lokalite. Rekurzívny resolver každej lokality sa pýta svojho miestneho sekundárneho servera, takže odpovede prichádzajú z autoritatívneho zdroja, nie z medzipamäte, a zmena vykonaná raz sa prenesie namiesto prepísania.

Také usporiadanie vyžaduje výslovné rozhodnutia, ktoré sa ľahko odkladajú a draho preskakujú. Kto smie upravovať zónu? Ktoré servery ju smú prenášať a cez ktoré adresy? Čo majú klienti vidieť, kým je tunel medzi lokalitami mimo prevádzky? Sekundárny server ďalej odpovedá zo svojej poslednej kópie, čo je zvyčajne želané správanie, ale musí to byť vyslovená voľba, nie prekvapenie počas výpadku.

Obmedzte prenosy zóny na známe sekundárne servery podľa adresy a používajte transakčné podpisy tam, kde ich implementácia podporuje. Otvorený prenos je kópia vášho interného menného priestoru pre každého, kto dosiahne port.

Cenou je koordinácia: jedna cesta úprav, jedna revízia zmien a spoločné porozumenie tomu, kto je v pohotovosti, keď je záznam nesprávny.

Možnosť B: subdoména pre každú lokalitu

Delegujte green.internal.example.com zelenej lokalite a yellow.internal.example.com žltej. Každá lokalita sa stane autoritatívnou pre svoje mená a materská zóna nesie len záznamy delegácie. Spor o jeden súbor zmizne a miestny tím môže pridať hostiteľa bez čakania na centrálnu zmenu.

Delegácia musí existovať v materskej zóne, so záznamami NS, ktoré ukazujú na autoritatívne servery lokality. Podmienené preposielanie pre subdoménu je platná alternatíva, keď je plná delegácia nepraktická, ale je to nastavenie resolvera, nie publikovaný fakt, takže každý resolver potrebuje rovnaké pravidlo.

Cena sa presúva, namiesto aby zmizla: materská zóna stále potrebuje vlastníka a vytvorenie novej lokality je teraz zmena na dvoch miestach namiesto jedného.

Nech každý resolver nasleduje voľbu

Dajte klientom schválený resolver a vyhľadávaciu doménu cez ich podporovanú konfiguráciu a uistite sa, že resolver má povolenú trasu VPN k akémukoľvek vzdialenému serveru DNS, na ktorý sa musí pýtať. Aplikácie tiež potrebujú trasy k privátnym adresám, ktoré tieto odpovede vracajú, pretože správne meno bez cesty je stále prerušené spojenie.

Ak Pi-hole zabezpečuje lokálne rozlíšenie, zapíšte, ktoré záznamy vlastní a ktoré dopyty preposiela. Dva nezávisle upravované zoznamy Pi-hole sa stále nereplikujú. V Pi-hole v6 sa vlastné riadky dnsmasq nastavujú cez voľby na strane hostiteľa, ako sú TOML, CLI alebo premenné prostredia, a nie sú vystavené cez API; načítanie súborov z /etc/dnsmasq.d/ je samostatná voľba, ktorá je predvolene vypnutá.

Potom testujte z oboch strán menom, ktoré by malo byť viditeľné všade:

$ 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

Odpoveď SOA vám povie, či sa žltý resolver považuje za autoritatívny, či sa pýta sekundárneho servera alebo len preposiela. To sú rôzne návrhy s rôznymi režimami zlyhania a odpoveď zvyčajne určí, ktorý ste skutočne nasadili.

Skončite tromi prípadmi prijatia: meno z každej lokality, záznam zmenený do hodiny a nedostupné prepojenie medzi lokalitami. Návrh, ktorý prejde len prvý, má plán publikovania na papieri a lokálne prepísanie v produkcii.