BIND over en VPN: betinget videresending eller stub-sone?

Kontorresolveren din svarer på alt unntatt ett bedriftsnavnerom, og bedrifts-DNS-serveren som kjenner det, står bak en VPN. BIND kan overlevere den ene sonen til upstream på tre ulike måter, og de feiler ulikt. Betinget videresending er den minste forpliktelsen, en stub-sone beholder delegasjonsdataene, og en secondary beholder en full kopi. Velg etter hva upstream vil tillate og hva du vil at resolveren skal holde, ikke etter hvilket utdrag du fant først.

Tre ordninger for ett navnerom

Betinget videresending: den minste forpliktelsen

Anta en kontorresolver på 192.168.10.53 og en bedriftsserver på 10.40.0.53 som er tilgjengelig gjennom en godkjent tunnel. Deklarasjonen er tre linjer, og den interessante er forward only, fordi den endrer feilatferden, ikke ruten.

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

Med forward only gir en utilgjengelig upstream SERVFAIL for denne sonen i stedet for å falle tilbake til iterativ oppslag. Det er vanligvis det du vil ha for et privat navnerom, fordi tilbakefallet ville sende private navn til en offentlig resolver og returnere et ubrukelig svar fra internett. BIND-referansen dokumenterer begge retningslinjene, og forskjellen betyr mer enn utdraget antyder. Flett sonen inn i den eksisterende konfigurasjonen i stedet for å erstatte en sone som allerede finnes for samme navn.

Stub eller secondary: når delegasjonen betyr noe

En stub-sone spør bedriftsserveren om sonens NS-poster og spør deretter de autoritative serverne direkte. Velg den når upstream-området er stort eller delt, og du vil at resolveren skal følge delegasjonen i stedet for å feste alt til én adresse. Prisen er en avhengighet av at NS-dataene er oppdaterte, og av at hver oppført navneserver er tilgjengelig fra resolverens kildeadresse.

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

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

En secondary svarer fra lokale data og overlever et upstream-utfall, og det er grunnen til å godta overføringsavhengigheten. Det betyr også at resolveren nå holder en kopi av en sone den ikke eier, slik at filbanen, overførings-ACL-en på primæren og oppdateringstimerne alle blir en del av driftsflaten din.

Sjekken som avgjør mellom dem

BIND genererer sin egen utgående spørring, så spørsmålet er ikke om en laptop kan nå 10.40.0.53, men om resolververten kan, fra kildeadressen bedriftsserveren vil se. Spør kjernen, spør deretter serveren, i den rekkefølgen.

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å ruten: et avkortet svar tvinger TCP, og en policy som bare tillater UDP gir periodiske feil som ser ut som pakketap. Bedriftssiden trenger både en akseptregel for resolverens kilde og en returrute til den; den kilden kan være resolverens rutede adresse eller en eksplisitt oversatt en, og det er sjelden en klientpooladresse. Hvis NS-spørringen feiler, kan en stub-sone ikke virke, uansett hvordan forward-sonen oppfører seg.

Verifiser svaret, ikke tunnelen

Spør gjennom kontorresolveren etter et navn du aldri har spurt om, og se på svarets authority-seksjon for å avgjøre om det kom fra bedriftssonen. Et bufret svar beviser ingenting om den nåværende ruten, og en vellykket direkte spørring til upstream beviser ikke at resolveren valgte den sonen. Gjenta den samme spørringen over TCP for å bekrefte at ruten tåler avkorting.

Hold klientene rettet mot kontorresolveren, og hold DNSSEC-validering på. En nettleser konfigurert med en uavhengig kryptert resolver omgår denne ordningen helt, og å slå av validering for at et uventet svar skal se riktig ut bytter en synlig feil mot en usynlig.

Skriv ned hvilken av de tre typene du valgte og hvorfor. Den neste som ser sonen feile, trenger den setningen mer enn konfigurasjonsfilen.