BIND čez VPN: pogojno posredovanje ali stub cona?

Vaš pisarniški resolver odgovori na vse razen na en imenski prostor podjetja, in strežnik DNS podjetja, ki ga pozna, stoji za VPN. BIND lahko to eno cono izroči upstreamu na tri različne načine, in vsak odpove drugače. Pogojno posredovanje je najmanjša obveznost, stub cona ohrani podatke o delegaciji, secondary pa ohrani popolno kopijo. Izberite po tem, kaj bo upstream dovolil in kaj želite, da vaš resolver hrani, ne po tem, kateri odlomek ste našli prvi.

Tri ureditve za en imenski prostor

Pogojno posredovanje: najmanjša obveznost

Predpostavite pisarniški resolver na 192.168.10.53 in strežnik podjetja na 10.40.0.53, dosegljiv skozi odobren tunel. Izjava je treh vrstic, in zanimiva je forward only, ker spremeni vedenje ob napaki, ne poti.

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

Z forward only nedosegljiv upstream za to cono vrne SERVFAIL namesto vrnitve k iterativnemu reševanju. To običajno želite za zasebni imenski prostor, ker bi vrnitev poslala zasebna imena javnemu resolverju in prinesla neuporaben odgovor iz interneta. Referenca BIND opisuje obe politiki, in razlika je pomembnejša, kot nakazuje odlomek. Cono vključite v obstoječo konfiguracijo, namesto da zamenjate cono, ki za isto ime že obstaja.

Stub ali secondary: ko je delegacija pomembna

Stub cona strežnik podjetja vpraša za zapise NS cone in nato neposredno vpraša pooblaščene strežnike. Izberite jo, ko je območje upstreama veliko ali razdeljeno in želite, da vaš resolver sledi delegaciji, namesto da vse pripne na en naslov. Cena je odvisnost od ažurnosti podatkov NS in od dosegljivosti vsakega navedenega imenskega strežnika z izvornega naslova vašega resolverja.

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 odgovori iz lokalnih podatkov in preživi izpad upstreama, in zato se splača sprejeti odvisnost od prenosa. To pomeni tudi, da vaš resolver zdaj hrani kopijo cone, ki ni njegova, zato pot datoteke, ACL prenosa na primarnem strežniku in časovniki osvežitve postanejo del vaše operativne površine.

Preverjanje, ki odloči med njima

BIND sam ustvari svojo odhodno poizvedbo, zato vprašanje ni, ali prenosnik doseže 10.40.0.53, ampak ali gostitelj resolverja doseže, z izvornega naslova, ki ga bo videl strežnik podjetja. Vprašajte jedro, nato vprašajte strežnik, v tem vrstnem redu.

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

Na poti dovolite UDP in TCP: skrajšan odgovor prisili TCP, politika, ki dovoli samo UDP, pa povzroči občasne napake, ki izgledajo kot izguba paketov. Stran podjetja potrebuje tako pravilo sprejemanja za izvor vašega resolverja kot povratno pot do njega; ta izvor je lahko usmerjeni naslov resolverja ali izrecno prevedeni naslov, in le redko je naslov iz odjemalskega bazena. Če poizvedba NS ne uspe, stub cona ne more delovati, ne glede na vedenje cone forward.

Preverite odgovor, ne tunela

Prek pisarniškega resolverja vprašajte za ime, ki ga še nikoli niste zahtevali, in poglejte razdelek authority odgovora, ali prihaja iz cone podjetja. Odgovor iz predpomnilnika ne dokaže ničesar o trenutni poti, uspešna neposredna poizvedba na upstream pa ne dokaže, da je vaš resolver izbral to cono. Ponovite isto poizvedbo po TCP, da potrdite, da pot preživi skrajšanje.

Ohranite odjemalce usmerjene na pisarniški resolver, in pustite preverjanje DNSSEC vključeno. Brskalnik, nastavljen z neodvisnim šifriranim resolverjem, to ureditev popolnoma obide, izklop preverjanja, da bi nepričakovan odgovor izgledal pravilen, pa zamenja vidno napako za nevidno.

Zapišite, katero od treh vrst ste izbrali in zakaj. Naslednja oseba, ki bo videla cono odpovedati, bo ta stavek potrebovala bolj kot konfiguracijsko datoteko.