I'm not sure why it's being asserted that these two uses are mutually
incompatible, especially since I've been using them in a coordinated way
forever and can still do so (at the expense of junking systemd-resolve
and going back to using dnsmasq and a custom configuration, which is
obviously a big pain). I've even, in the past, used MULTIPLE VPNs, even
at the same time, and it still just works.
If the resolver library (e.g., gethostbyname etc.) gets an unqualified
hostname, it uses the search path just as it always has including ndots
and all that stuff, to generate FQ hostnames. No change there.
When the local resolver caching service (dnsmasq, systemd-resolv) gets a
FQ hostname it looks through the extensions provided by the VPN DHCP
information and if the hostname matches that extension it forwards the
lookup to the DNS server for that VPN. If it doesn't match, it doesn't
forward the request. If it doesn't match any of the VPN search paths,
it forwards the request to the default DNS servers.
I honestly don't understand why we're considering these uses
incompatible. They seem to me to be exactly compatible and exactly what
you want to do, at least the vast majority of the time.
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
ubuntu-bugs mailing list