BIND over ein VPN: vilkårsstyrt videresending eller stub-sone?

Kontorresolveren din svarar på alt unntatt eitt verksemdsnamnerom, og verksemds-DNS-tenaren som kjenner det, står bak ein VPN. BIND kan overlevere den eine sona til upstream på tre ulike måtar, og dei feilar ulikt. Vilkårsstyrt videresending er den minste forpliktinga, ei stub-sone held på delegasjonsdataa, og ein secondary held på ein full kopi. Vel etter kva upstream vil tillate og kva du vil at resolveren skal halde på, ikkje etter kva utdrag du fann først.

Tre ordningar for eitt namnerom

Vilkårsstyrt videresending: den minste forpliktinga

Tenk deg ein kontorresolver på 192.168.10.53 og ein verksemdstenar på 10.40.0.53 som er tilgjengeleg gjennom ein godkjend tunnel. Deklarasjonen er tre linjer, og den interessante er forward only, fordi han endrar korleis feil blir handsama, ikkje ruta.

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

Med forward only gir ein utilgjengeleg upstream SERVFAIL for denne sona i staden for å falle tilbake til iterativ oppslag. Det er vanlegvis det du vil ha for eit privat namnerom, fordi tilbakefallet ville sendt private namn til ein offentleg resolver og returnert eit ubrukeleg svar frå internett. BIND-referansen dokumenterer begge retningslinjene, og skilnaden betyr meir enn utdraget antydar. Flett sona inn i den eksisterande konfigurasjonen i staden for å erstatta ei sone som allereie finst for same namn.

Stub eller secondary: når delegasjonen betyr noko

Ei stub-sone spør verksemdstenaren om NS-postane til sona og spør deretter dei autoritative tenarane direkte. Vel henne når upstream-området er stort eller delt, og du vil at resolveren skal følgje delegasjonen i staden for å feste alt til éin adresse. Prisen er ei avhenging av at NS-dataa er oppdaterte, og av at kvar oppførte namnetenar er tilgjengeleg frå kjeldeadressa til resolveren.

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

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

Ein secondary svarar frå lokale data og overlever eit upstream-utfall, og det er grunnen til å godta overføringsavhenginga. Det betyr òg at resolveren no held på ein kopi av ei sone han ikkje eig, slik at filstigen, overførings-ACL-en på primæren og oppdateringstimarane alle blir ein del av driftsflata di.

Sjekken som avgjer mellom dei

BIND genererer si eiga utgåande spørjing, så spørsmålet er ikkje om ein laptop kan nå 10.40.0.53, men om resolververten kan, frå kjeldeadressa verksemdstenaren vil sjå. Spør kjernen, spør deretter tenaren, i den rekkjefølgja.

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

Tillat UDP og TCP på ruta: eit avkorta svar tvingar TCP, og ein policy som berre tillèt UDP gir periodiske feil som ser ut som pakketap. Verksemdssida treng både ein akseptregel for kjelda til resolveren og ei returrute dit; den kjelda kan vere den ruta adressa til resolveren eller ei eksplisitt omsett ei, og det er sjeldan ei klientbassengadresse. Viss NS-spørjinga feilar, kan ei stub-sone ikkje verke, same korleis forward-sona oppfører seg.

Stadfest svaret, ikkje tunnelen

Spør gjennom kontorresolveren etter eit namn du aldri har spurt om, og sjå på authority-delen av svaret for å avgjere om det kom frå verksemdssona. Eit svart i mellomlager beviser ingenting om den noverande ruta, og ei vellukka direkte spørjing til upstream beviser ikkje at resolveren valde den sona. Gjenta den same spørjinga over TCP for å stadfeste at ruta toler avkorting.

Hald klientane retta mot kontorresolveren, og hald DNSSEC-validering på. Ein nettlesar sett opp med ein uavhengig kryptert resolver går heilt utanom denne ordninga, og å slå av validering for at eit uventa svar skal sjå rett ut byter ein synleg feil mot ein usynleg.

Skriv ned kva av dei tre typane du valde og kvifor. Den neste som ser sona feile, treng den setninga meir enn konfigurasjonsfila.