BIND přes VPN: podmíněné předávání, nebo stub zóna?

Váš kancelářský resolver odpovídá na všechno kromě jednoho firemního jmenného prostoru a firemní DNS server, který ho zná, je za VPN. BIND může tuto jedinou zónu předat upstreamu třemi různými způsoby a každý selhává jinak. Podmíněné předávání je nejmenší závazek, stub zóna uchovává data o delegaci a secondary uchovává úplnou kopii. Vybírejte podle toho, co upstream dovolí a co má váš resolver uchovávat, ne podle toho, který úryvek jste našli první.

Tři uspořádání pro jeden jmenný prostor

Podmíněné předávání: nejmenší závazek

Předpokládejte kancelářský resolver na 192.168.10.53 a firemní server na 10.40.0.53 dostupný přes schválený tunel. Deklarace má tři řádky a ten zajímavý je forward only, protože mění chování při selhání, ne cestu.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

S forward only nedostupný upstream vrátí pro tuto zónu SERVFAIL místo návratu k iterativnímu řešení. To je obvykle to, co u privátního jmenného prostoru chcete, protože návrat by poslal privátní názvy veřejnému resolveru a vrátil by neužitečnou odpověď z internetu. Referenční dokumentace BIND popisuje obě politiky a rozdíl je důležitější, než úryvek naznačuje. Přidejte zónu do stávající konfigurace, místo abyste nahrazovali zónu, která pro stejný název už existuje.

Stub nebo secondary: kdy záleží na delegaci

Stub zóna se firemního serveru ptá na NS záznamy zóny a pak se přímo ptá autoritativních serverů. Zvolte ji, když je oblast upstreamu velká nebo rozdělená a chcete, aby váš resolver sledoval delegaci, místo aby vše připevnil k jedné adrese. Cenou je závislost na aktuálnosti NS dat a na tom, že každý uvedený jmenný server je dostupný ze zdrojové adresy vašeho resolveru.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary odpovídá z lokálních dat a přežije výpadek upstreamu, a to je důvod, proč přijmout závislost na transferu. Znamená to také, že váš resolver nyní drží kopii zóny, kterou nevlastní, takže cesta k souboru, ACL transferu na primárním serveru a časovače obnovy se stávají součástí vaší provozní plochy.

Kontrola, která rozhodne mezi nimi

BIND generuje vlastní odchozí dotaz, takže otázka není, zda se notebook dostane na 10.40.0.53, ale zda to zvládne hostitel resolveru, a to ze zdrojové adresy, kterou firemní server uvidí. Zeptejte se jádra, pak se zeptejte serveru, v tomto pořadí.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Povolte na cestě UDP i TCP: zkrácená odpověď vynutí TCP a politika, která povoluje jen UDP, způsobuje občasná selhání, která vypadají jako ztráta paketů. Firemní strana potřebuje jak pravidlo pro přijetí zdroje vašeho resolveru, tak zpětnou trasu k němu; tím zdrojem může být směrovaná adresa resolveru nebo explicitně přeložená adresa a jen zřídka to je adresa z klientského poolu. Pokud dotaz NS selže, stub zóna nemůže fungovat, ať se forward zóna chová jakkoli.

Ověřte odpověď, ne tunel

Dotážete se přes kancelářský resolver na název, na který jste se nikdy neptali, a podívejte se do sekce authority odpovědi, zda přišla z firemní zóny. Odpověď z cache nic o současné cestě nedokazuje a úspěšný přímý dotaz na upstream nedokazuje, že váš resolver tuto zónu vybral. Zopakujte stejný dotaz přes TCP, abyste potvrdili, že cesta přežije zkrácení.

Držte klienty nasměrované na kancelářský resolver, a nechte zapnutou validaci DNSSEC. Prohlížeč nastavený s nezávislým šifrovaným resolverem toto uspořádání úplně obejde a vypnutí validace, aby neočekávaná odpověď vypadala správně, vymění viditelné selhání za neviditelné.

Zapište, který ze tří typů jste zvolili a proč. Další člověk, který uvidí zónu selhávat, bude tu větu potřebovat víc než konfigurační soubor.