Din kontor-resolver svarer på alt undtagen ét virksomheds-navnerum, og den virksomheds-DNS-server, der kender det, ligger bag en VPN. BIND kan overdrage den ene zone til upstream på tre forskellige måder, og de fejler forskelligt. Betinget videresendelse er den mindste forpligtelse, en stub-zone beholder delegationdataene, og en secondary beholder en fuld kopi. Vælg efter hvad upstream vil tillade, og hvad du vil have din resolver til at holde, ikke efter hvilket uddrag du fandt først.

Tre ordninger for ét navnerum

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Betinget videresendelse: den mindste forpligtelse

Antag en kontor-resolver på 192.168.10.53 og en virksomhedsserver på 10.40.0.53, der kan nås gennem en godkendt tunnel. Deklarationen er tre linjer, og den interessante er forward only, fordi den ændrer fejlopførslen, ikke ruten.

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

Med forward only giver en utilgængelig upstream SERVFAIL for denne zone i stedet for at falde tilbage til iterativ opløsning. Det er normalt det, du vil have for et privat navnerum, fordi tilbagefaldet ville sende private navne til en offentlig resolver og returnere et ubrugeligt svar fra internettet. BIND-referencen dokumenterer begge politikker, og forskellen betyder mere, end uddraget antyder. Flet zonen ind i den eksisterende konfiguration i stedet for at erstatte en zone, der allerede findes for samme navn.

Stub eller secondary: når delegationen betyder noget

En stub-zone spørger virksomhedsserveren om zonens NS-poster og forespørger derefter de autoritative servere direkte. Vælg den, når upstream-området er stort eller opdelt, og du vil have din resolver til at følge delegationen i stedet for at fastgøre alt til én adresse. Prisen er en afhængighed af, at NS-dataene er aktuelle, og af at hver angivet navneserver kan nås fra din resolvers 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 ud fra lokale data og overlever et upstream-udfald, og det er grunden til at acceptere transfer-afhængigheden. Det betyder også, at din resolver nu holder en kopi af en zone, den ikke ejer, så filstien, transfer-ACL'en på primæren og opdateringstimerne bliver alle en del af din driftsflade.

Det tjek, der afgør valget

BIND genererer sin egen udgående forespørgsel, så spørgsmålet er ikke, om en laptop kan nå 10.40.0.53, men om resolver-værten kan, fra den kildeadresse som virksomhedsserveren vil se. Spørg kernen, spørg derefter serveren, i den rækkefølge.

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

Tillad UDP og TCP på ruten: et afkortet svar tvinger TCP, og en politik, der kun tillader UDP, giver periodiske fejl, der ligner pakketab. Virksomhedssiden har både brug for en accept-regel for din resolvers kilde og en returrute til den; den kilde kan være resolverens rutede adresse eller en eksplicit oversat en, og det er sjældent en klientpulje-adresse. Hvis NS-forespørgslen fejler, kan en stub-zone ikke virke, uanset hvordan forward-zonen opfører sig.

Verificér svaret, ikke tunnelen

Forespørg gennem kontor-resolveren på et navn, du aldrig har spurgt om, og se på svarets authority-sektion for at afgøre, om det kom fra virksomhedszonen. Et cachelagret svar beviser intet om den aktuelle rute, og en vellykket direkte forespørgsel til upstream beviser ikke, at din resolver valgte den zone. Gentag den samme forespørgsel over TCP for at bekræfte, at ruten overlever afkortning.

Hold klienterne rettet mod kontor-resolveren, og hold DNSSEC-validering slået til. En browser konfigureret med en uafhængig krypteret resolver omgår denne ordning helt, og at slå validering fra for at få et uventet svar til at se korrekt ud bytter en synlig fejl for en usynlig.

Skriv ned, hvilken af de tre typer du valgte, og hvorfor. Den næste person, der ser zonen fejle, får mere brug for den sætning end for konfigurationsfilen.

Relaterede artikler