dnsmasq Drops a Private DNS Answer: Is Rebinding Protection It?

The company DNS server returns the expected private address, and a query through the local forwarding resolver still fails. The answer exists, which rules out the upstream zone and the record itself. What is left is the step where the resolver decides whether to hand that answer back to the client. If that resolver is dnsmasq, the rejection is probably already in the log.

Receiving an answer and choosing to return it are two different steps.

Compare the same name on both resolvers

Record which resolver the application actually uses and the exact hostname it asks for. Then compare the upstream result with the forwarding resolver's event for the same name. A missing upstream response, a cached negative answer and a logged rejection need three different corrections.

An address visible in a direct diagnostic query does not prove the application received it through its usual path. The two queries can leave from different resolvers, or from the same resolver under different policies. Write both results down before theorising, because this is the step where people substitute one for the other. The comparison is the whole diagnosis.

Read the rejection instead of the symptom

dnsmasq's stop-dns-rebind option rejects qualifying private-address answers received from upstream, and logs them when it does. That protection exists for a good reason: a public name that suddenly resolves to a private address is the classic rebinding attack. It also intersects with an intentionally private service, which is your case.

Search the log for the rejection before you change anything, because the message names the mechanism.

If there is no rejection and no upstream answer, rebinding protection is not your problem, and disabling it would be a change that fixes nothing while widening exposure. That is worse than the original failure, because it removes a control and leaves the fault. Confirm the specific log line first. Then decide.

Scope the exception to one domain

For a verified domain, the dnsmasq manual provides a domain-scoped exception rather than a global switch.

rebind-domain-ok=corp.example

The domain above is illustrative. Use the administrative domain you actually operate, and understand the option's matching scope before applying it, because a suffix rule covers more than the one host you tested. A router's configuration generator may expose the same setting through its own control rather than a raw directive. Either route is fine as long as the resulting scope is the one you intended.

An exception to rebinding detection does exactly one thing: it lets that domain's answers through.

It does not configure a split-DNS forwarder, make an unreachable upstream reachable, or create a route to the returned address. Each of those is a separate requirement with its own failure signature, and each fails differently in the client.

Verify without removing the boundary

Query the hostname again through the forwarding path, then connect to the service with its normal identity checks. A DNS exception is not a reason to accept an unexpected certificate, and the two failures are easy to confuse when both surface as a browser error. Test the name and the service separately. Only one of them was ever a DNS problem.

Keep the reason for the exception next to the configuration, with a date and an owner.

Recheck it when the private service moves or the domain changes. Disabling the protection globally would change how unrelated answers are treated, and it would still leave the route or service fault in place if rebinding was never the cause.