What's the most reliable configuration to have a fixed list of internal domains always resolved through an internal nameserver, even if it's unreachable because the VPN is down, while still using the default nameserver for everything else?
The connection is established by NetworkManager after selecting the appropriate interface or network in KDE (or another desktop environment).
This question is specifically about defining a static list of VPN domains because:
- Suppose there are three internal domains, which are known only to the internal nameserver within the VPN, two of which are automatically added to
/etc/resolv.confas "search" domains whenever the VPN connection is established, along with the internal nameserver, which is prepended to that file, if the VPN client is configured to do so.
- Suppose the internal domains of the main VPN are ".int", ".org", and ".test.net" and the first two would be added as search domains if the client was configured to change the
- If the VPN client changes
/etc/resolv.confafter establishing the connection, all DNS requests are sent to the internal nameserver, which should handle only the three internal domains but can't handle some other domains.
- Whenever the VPN connection is lost, the VPN client would automatically reset the
resolv.conffile, leaving only the standard nameserver assigned by DHCP, added by NetworkManager. So whenever the VPN is down, internal DNS requests are leaked; they're sent to the standard nameserver, which either doesn't know about them or resolves them to different, external IPs.
- Whenever a connection is established in KDE, the nameserver assigned by DHCP is written to the file. NetworkManager takes care of that, and if it was a link to a file containing only
nameserver localhost, it would probably have to write the received nameserver IP address to some
uplink.conffile, which would be used by the resolver.
- It wouldn't be necessary to make any additional changes to the
resolv.conffile if it was a symlink to a file containing only
nameserver localhostand if the local resolver would always know how to forward queries depending on the domain.
- The IP address of the internal nameserver is static and so is the list of internal domains: DNS queries for these internal domains should only ever be sent to the internal nameserver, no exceptions.
- DNS queries to other domains should be handled by the standard nameserver, as usual. Similar questions have been solved by manually configuring a nameserver but in this case, the system should use the one assigned by DHCP.
- A quick attempt with dnsmasq failed. After configuring
server=/int/10.1.1.1etc., it still sent queries for
xxx.intto the standard nameserver instead. The log file showed both
using nameserver 10.1.1.1#53 for domain intand
using nameserver 192.168.1.1#53 for domain int, where
192.168.1.1was the standard nameserver assigned by DHCP (so DNS queries were leaking). A solution with systemd-resolved is preferred but config examples for other resolvers are welcome as well.
- The focus of the question is the configuration of a local resolver like systemd-resolved, regardless of the state of the VPN connection or if a second VPN connection is currently active.
- This question is not about one specific distribution; it's for any distribution that uses systemd and has KDE. For example, Fedora 33 uses systemd-resolved by default, so a config example for it would be great.
- Standard tools like
pingmust work (i.e., not send queries to the wrong nameserver).
There are similar questions on this site, usually without the requirement of not leaking queries, as well as on other sites. For example, an article on gnome.org seems to address the split DNS question under "My Corporate VPN is Missing a Routing Domain, What Should I Do?", but it expects all internal domains to be set by the VPN client and states:
... Sadly, not all VPNs actually do this properly, since it doesn’t matter for traditional non-split DNS. Worse, there is no graphical configuration in GNOME System Settings to fix this. There really should be. But for now, you’ll have to use
Having to use such a command does not seem like a reliable configuration. And DNS queries shouldn't be leaked if the connection is lost for a moment. The article continues with:
Hopefully you never have to mess with this.
What if you do? The scenario shouldn't be too uncommon; there must be at least one standard solution.
For the record, this dnsmasq config was tried but it doesn't fulfill the requirement of defaulting to the standard nameserver provided by DHCP:
no-resolv server=/int/10.1.1.1 server=/org/10.1.1.1 server=/test.net/10.1.1.1 server=/google.com/126.96.36.199 # example server=188.8.131.52 # not wanted log-queries
/etc/NetworkManager/NetworkManager.conf, under section
Add a symlink to the config directory used by NetworkManager pointing to the config file that would be used when starting dnsmasq directly using
systemctl start dnsmasq:
`/etc/NetworkManager/dnsmasq.d/dns-int.conf` -> `/etc/dnsmasq.d/dns-int.conf`
However, as explained above, this configuration is not completely correct.