Dvě lokality, jedna privátní zóna DNS: komu patří záznamy?

Přidáte hostitele v zelené lokalitě, vyřeší se pro zelené uživatele a žlutá kancelář stále dostává NXDOMAIN. To není selhání VPN ani rozbitý resolver; je to mezera ve vlastnictví uvnitř privátní zóny. Dva nezávisle upravované seznamy záznamů se nestanou jednou zónou jen proto, že se lokality navzájem dosáhnou. Řešením je plán publikování, ne další pravidlo firewallu.

Příznak pojmenovává chybějícího vlastníka

Každá lokalita má pravděpodobně lokální přepis, záznam v Pi-hole nebo řádek dnsmasq, který někdo přidal, když bylo potřeba jméno. Zelený záznam existuje jen na zeleném resolveru, takže klient ve žluté lokalitě se ptá svého resolveru a dostane pravdivé "takové jméno neexistuje". Zastaralá odpověď vypadá jinak: hostitel se přesunul, jedna lokalita aktualizovala svou kopii a druhá stále vrací starou adresu.

Ani jeden vzorec se dlouho nevyřeší vyčištěním mezipaměti. Mezipaměť předávajícího resolveru je kopie odpovědi, kterou kdysi dostal, ne autorita, která publikuje nová jména, takže mezipaměť, která dnes funguje, nic neříká o zítřejším hostiteli. Dokumentace BIND popisuje role primární, sekundární, rekurzivní a předávající odděleně právě z tohoto důvodu.

Otázka návrhu je tedy úzká a zodpověditelná: kdo smí záznam vytvořit a jak se ten záznam dostane ke každému resolveru, který za něj musí odpovídat?

Možnost A: jedna autoritativní zóna se sekundárními servery

Spusťte primární server pro internal.example.com a nechte podporované sekundární servery získat zónu v každé lokalitě. Rekurzivní resolver každé lokality se ptá svého místního sekundárního serveru, takže odpovědi pocházejí z autoritativního zdroje, ne z mezipaměti, a změna provedená jednou se přenese, místo aby se přepisovala.

Takové uspořádání vyžaduje výslovná rozhodnutí, která se snadno odkládají a draze přeskakují. Kdo smí zónu upravovat? Které servery ji smějí přenášet a přes které adresy? Co mají klienti vidět, dokud je tunel mezi lokalitami mimo provoz? Sekundární server dál odpovídá ze své poslední kopie, což je obvykle chování, které chcete, ale musí to být vyřčená volba, ne překvapení během výpadku.

Omezte přenosy zóny na známé sekundární servery podle adresy a používejte transakční podpisy tam, kde je implementace podporuje. Otevřený přenos je kopie vašeho interního jmenného prostoru pro každého, kdo dosáhne na port.

Cena je koordinace: jedna cesta úprav, jedna revize změn a sdílené porozumění tomu, kdo je pohotovost, když je záznam špatný.

Možnost B: subdoména pro každou lokalitu

Delegujte green.internal.example.com zelené lokalitě a yellow.internal.example.com žluté. Každá lokalita se stane autoritativní pro svá jména a mateřská zóna nese jen záznamy delegace. Spor o jeden soubor zmizí a místní tým může přidat hostitele, aniž by čekal na centrální změnu.

Delegace musí existovat v mateřské zóně, se záznamy NS, které ukazují na autoritativní servery lokality. Podmíněné předávání pro subdoménu je platná alternativa, když je plná delegace nepraktická, ale je to nastavení resolveru, ne publikovaný fakt, takže každý resolver potřebuje stejné pravidlo.

Cena se přesouvá, místo aby zmizela: mateřská zóna stále potřebuje vlastníka a vytvoření nové lokality je nyní změna na dvou místech místo jednoho.

Nechte každý resolver následovat volbu

Dejte klientům schválený resolver a vyhledávací doménu přes jejich podporovanou konfiguraci a ujistěte se, že resolver má povolenou trasu VPN k libovolnému vzdálenému serveru DNS, na který se musí dotazovat. Aplikace také potřebují trasy k privátním adresám, které tyto odpovědi vracejí, protože správné jméno bez cesty je pořád přerušené spojení.

Pokud Pi-hole zajišťuje místní rozlišení, zapište, které záznamy vlastní a které dotazy předává. Dva nezávisle upravované seznamy Pi-hole se stále nereplikují. V Pi-hole v6 se vlastní řádky dnsmasq nastavují přes volby na straně hostitele, jako jsou TOML, CLI nebo proměnné prostředí, a nejsou vystaveny přes API; načítání souborů /etc/dnsmasq.d/ je samostatná volba, která je ve výchozím nastavení vypnutá.

Potom testujte z obou stran jménem, které má být viditelné všude:

$ 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

Odpověď SOA vám řekne, zda se žlutý resolver považuje za autoritativní, zda se ptá sekundárního serveru, nebo jen předává. To jsou různé návrhy s různými režimy selhání a odpověď obvykle určí, který jste skutečně nasadili.

Skončete třemi případy přijetí: jméno z každé lokality, záznam změněný do hodiny a nedostupné propojení mezi lokalitami. Návrh, který projde jen první, má plán publikování na papíře a lokální přepis v produkci.