BIND Over a VPN: Conditional Forward or Stub Zone?

Your office resolver answers everything except one corporate namespace, and the corporate DNS server that knows it sits behind a VPN. BIND can hand that single zone to the upstream in three different ways, and they fail differently. A conditional forward is the smallest commitment, a stub zone keeps the delegation data, and a secondary keeps a full copy. Pick by what the upstream will allow and by what you want your resolver to hold, not by which snippet you found first.

Three arrangements for one namespace

Conditional forward: the smallest commitment

Assume an office resolver at 192.168.10.53 and a corporate server at 10.40.0.53 reachable across an approved tunnel. The declaration is three lines, and the interesting one is forward only, because it changes the failure behaviour rather than the path.

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

With forward only, an unreachable upstream produces a SERVFAIL for this zone instead of a fallback to iterative resolution. That is usually what you want for a private namespace, because the fallback would send private names to a public resolver and return an unhelpful answer from the internet. The BIND reference documents both policies, and the difference matters more than the snippet suggests. Merge the zone into the existing configuration rather than replacing a zone that already exists for the same name.

Stub or secondary: when the delegation matters

A stub zone asks the corporate server for the zone's NS records and then queries the authoritative servers directly. Choose it when the upstream region is large or subdivided and you want your resolver to follow delegation instead of pinning everything to one address. The cost is a dependency on the NS data being current, and on every listed nameserver being reachable from your resolver's source address.

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

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

A secondary answers from local data and survives an upstream outage, which is the reason to accept the transfer dependency. It also means your resolver now holds a copy of a zone it does not own, so the file path, the transfer ACL on the primary and the refresh timers all become part of your operational surface.

The check that decides between them

BIND generates its own outbound query, so the question is not whether a laptop can reach 10.40.0.53 but whether the resolver host can, from the source address the corporate server will see. Ask the kernel, then ask the server, in that order.

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

Permit UDP and TCP on the path: a truncated response forces TCP, and a policy that allows only UDP produces intermittent failures that look like packet loss. The corporate side needs both an accept rule for your resolver's source and a return route to it; that source may be the resolver's routed address or an explicitly translated one, and it is rarely a client pool address. If the NS query fails, a stub zone cannot work no matter how the forward zone behaves.

Verify the answer, not the tunnel

Query through the office resolver for a name you have never asked for, and check the answer's authority section to see whether it came from the corporate zone. A cached answer proves nothing about the current path, and a successful query to the upstream directly does not prove your resolver selected that zone. Repeat the same query over TCP to confirm the path survives truncation.

Keep clients pointed at the office resolver, and keep DNSSEC validation on. A browser configured with an independent encrypted resolver bypasses this arrangement entirely, and disabling validation to make an unexpected answer look correct trades a visible failure for an invisible one.

Write down which of the three types you chose and why. The next person to see the zone fail will need that sentence more than the config file.