BIND preko VPN-a: uslovno prosljeđivanje ili stub zona?

Vaš uredski resolver odgovara na sve osim na jedan korporativni prostor imena, a korporativni DNS server koji ga poznaje nalazi se iza VPN-a. BIND može taj jedini prostor imena predati upstream-u na tri različita načina, i oni padaju na različit način. Uslovno prosljeđivanje je najmanja obaveza, stub zona čuva podatke o delegaciji, a secondary čuva potpunu kopiju. Birajte prema tome šta će upstream dozvoliti i šta želite da vaš resolver čuva, a ne prema tome koji ste isječak prvi pronašli.

Tri rasporeda za jedan prostor imena

Uslovno prosljeđivanje: najmanja obaveza

Pretpostavite uredski resolver na 192.168.10.53 i korporativni server na 10.40.0.53 dostupan kroz odobreni tunel. Deklaracija je tri reda, a zanimljiv je forward only, jer mijenja ponašanje pri kvaru, a ne putanju.

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

Sa forward only nedostupan upstream daje SERVFAIL za ovu zonu umjesto povratka na iterativno rješavanje. To je obično ono što želite za privatni prostor imena, jer bi povratak poslao privatna imena javnom resolveru i vratio beskoristan odgovor s interneta. BIND referenca dokumentuje obje politike, a razlika je važnija nego što isječak sugeriše. Spojite zonu s postojećom konfiguracijom umjesto da zamijenite zonu koja već postoji za isto ime.

Stub ili secondary: kada je delegacija važna

Stub zona pita korporativni server za NS zapise zone, a zatim direktno pita autoritativne servere. Birajte je kada je upstream regija velika ili podijeljena i želite da vaš resolver prati delegaciju umjesto da sve prikuca na jednu adresu. Cijena je zavisnost od ažurnosti NS podataka i od dostupnosti svakog navedenog imenskog servera s izvorišne adrese vašeg resolvera.

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 odgovara iz lokalnih podataka i preživljava ispad upstream-a, i to je razlog da prihvatite zavisnost od transfera. To takođe znači da vaš resolver sada čuva kopiju zone koju ne posjeduje, pa putanja do datoteke, ACL za transfer na primarnom serveru i tajmeri osvježavanja postaju dio vaše operativne površine.

Provjera koja odlučuje između njih

BIND generiše vlastiti odlazni upit, pa pitanje nije može li laptop doći do 10.40.0.53, nego može li to host resolvera, s izvorišne adrese koju će korporativni server vidjeti. Pitajte kernel, pa pitajte server, tim redom.

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

Dozvolite UDP i TCP na putu: skraćen odgovor prisiljava TCP, a politika koja dozvoljava samo UDP proizvodi povremene kvarove koji izgledaju kao gubitak paketa. Korporativna strana treba i pravilo prihvatanja za izvor vašeg resolvera i povratnu rutu do njega; taj izvor može biti rutirana adresa resolvera ili izričito prevedena, a rijetko je adresa klijentskog pula. Ako NS upit ne uspije, stub zona ne može raditi bez obzira na to kako se forward zona ponaša.

Provjerite odgovor, ne tunel

Upitajte preko uredskog resolvera ime koje nikada niste tražili i pregledajte authority odjeljak odgovora da vidite dolazi li iz korporativne zone. Keširan odgovor ne dokazuje ništa o trenutnoj putanji, a uspješan direktan upit upstream-u ne dokazuje da je vaš resolver odabrao tu zonu. Ponovite isti upit preko TCP-a da potvrdite da putanja preživljava skraćivanje.

Držite klijente usmjerene na uredski resolver, i držite DNSSEC validaciju uključenom. Preglednik konfigurisan s nezavisnim šifriranim resolverom potpuno zaobilazi ovaj raspored, a isključivanje validacije da bi neočekivan odgovor izgledao ispravan mijenja vidljiv kvar za nevidljiv.

Zapišite koji ste od tri tipa odabrali i zašto. Sljedećoj osobi koja vidi da zona pada ta rečenica će trebati više od konfiguracijske datoteke.