© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
(In reply to David Woodhouse from comment #7)
> Note also that if you *wanted* to do split DNS, you have no idea which
> domains to do split DNS *FOR*. You have a list of default search domains,
> but that is a DIFFERENT THING. A search domain of example.com means "if the
> user looks up foo and it doesn't exist, then also look for foo.example.com
> before failing". It doesn't mean any more than that.
It also means that foo.example.com should be queried over the
interface that has it the search list. I don't think it makes any
sense that interface X specifies domain D in the search list but we
try to resolve it on interface Y.
> In particular, there
> can be domains which exist in a VPN (such as example.internal) which are
> *not* added to the search domains.
Yes, basically the search list is only a subset of the domains for
which we want to do split DNS.
> If you want to add an option for doing split-DNS, it can't be a boolean and
> abuse the search domains. It has to be an explicit list of the domains for
> which you want to use that DNS service. Unless we have a separate list of
> "domains which exist here" for each connection, which is *distinct* from the
> search domains?
I looked at systemd-resolved documentation and it introduces the
concept of "routing-only" domains, which are those domains only used
for deciding the output interface, as opposed to "search" domains that
are used for both completing unqualified names and for routing:
https:/
and I think we could do something similar. For example, interpret
domains starting with a tilde in ipvX.dns-search as routing-only. All
other domains automatically obtained from DHCP/VPN/... would still be
considered as standard search domains.
When the DNS backend supports split DNS (i.e. dnsmasq or
systemd-resolved) I think we should always use split-DNS for the
domains in the search list; and with always I mean also for non-VPN
connections. In this way, queries for a domain in the search list will
be forwarded only to the interface that specified it. Then, of course,
we need to add wildcard rules to forward non-matching queries to all
interfaces.
Borrowing another concept from systemd-resolved, we could support the
wildcard routing domain "~." that means "send all all queries that
don't match specific search domains to this interface". To keep
backwards compatibility, if no connection provides a wildcard routing
domain, we would forward all non-matching queries to all interfaces,
except to VPNs that provides a search list. In this way:
- we still do split DNS for VPNs by default
- this https:/
don't push any domains should get all queries) keeps working as is
In case of a full-tunnel VPN, one could set ipv4.dns-search to "~*" on
the VPN connection to direct all to the VPN DNS server. Queries for a
domain provided by a local connection would still go on through local
interface.
Any opinions about this idea? I pushed a draft implementation to branch
bg/dns-
cases mentioned in this bz.