Két telephely, egy privát DNS-zóna: kié a rekordok?

Hozzáad egy gazdagépet a zöld telephelyen, az feloldódik a zöld felhasználóknak, a sárga iroda pedig továbbra is NXDOMAIN-t kap. Ez nem VPN-hiba és nem tönkrement feloldó; ez tulajdonosi rés a privát zónában. Két függetlenül szerkesztett rekordlista nem válik egy zónává csak azért, mert a telephelyek elérik egymást. A megoldás közzétételi terv, nem újabb tűzfalszabály.

A tünet megnevezi a hiányzó tulajdonost

Minden telephelyen valószínűleg van helyi felülírás, Pi-hole-bejegyzés vagy dnsmasq-sor, amelyet valaki akkor adott hozzá, amikor névre volt szükség. A zöld rekord csak a zöld feloldón létezik, ezért a sárgán lévő kliens a saját feloldóját kérdezi, és valós „nincs ilyen név” választ kap. Az elavult válasz másképp néz ki: a gazdagép elköltözött, az egyik telephely frissítette a példányát, a másik pedig továbbra is a régi címet adja vissza.

Egyik minta sem javul hosszú ideig a gyorsítótár ürítésétől. A továbbító feloldó gyorsítótára egy korábban kapott válasz másolata, nem új neveket közzétevő jogosultság, ezért a ma működő gyorsítótár semmit sem mond a holnapi gazdagépről. A BIND dokumentációja pontosan ezért írja le külön az elsődleges, másodlagos, rekurzív és továbbító szerepet.

A tervezési kérdés tehát szűk és megválaszolható: ki hozhat létre rekordot, és hogyan jut el az a rekord minden feloldóhoz, amelynek válaszolnia kell rá?

A lehetőség: egy hiteles zóna másodlagosokkal

Futtasson elsődleges kiszolgálót a következőhöz: internal.example.com, és engedje, hogy a támogatott másodlagosok minden telephelyen megszerezzék a zónát. Az egyes telephelyek rekurzív feloldója a helyi másodlagost kérdezi, így a válaszok hiteles forrásból, nem gyorsítótárból jönnek, és az egyszer elvégzett módosítás átadásra kerül, nem újragépelésre.

Ez az elrendezés kifejezett döntéseket igényel, amelyeket könnyű elhalasztani és drága kihagyni. Ki szerkesztheti a zónát? Mely kiszolgálók továbbíthatják, és mely címeken keresztül? Mit lássanak a kliensek, amíg a telephelyek közötti alagút áll? A másodlagos továbbra is az utolsó példányából válaszol, ami általában a kívánt viselkedés, de kimondott választásnak kell lennie, nem meglepetésnek kimaradás idején.

Korlátozza a zónatovábbítást a cím szerint ismert másodlagosokra, és használjon tranzakciós aláírásokat ott, ahol a megvalósítás támogatja. A nyitott továbbítás a belső névterének másolata mindenkinek, aki eléri a portot.

A költség a koordináció: egy szerkesztési útvonal, egy változásfelülvizsgálat és közös megértés arról, ki van ügyeletben, amikor egy rekord hibás.

B lehetőség: alddomain telephelyenként

Delegálja a green.internal.example.com a zöld telephelynek és a yellow.internal.example.com a sárgának. Minden telephely hitelessé válik a saját nevei fölött, a szülő zóna pedig csak a delegálási rekordokat hordozza. Eltűnik a versengés egyetlen fájlért, és egy helyi csapat központi változás megvárása nélkül is hozzáadhat gazdagépet.

A delegálásnak a szülőben kell léteznie, a telephely hiteles kiszolgálóira mutató NS-rekordokkal. A feltételes továbbítás az alddomainhez érvényes alternatíva, ha a teljes delegálás nem praktikus, de ez feloldó-beállítás, nem közzétett tény, ezért minden feloldónak ugyanarra a szabályra van szüksége.

A költség elmozdul, nem tűnik el: a szülő zónának továbbra is kell tulajdonos, és új telephely létrehozása most két helyen végzett változás egy helyett.

Minden feloldó kövesse a választást

Adja meg a klienseknek a jóváhagyott feloldót és a keresési tartományt a támogatott konfigurációjukon keresztül, és biztosítsa, hogy a feloldónak engedélyezett VPN-útvonala legyen minden távoli DNS-kiszolgálóhoz, amelyet kérdeznie kell. Az alkalmazásoknak is szükségük van útvonalakra azokhoz a privát címekhez, amelyeket ezek a válaszok visszaadnak, mert a helyes név útvonal nélkül is törött kapcsolat.

Ha a Pi-hole biztosítja a helyi feloldást, írja le, mely rekordok vannak a birtokában, és mely lekérdezéseket továbbítja. Két függetlenül szerkesztett Pi-hole-lista továbbra sem replikálódik. A Pi-hole v6-ban az egyéni dnsmasq-sorok hosztoldali beállításokkal, például TOML-lel, CLI-vel vagy környezeti változókkal adhatók meg, és nem érhetők el az API-n keresztül; a /etc/dnsmasq.d/ fájlok betöltése külön beállítás, amely alapértelmezés szerint ki van kapcsolva.

Ezután tesztelje mindkét oldalról egy olyan névvel, amelynek mindenhol láthatónak kell lennie:

$ 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

Az SOA-válasz megmondja, hogy a sárga feloldó hitelesnek tartja-e magát, másodlagost kérdez-e, vagy csak továbbít. Ezek különböző tervek különböző hiba módokkal, és a válasz általában megmutatja, melyiket telepítette valójában.

Fejezze be három elfogadási esettel: egy név minden telephelyről, egy órán belül módosított rekord, és a telephelyek közötti kapcsolat elérhetetlensége. Az a terv, amely csak az elsőt teljesíti, papíron közzétételi tervvel, éles környezetben pedig helyi felülírással rendelkezik.