BIND printr-un VPN: redirecționare condiționată sau zonă stub?

Resolverul biroului tău răspunde la tot, cu excepția unui spațiu de nume corporate, iar serverul DNS corporate care îl cunoaște stă în spatele unui VPN. BIND poate preda acea singură zonă upstreamului în trei moduri diferite, și ele eșuează diferit. Redirecționarea condiționată este cel mai mic angajament, o zonă stub păstrează datele de delegare, iar un secondary păstrează o copie completă. Alege după ce va permite upstreamul și după ce vrei ca resolverul tău să păstreze, nu după fragmentul pe care l-ai găsit primul.

Trei aranjamente pentru un spațiu de nume

Redirecționare condiționată: cel mai mic angajament

Presupune un resolver de birou la 192.168.10.53 și un server corporate la 10.40.0.53 accesibil printr-un tunel aprobat. Declarația are trei linii, iar cea interesantă este forward only, pentru că schimbă comportamentul la eșec, nu calea.

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

Cu forward only, un upstream inaccesibil produce un SERVFAIL pentru această zonă în loc să revină la rezolvarea iterativă. De obicei asta vrei pentru un spațiu de nume privat, pentru că revenirea ar trimite nume private către un resolver public și ar aduce un răspuns inutil din internet. Referința BIND documentează ambele politici, iar diferența contează mai mult decât sugerează fragmentul. Integrează zona în configurația existentă în loc să înlocuiești o zonă care există deja pentru același nume.

Stub sau secondary: când delegarea contează

O zonă stub cere serverului corporate înregistrările NS ale zonei și apoi interoghează direct serverele autoritative. Alege-o când regiunea upstream este mare sau subdivizată și vrei ca resolverul tău să urmeze delegarea în loc să fixeze totul pe o singură adresă. Costul este dependența de actualitatea datelor NS și de faptul că fiecare server de nume listat este accesibil de la adresa sursă a resolverului tău.

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

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

Un secondary răspunde din date locale și supraviețuiește unei căderi a upstreamului, iar acesta este motivul pentru a accepta dependența de transfer. Înseamnă și că resolverul tău păstrează acum o copie a unei zone pe care nu o deține, astfel încât calea fișierului, ACL-ul de transfer de pe primar și temporizatoarele de reîmprospătare devin toate parte din suprafața ta operațională.

Verificarea care decide între ele

BIND își generează propria interogare ieșită, deci întrebarea nu este dacă un laptop poate ajunge la 10.40.0.53, ci dacă gazda resolverului poate, de la adresa sursă pe care serverul corporate o va vedea. Întreabă kernelul, apoi întreabă serverul, în această ordine.

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

Permite UDP și TCP pe cale: un răspuns trunchiat forțează TCP, iar o politică ce permite doar UDP produce eșecuri intermitente care arată ca pierdere de pachete. Partea corporate are nevoie atât de o regulă de acceptare pentru sursa resolverului tău, cât și de o rută de întoarcere către ea; acea sursă poate fi adresa rutată a resolverului sau una tradusă explicit, și rareori este o adresă dintr-un pool de clienți. Dacă interogarea NS eșuează, o zonă stub nu poate funcționa, indiferent cum se comportă zona forward.

Verifică răspunsul, nu tunelul

Interoghează prin resolverul biroului un nume pe care nu l-ai cerut niciodată și uită-te la secțiunea authority a răspunsului pentru a vedea dacă vine din zona corporate. Un răspuns din cache nu dovedește nimic despre calea actuală, iar o interogare directă reușită către upstream nu dovedește că resolverul tău a ales acea zonă. Repetă aceeași interogare prin TCP pentru a confirma că calea supraviețuiește trunchierii.

Ține clienții îndreptați spre resolverul biroului, și ține validarea DNSSEC activată. Un browser configurat cu un resolver criptat independent ocolește complet acest aranjament, iar dezactivarea validării pentru ca un răspuns neașteptat să pară corect schimbă un eșec vizibil cu unul invizibil.

Notează care dintre cele trei tipuri l-ai ales și de ce. Următoarea persoană care va vedea zona eșuând va avea nevoie de acea propoziție mai mult decât de fișierul de configurare.