Two Sites, One Private DNS Zone: Who Owns the Records?

You add a host at the green site, it resolves for green users, and the yellow office still gets NXDOMAIN. That is not a VPN failure and not a broken resolver; it is an ownership gap in the private zone. Two independently edited record lists do not become one zone just because the sites can reach each other. The fix is a publishing plan, not another firewall rule.

The symptom names the missing owner

Each site probably has a local override, a Pi-hole entry or a dnsmasq line that someone added when a name was needed. The green record exists only on the green resolver, so a client at yellow asks its own resolver and receives a truthful "no such name". A stale answer looks different: the host moved, one site updated its copy, and the other still returns the old address.

Neither pattern is fixed by a cache flush for long. A forwarding resolver's cache is a copy of an answer it once received, not an authority that publishes new names, so a cache that works today says nothing about tomorrow's host. The BIND documentation describes primary, secondary, recursive and forwarding roles separately for exactly this reason.

So the design question is narrow and answerable: who may create a record, and how does that record reach every resolver that must answer for it?

Option A: one authoritative zone with secondaries

Run a primary for internal.example.com and let supported secondaries obtain the zone at each site. Each site's recursive resolver queries its local secondary, so answers come from an authoritative source rather than a cache, and a change made once is transferred rather than retyped.

That arrangement needs explicit decisions that are easy to postpone and expensive to skip. Who may edit the zone? Which servers are allowed to transfer it, and over which addresses? What should clients see while the tunnel between sites is down? A secondary keeps answering from its last copy, which is usually the behaviour you want, but it must be a stated choice rather than a surprise during an outage.

Restrict zone transfers to the known secondaries by address and use transaction signatures where the implementation supports them. An open transfer is a copy of your internal namespace for anyone who can reach the port.

The cost is coordination: one editing path, one change review, and a shared understanding of who is on call when a record is wrong.

Option B: a subdomain per site

Delegate green.internal.example.com to the green site and yellow.internal.example.com to the yellow site. Each site becomes authoritative for its own names, and the parent zone carries only the delegation records. Contention over one file disappears, and a local team can add a host without waiting for a central change.

The delegation has to exist in the parent, with NS records that point at the site's authoritative servers. A conditional forward for the subdomain is a valid alternative when a full delegation is impractical, but it is a resolver setting rather than a published fact, so every resolver needs the same rule.

The cost moves rather than vanishing: the parent zone still needs an owner, and creating a new site is now a change in two places instead of one.

Make each resolver follow the choice

Give clients the approved resolver and search domain through their supported configuration, and make sure the resolver has a permitted VPN route to any remote DNS server it must query. Applications also need routes to the private addresses those answers return, because a correct name with no path is still a broken connection.

If Pi-hole supplies local resolution, write down which records it owns and which queries it forwards. Two independently edited Pi-hole lists still do not replicate. In Pi-hole v6, custom dnsmasq lines are set through host-side options such as TOML, CLI or environment variables and are not exposed through the API; loading /etc/dnsmasq.d/ files is a separate option that is off by default.

Then test from both sides with a name that should be visible everywhere:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

The SOA answer tells you whether the yellow resolver believes it is authoritative, is querying a secondary, or is just forwarding. Those are different designs with different failure modes, and the reply usually identifies which one you actually deployed.

Finish with three acceptance cases: one name from each site, one record changed within the hour, and the intersite link unavailable. A design that passes only the first has a publishing plan on paper and a local override in production.