BIND sobre una VPN: reenviament condicional o zona stub?

El vostre resolver d'oficina respon a tot excepte a un espai de noms corporatiu, i el servidor DNS corporatiu que el coneix és darrere d'una VPN. BIND pot lliurar aquesta única zona a l'upstream de tres maneres diferents, i fallen de manera diferent. El reenviament condicional és el compromís més petit, una zona stub conserva les dades de delegació i una secondary conserva una còpia completa. Trieu segons què permetrà l'upstream i què voleu que conservi el vostre resolver, no segons quin fragment heu trobat primer.

Tres disposicions per a un espai de noms

Reenviament condicional: el compromís més petit

Suposeu un resolver d'oficina a 192.168.10.53 i un servidor corporatiu a 10.40.0.53 accessible per un túnel aprovat. La declaració és de tres línies, i la interessant és forward only, perquè canvia el comportament davant d'una fallada, no el camí.

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

Amb forward only, un upstream inaccessible produeix un SERVFAIL per a aquesta zona en lloc d'una caiguda a la resolució iterativa. Això és el que normalment voleu per a un espai de noms privat, perquè la caiguda enviaria noms privats a un resolver públic i retornaria una resposta inútil d'internet. La referència de BIND documenta totes dues polítiques, i la diferència importa més del que suggereix el fragment. Incorporeu la zona a la configuració existent en lloc de substituir una zona que ja existeix per al mateix nom.

Stub o secondary: quan la delegació importa

Una zona stub demana al servidor corporatiu els registres NS de la zona i després consulta directament els servidors autoritatius. Trieu-la quan la regió de l'upstream és gran o subdividida i voleu que el vostre resolver segueixi la delegació en lloc de fixar-ho tot en una adreça. El cost és una dependència que les dades NS estiguin al dia i que cada servidor de noms llistat sigui accessible des de l'adreça d'origen del vostre resolver.

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

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

Una secondary respon amb dades locals i sobreviu a una caiguda de l'upstream, i aquesta és la raó per acceptar la dependència de la transferència. També significa que el vostre resolver ara guarda una còpia d'una zona que no posseeix, de manera que el camí del fitxer, l'ACL de transferència al primari i els temporitzadors d'actualització passen a formar part de la vostra superfície operativa.

La comprovació que decideix entre elles

BIND genera la seva pròpia consulta de sortida, així que la pregunta no és si un portàtil pot arribar a 10.40.0.53, sinó si ho pot fer l'amfitrió del resolver, des de l'adreça d'origen que veurà el servidor corporatiu. Pregunteu al nucli i després al servidor, en aquest ordre.

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

Permeteu UDP i TCP al camí: una resposta truncada força TCP, i una política que només permet UDP produeix fallades intermitents que semblen pèrdua de paquets. El costat corporatiu necessita tant una regla d'acceptació per a l'origen del vostre resolver com una ruta de tornada cap a ell; aquest origen pot ser l'adreça encaminada del resolver o una de traduïda explícitament, i poques vegades és una adreça d'un pool de clients. Si la consulta NS falla, una zona stub no pot funcionar faci el que faci la zona forward.

Verifiqueu la resposta, no el túnel

Consulteu a través del resolver d'oficina un nom que no hàgiu demanat mai i mireu la secció d'autoritat de la resposta per veure si prové de la zona corporativa. Una resposta en memòria cau no demostra res sobre el camí actual, i una consulta directa amb èxit a l'upstream no demostra que el vostre resolver hagi triat aquesta zona. Repetiu la mateixa consulta per TCP per confirmar que el camí sobreviu al truncament.

Manteniu els clients apuntant al resolver d'oficina, i manteniu la validació DNSSEC activada. Un navegador configurat amb un resolver xifrat independent eludeix completament aquesta disposició, i desactivar la validació perquè una resposta inesperada sembli correcta canvia una fallada visible per una d'invisible.

Anoteu quin dels tres tipus heu triat i per què. La propera persona que vegi la zona fallar necessitarà aquesta frase més que el fitxer de configuració.