OpenVPN Pushes DNS, but Your Resolver May Never See It

The client log shows the pushed DNS server, the tunnel is connected, and an internal name still resolves to nothing. Nothing is broken in the push itself. The option arrived and the operating system resolver never used it, because on most Unix clients OpenVPN delivers the value and leaves the application to the platform.

The symptom: the log shows DNS and names still fail

OpenVPN dhcp-option carries DNS and domain information, and the client records what it received. On some implementations the client applies those settings internally; on others it exports them for an integration script or a networking service to consume. The log line describes the first half of that story only. The second half happens somewhere the client does not control. That is where the failure usually lives.

That is why a connected tunnel and a failing internal name coexist so often. The value is present, the consumer is missing or misconfigured, and the resolver quietly keeps using the public server it used before the connection.

Received is not applied

A client can log a pushed DNS value while the system resolver remains owned by another service. A browser may also have its own encrypted-DNS policy that bypasses the system resolver entirely, which produces the memorable situation where one application resolves internal names and another does not.

Check the implementation's supported integration rather than assuming every Unix client rewrites the same file. The assumption is the reason people edit a resolver configuration that nothing reads.

Find the resolver owner per platform

On Windows, the name resolution policy table can direct specific suffixes to specific servers, and the VPN client may install rules there. Check the policy rather than only the adapter DNS list. On Linux, NetworkManager or systemd-resolved can own the configuration, and which one owns it determines what a reconnect will preserve.

Read the effective state with the tool that actually answers queries: resolvectl query internal.example.net on a systemd-resolved host, or the platform equivalent. Then compare that answer with the DNS server the client log claims to have pushed.

Avoid running several services that overwrite resolver settings without coordination. Two owners produce a result that looks intermittent, and each reconnect appears to fix or break it at random.

Scripts and foreign_option

OpenVPN exports pushed options to scripts through variables named foreign_option_N, and a script can translate them into resolver commands. That arrangement is a supported integration, not automatic behavior, and it has to be installed and invoked on the client.

If you rely on a script, log its execution and its exit status. A script that runs but fails silently leaves the same symptom as no script at all, and it is harder to notice because the configuration looks complete. Check the script output, not the script file. A file that exists is not a script that ran.

Test the name, not the log

Query an internal-only hostname from the client after connecting, then query a public name, then check which server answered. The two answers come from different places in a working setup, and both should match the design.

If the name resolves but the service fails, move on to routing and application access instead of changing DNS again. The OpenVPN manual documents dhcp-option and the script environment; use it to confirm what your client is expected to apply before you edit another resolver file.