NetworkManager

  1. Bug #1754671
  2. Comment #91

Comment 91 for bug 1754671

Revision history for this message
In , dwmw2 (dwmw2) wrote :

Some further notes:

 • I can make NetworkManager-openconnect provide both 'search domains' and
   'split dns domain' in separate config items. Right now we mache them all
   into the search domains because we know NM abuses that field for both,
   but we should fix that too.

 • We might perhaps take this opportunity to kill the weirdness that we have
   redundant DNS information in *both* IPv4 and IPv6 configs. That was always
   wrong, and a clean break to make it sane might be better than letting it
   persist for ever.

 • For a split-tunnel VPN, it's OK to have the split-dns lookup list default
   to the same as the search list (plus all the reverse domains which we do
   already get right, I believe). It should be possible to *add* entries to
   the split-dns lookup list that aren't in the search list, both manually
   in the config, and automatically from the VPN plugin (see first point above).

 • for a full-tunnel VPN, the split-dns lookup list should cover everything.
   There *might* be an exception list — for example IF we allow routing to
   the local network (cf. bug 767288 which asks for an option not to) then
   the reverse lookup ranges in .ip6.arpa and the split-dns domain list of
   the local network would be the only thing that's permitted *not* to go
   to the VPN's nameservers.

In the general case, DNS lookups for reverse ranges in .ip6.arpa and .in-addr.arpa should go to the nameservers of the connection to which we are routing those addresses. We *mostly* get that right, except for full-tunnel VPN right now.

Forward DNS lookups by default should go to the DNS servers of the connection which has the default route. Again, we don't get that right for full-tunnel VPN right now.

Forward DNS lookups for domains which are listed in some connection's "split-dns domains list" (which I called the 'lookup list' above), could go to that connection's DNS server UNLESS there's a reason not to (like a full tunnel VPN wanting to disable *all* local access as discussed in bug 767288).