Dwie lokalizacje, jedna prywatna strefa DNS: do kogo należą rekordy?

Dodajesz host w zielonej lokalizacji, rozwiązuje się on dla zielonych użytkowników, a żółte biuro nadal otrzymuje NXDOMAIN. To nie awaria VPN ani zepsuty resolver; to luka własności w prywatnej strefie. Dwie niezależnie edytowane listy rekordów nie stają się jedną strefą tylko dlatego, że lokalizacje mogą się nawzajem osiągnąć. Rozwiązaniem jest plan publikacji, nie kolejna reguła zapory.

Objaw wskazuje brakującego właściciela

Każda lokalizacja ma prawdopodobnie lokalne nadpisanie, wpis Pi-hole lub wiersz dnsmasq dodany przez kogoś, gdy potrzebna była nazwa. Zielony rekord istnieje tylko na zielonym resolverze, więc klient w żółtej lokalizacji pyta swój resolver i otrzymuje prawdziwe "nie ma takiej nazwy". Nieaktualna odpowiedź wygląda inaczej: host się przeniósł, jedna lokalizacja zaktualizowała swoją kopię, a druga nadal zwraca stary adres.

Żaden z tych wzorców nie naprawia się na długo przez wyczyszczenie pamięci podręcznej. Pamięć podręczna resolvera przekazującego jest kopią odpowiedzi, którą kiedyś otrzymał, a nie autorytetem publikującym nowe nazwy, więc pamięć, która działa dziś, nic nie mówi o hoście jutra. Dokumentacja BIND opisuje role podstawową, dodatkową, rekurencyjną i przekazywania osobno właśnie z tego powodu.

Zatem pytanie projektowe jest wąskie i ma odpowiedź: kto może utworzyć rekord i jak ten rekord dociera do każdego resolvera, który musi na niego odpowiadać?

Opcja A: jedna strefa autorytatywna z serwerami dodatkowymi

Uruchom serwer podstawowy dla internal.example.com i pozwól obsługiwanym serwerom dodatkowym pobrać strefę w każdej lokalizacji. Rekurencyjny resolver każdej lokalizacji pyta swój lokalny serwer dodatkowy, więc odpowiedzi pochodzą z autorytatywnego źródła, a nie z pamięci podręcznej, a zmiana wykonana raz jest przenoszona, a nie wpisywana ponownie.

Taki układ wymaga wyraźnych decyzji, które łatwo odłożyć i drogo pominąć. Kto może edytować strefę? Które serwery mogą ją przenosić i przez jakie adresy? Co mają widzieć klienci, gdy tunel między lokalizacjami jest wyłączony? Serwer dodatkowy nadal odpowiada ze swojej ostatniej kopii, co zwykle jest pożądanym zachowaniem, ale musi to być wybór zadeklarowany, a nie niespodzianka podczas awarii.

Ogranicz transfery strefy do znanych serwerów dodatkowych według adresu i używaj podpisów transakcji tam, gdzie implementacja je obsługuje. Otwarty transfer to kopia wewnętrznej przestrzeni nazw dla każdego, kto dotrze do portu.

Kosztem jest koordynacja: jedna ścieżka edycji, jeden przegląd zmian i wspólne zrozumienie, kto jest na dyżurze, gdy rekord jest błędny.

Opcja B: subdomena dla każdej lokalizacji

Deleguj green.internal.example.com do zielonej lokalizacji, a yellow.internal.example.com do żółtej. Każda lokalizacja staje się autorytatywna dla swoich nazw, a strefa nadrzędna niesie tylko rekordy delegacji. Spór o jeden plik znika, a lokalny zespół może dodać host bez czekania na zmianę centralną.

Delegacja musi istnieć w strefie nadrzędnej, z rekordami NS wskazującymi na serwery autorytatywne lokalizacji. Przekazywanie warunkowe dla subdomeny jest ważną alternatywą, gdy pełna delegacja jest niepraktyczna, ale to ustawienie resolvera, a nie opublikowany fakt, więc każdy resolver potrzebuje tej samej reguły.

Koszt przesuwa się zamiast znikać: strefa nadrzędna nadal potrzebuje właściciela, a utworzenie nowej lokalizacji jest teraz zmianą w dwóch miejscach zamiast w jednym.

Niech każdy resolver podąża za wyborem

Przekaż klientom zatwierdzony resolver i domenę wyszukiwania przez ich obsługiwaną konfigurację i upewnij się, że resolver ma dozwoloną trasę VPN do każdego zdalnego serwera DNS, o który musi pytać. Aplikacje potrzebują też tras do prywatnych adresów zwracanych przez te odpowiedzi, bo poprawna nazwa bez ścieżki to nadal zerwane połączenie.

Jeśli Pi-hole zapewnia lokalne rozwiązywanie, zapisz, które rekordy posiada i które zapytania przekazuje. Dwie niezależnie edytowane listy Pi-hole nadal się nie replikują. W Pi-hole v6 niestandardowe wiersze dnsmasq ustawia się przez opcje po stronie hosta, takie jak TOML, CLI lub zmienne środowiskowe, i nie są udostępniane przez API; ładowanie plików z /etc/dnsmasq.d/ to osobna opcja, domyślnie wyłączona.

Następnie przetestuj z obu stron nazwą, która powinna być widoczna wszędzie:

$ 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

Odpowiedź SOA mówi, czy żółty resolver uważa się za autorytatywny, pyta serwer dodatkowy, czy tylko przekazuje. To różne projekty z różnymi trybami awarii, a odpowiedź zwykle wskazuje, który faktycznie wdrożono.

Zakończ trzema przypadkami akceptacji: jedna nazwa z każdej lokalizacji, jeden rekord zmieniony w ciągu godziny i niedostępne połączenie między lokalizacjami. Projekt, który przechodzi tylko pierwszy, ma plan publikacji na papierze i lokalne nadpisanie w produkcji.