BIND över ett VPN: betingad vidarebefordran eller stub-zon?

Din kontorsresolver svarar på allt utom en företagsnamnrymd, och företagets DNS-server som känner till den står bakom ett VPN. BIND kan lämna över den enda zonen till upstream på tre olika sätt, och de misslyckas olika. Betingad vidarebefordran är det minsta åtagandet, en stub-zon behåller delegeringsdata, och en secondary behåller en fullständig kopia. Välj efter vad upstream tillåter och vad du vill att din resolver ska hålla, inte efter vilket utdrag du hittade först.

Tre upplägg för en namnrymd

Betingad vidarebefordran: det minsta åtagandet

Anta en kontorsresolver på 192.168.10.53 och en företagsserver på 10.40.0.53 som nås via en godkänd tunnel. Deklarationen är tre rader, och den intressanta är forward only, eftersom den ändrar felbeteendet, inte vägen.

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

Med forward only ger en onåbar upstream SERVFAIL för den här zonen i stället för att falla tillbaka till iterativ uppslagning. Det är oftast det du vill ha för en privat namnrymd, eftersom återfallet skulle skicka privata namn till en publik resolver och returnera ett oanvändbart svar från internet. BIND-referensen dokumenterar båda policyerna, och skillnaden spelar större roll än utdraget antyder. Infoga zonen i den befintliga konfigurationen i stället för att ersätta en zon som redan finns för samma namn.

Stub eller secondary: när delegeringen spelar roll

En stub-zon frågar företagsservern efter zonens NS-poster och frågar sedan de auktoritativa servrarna direkt. Välj den när upstream-regionen är stor eller uppdelad och du vill att din resolver ska följa delegeringen i stället för att fästa allt vid en adress. Priset är ett beroende av att NS-data är aktuella, och av att varje listad namnserver nås från din resolvers källadress.

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 svarar från lokala data och överlever ett upstream-avbrott, och det är skälet att acceptera överföringsberoendet. Det betyder också att din resolver nu håller en kopia av en zon som den inte äger, så filsökvägen, överförings-ACL:en på primären och uppdateringstimmarna blir alla en del av din driftvy.

Kontrollen som avgör mellan dem

BIND genererar sin egen utgående fråga, så frågan är inte om en laptop kan nå 10.40.0.53 utan om resolvervärden kan, från den källadress som företagsservern ser. Fråga kärnan och sedan servern, i den ordningen.

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

Tillåt UDP och TCP på vägen: ett trunkerat svar tvingar TCP, och en policy som bara tillåter UDP ger periodiska fel som ser ut som paketförlust. Företagssidan behöver både en acceptregel för din resolvers källa och en returväg till den; den källan kan vara resolverns routade adress eller en uttryckligen översatt adress, och det är sällan en adress ur en klientpool. Om NS-frågan misslyckas kan en stub-zon inte fungera, oavsett hur forward-zonen beter sig.

Verifiera svaret, inte tunneln

Fråga genom kontorsresolvern efter ett namn du aldrig har frågat om, och titta på svarets authority-avsnitt för att se om det kom från företagszonen. Ett cachat svar bevisar ingenting om den aktuella vägen, och en lyckad direkt fråga till upstream bevisar inte att din resolver valde den zonen. Upprepa samma fråga över TCP för att bekräfta att vägen tål trunkering.

Håll klienterna riktade mot kontorsresolvern, och håll DNSSEC-valideringen på. En webbläsare konfigurerad med en oberoende krypterad resolver kringgår detta upplägg helt, och att stänga av validering för att ett oväntat svar ska se korrekt ut byter ett synligt fel mot ett osynligt.

Skriv ned vilken av de tre typerna du valde och varför. Nästa person som ser zonen misslyckas behöver den meningen mer än konfigurationsfilen.