Comment 22 for bug 1864256

Revision history for this message
In , mcatanza (mcatanza-redhat-bugs) wrote :

(In reply to Benedikt Gollatz from comment #13)
> Unless there is a different bit of hidden configuration, it seems
> that even fresh installations of F33 would encounter the problem of
> non-resolving internal names.

Well I doubt it, because if so, openvpn would be broken for everyone. You should get one of the following behaviors for 'resolvectl domain'. With "use this connection only for resources on its network" unchecked (default behavior, good for public VPNs):

Global:
Link 2 (wlp58s0):
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (tun0): ~.

Or, with "use this connection only for resources on its network" checked (good for corporate VPNs):

Global:
Link 2 (wlp58s0): ~.
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (tun0): example.com

where example.com is the domain of your VPN. Since you are trying to resolve internal names, I assume you're using a corporate VPN and that is the setup you want? Can you please confirm that you have that button checked?

In both cases, 'resolvectl dns' should look like this:

Global:
Link 2 (wlp58s0): <default nameservers>
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 6 (tun0): <VPN nameservers>

That's all rehashed from comment #10, but I post it again here for clarity. I use both configurations every day, at the same time, and it all works as expected for me. Deviation from the above is unexpected and unusual. Something strange is happening with your case, and we need to figure out why.