BIND cez VPN: podmienené preposielanie alebo stub zóna?

Váš kancelársky resolver odpovedá na všetko okrem jedného firemného menného priestoru a firemný DNS server, ktorý ho pozná, je za VPN. BIND môže túto jedinú zónu odovzdať upstreamu tromi rôznymi spôsobmi a každý zlyháva inak. Podmienené preposielanie je najmenší záväzok, stub zóna uchováva údaje o delegácii a secondary uchováva úplnú kópiu. Vyberajte podľa toho, čo upstream dovolí a čo chcete, aby váš resolver uchovával, nie podľa toho, ktorý úryvok ste našli prvý.

Tri usporiadania pre jeden menný priestor

Podmienené preposielanie: najmenší záväzok

Predpokladajme kancelársky resolver na 192.168.10.53 a firemný server na 10.40.0.53 dostupný cez schválený tunel. Deklarácia má tri riadky a tá zaujímavá je forward only, pretože mení správanie pri zlyhaní, nie cestu.

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

S forward only nedostupný upstream vráti pre túto zónu SERVFAIL namiesto návratu k iteratívnemu riešeniu. To je zvyčajne to, čo pri privátnom mennom priestore chcete, pretože návrat by poslal privátne mená verejnému resolveru a vrátil by neužitočnú odpoveď z internetu. Referenčná dokumentácia BIND opisuje obe politiky a rozdiel je dôležitejší, než úryvok naznačuje. Pridajte zónu do existujúcej konfigurácie namiesto nahrádzania zóny, ktorá pre rovnaký názov už existuje.

Stub alebo secondary: keď záleží na delegácii

Stub zóna sa firemného servera pýta na NS záznamy zóny a potom sa priamo pýta autoritatívnych serverov. Zvoľte ju, keď je oblasť upstreamu veľká alebo rozdelená a chcete, aby váš resolver nasledoval delegáciu namiesto pripínania všetkého na jednu adresu. Cenou je závislosť od aktuálnosti NS údajov a od toho, že každý uvedený menný server je dostupný zo zdrojovej adresy vášho 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 odpovedá z lokálnych údajov a prežije výpadok upstreamu, a to je dôvod prijať závislosť od transferu. Znamená to tiež, že váš resolver teraz drží kópiu zóny, ktorú nevlastní, takže cesta k súboru, ACL transferu na primárnom serveri a časovače obnovy sa stávajú súčasťou vašej prevádzkovej plochy.

Kontrola, ktorá rozhodne medzi nimi

BIND generuje vlastnú odchádzajúcu požiadavku, takže otázka nie je, či sa notebook dostane na 10.40.0.53, ale či to zvládne hostiteľ resolveru, a to zo zdrojovej adresy, ktorú firemný server uvidí. Opýtajte sa jadra, potom sa opýtajte servera, v tomto poradí.

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

Povoľte na ceste UDP aj TCP: skrátená odpoveď vynúti TCP a politika, ktorá povoľuje len UDP, spôsobuje občasné zlyhania, ktoré vyzerajú ako strata paketov. Firemná strana potrebuje aj pravidlo prijatia pre zdroj vášho resolveru, aj spätnú trasu k nemu; tým zdrojom môže byť smerovaná adresa resolveru alebo explicitne preložená adresa a len zriedka je to adresa z klientskeho poolu. Ak požiadavka NS zlyhá, stub zóna nemôže fungovať, nech sa forward zóna správa akokoľvek.

Overte odpoveď, nie tunel

Opýtajte sa cez kancelársky resolver na názov, na ktorý ste sa nikdy nepýtali, a pozrite sa do sekcie authority odpovede, či prišla z firemnej zóny. Odpoveď z cache nič nedokazuje o aktuálnej ceste a úspešná priama požiadavka na upstream nedokazuje, že váš resolver túto zónu vybral. Zopakujte tú istú požiadavku cez TCP, aby ste potvrdili, že cesta prežije skrátenie.

Držte klientov nasmerovaných na kancelársky resolver, a nechajte zapnutú validáciu DNSSEC. Prehliadač nastavený s nezávislým šifrovaným resolverom toto usporiadanie úplne obíde a vypnutie validácie, aby neočakávaná odpoveď vyzerala správne, vymení viditeľné zlyhanie za neviditeľné.

Zapíšte, ktorý z troch typov ste zvolili a prečo. Ďalší človek, ktorý uvidí zónu zlyhávať, bude tú vetu potrebovať viac než konfiguračný súbor.