Private VPN Names Failing? DNS Rebind Protection Is the Suspect

On the office LAN the internal name answers instantly. The moment the VPN is up it stops working, the application reports a timeout, and the tunnel itself is passing traffic without complaint. What changed is the resolver, and that resolver has an opinion about private addresses.

Rebind protection exists to stop one specific trick. A deliberately published private name looks similar enough that the defence fires.

Read the Answer Before You Read the Policy

Query the name against the resolver the VPN actually pushes, not the one your laptop uses at home. Compare the answer with the record you expect, and note whether the reply is empty, refused, or full of public addresses nobody planned.

The symptoms overlap, so the shape of the answer decides the diagnosis. An NXDOMAIN is a missing record, a REFUSED is an access rule, a public address for an internal name is a policy or split-DNS error, and a correct private address the client cannot use is a different problem entirely. A refused connection or a stalled request proves nothing on its own, which is why the first command in any of these tickets should be a lookup rather than a restart. Write the answer down before changing anything.

What the Defence Is Actually Stopping

DNS rebinding works by changing what a name resolves to after the client has already trusted it. A page loads from an attacker-controlled name, the answer flips to a private address, and the browser is tricked into talking to something on the local network it would never have accepted a direct connection to. The defence is to refuse answers pointing into private space when the resolver was never asked to serve a private namespace. That asymmetry is the whole attack.

dnsmasq documents exactly that behaviour, along with per-domain exceptions. Its manual page describes rebind-domain-ok as the way to name domains that may legitimately return such addresses. Read it as a signal that the intended fix is a scoped allowance, not a global switch.

Scope the Exception to the Namespace

Fix the namespace first, then the exception. Confirm that the failing name belongs to a domain the organization controls and that the record is maintained deliberately. An unexpected address that merely resembles a familiar LAN range deserves suspicion, not an exception, so check the zone's owner before writing any allowance.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

Then add the narrowest allowance that covers the intended names: one domain, or one delegated subdomain, in the resolver configuration the VPN clients query. Turning the protection off for every name on that resolver removes the defence for all of them at once, including the names that never needed it.

Split DNS belongs in the same decision. If the private namespace should only be answered on the internal resolver, publish it there and stop leaking it to public resolvers, so the exception covers one path instead of every path.

Re-Test the Resource and the Defence

Query again, then connect to the service and check what the client sees. A correct private answer with a working session means the exception landed. A correct answer with a stalled session means the route or the service identity is the next suspect.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

Test a public name through the same resolver as well. The protection should still behave for names outside the exception, and if that check fails, the change was wider than intended. Keep certificate validation untouched throughout, because a name that resolves correctly still has to match the certificate the service presents.

Record the rejected answer, the domain, the resolver and who owns the policy in the ticket. That record is what turns a mysterious internal outage into a configuration change somebody can review.