• 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).
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).