[Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN

Ralf Jung post at ralfj.de
Thu Sep 4 12:41:50 UTC 2014


> There is a somewhat generic method, but your VPN software gets the
> DNS servers via its VPN protocol, and it needs to expose this somehow
> to either NM or dnssec-trigger or unbound.

I see. What's the recommended way to notify?
(I will soon be gone for 2 weeks, so I'll only be able to pursue this
further afterwards.)

> It should not need to re-probe. If you have VPN DNS servers, you are
> basically forced to use those. For the IPsec case, you also get a
> domain, so unbound can be told to only use those DNS servers for that
> domain. So probing it makes no sense, you need to use it anyway to get
> the internal DNS view at the other end of the VPN.
> But some VPN protocols might required you send all DNS queries to them.

I don't understand this. What makes VPNs different here than non-VPN
internet accesses? The DNS servers change, sure, but I don't see
anything forcing me to actually use them - at least, not more so than
anything forces me to use the DNS servers supplied via DHCP on a
physical wire. Sure, in both cases the supplied DNS may do "special"
things, or serve some local-only zones, or whatever - but none of this
is VPN-exclusive.
Also, even if the supplied servers had to be used, there's still the
question of whether unbound queries them and verifies the result - or
whether "insecure" mode is used.

In my particular case, I extracted the DNS servers supplied by the VPN
from the log, and fed them to "dnssec-trigger-control submit". Then
everything worked as expected (well, almost, but that's an independent
issue). Without manual intervention, the old "physical" DNS servers
remained in /etc/resolv.conf (put there by dnssec-trigger after the
probe failed), resulting in no name resolution being possible.

Kind regards

More information about the dnssec-trigger mailing list