In the configuration file for local network interface (a file matching the name pattern /etc/systemd/network/*.network
) we have to either specify we want to obtain local DNS server address from DHCP server using DHCP=
option:
[Network]
DHCP=yes
or specify its address explicitly using DNS=
option:
[Network]
DNS=10.0.0.1
In addition we need to specify (in the same section) local domains using Domains=
option
Domains=domainA.example domainB.example ~example
We specify local domains domainA.example domainB.example
to get the following behavior (from systemd-resolved.service, systemd-resolved man page):
Lookups for a hostname ending in one of the per-interface domains are
exclusively routed to the matching interfaces.
This way hostX.domainA.example
will be resolved exclusively by our local DNS server.
We specify with ~example
that all domains ending in example
are to be treated as route-only domains to get the following behavior (from description of this commit) :
DNS servers which have route-only domains should only be used for the
specified domains.
This way hostY.on.the.internet
will be resolved exclusively by our global, remote DNS server.
Note
Ideally, when using DHCP protocol, local domain names should be obtained from DHCP server instead of being specified explicitly in configuration file of network interface above. See UseDomains=
option. However there are still outstanding issues with this feature – see systemd-networkd DHCP search domains option issue.
We need to specify remote DNS server as our global, system-wide DNS server. We can do this in /etc/systemd/resolved.conf
file:
[Resolve]
DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
Don't forget to reload configuration and to restart services:
$ sudo systemctl daemon-reload
$ sudo systemctl restart systemd-networkd
$ sudo systemctl restart systemd-resolved
Caution!
Above guarantees apply only when names are being resolved by systemd-resolved – see man page for nss-resolve, libnss_resolve.so.2 and man page for systemd-resolved.service, systemd-resolved.
See also:
References:
Best Answer
Confusing names that people often get wrong.
In the terminology of RFC 1034, there are "resolvers" and there are "name servers". "resolver" describes the entire subsystem that user programs use to access "name servers", without regard to any particular architecture. It's the subsystem that queries one or more "name servers" for the data that they publish and pieces together from those data a final answer for the querying application, in the manner described in RFC 1034 § 5.3.3. A "resolver" is the overall subsystem that does query resolution.
The RFC theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each individual applications program.
In RFC 1034 terminology, a "stub resolver" is what is generally employed in the Unix and Linux world: a fairly dumb DNS client library running in the application processes, talking the same DNS/UDP and DNS/TCP protocols to an external program running as another process, that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
"resolver" is such a confusing term, and so often used contrary to the RFCs, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into applications.
The DNS client library does name qualification and finds out what DNS proxy server(s) to talk to, in the manners described in further reading.
systemd-resolved
listening on 127.0.0.53.Other Unix and Linux softwares that perform this rôle include Daniel J. Bernstein's
dnscache
,unbound
,dnsmasq
, the PowerDNS Recursor, the MaraDNS Recursor ("Deadwood"), and so forth.I personally have a local instance of modified
dnscache
(that can inherit its listening sockets) on every machine listening on 127.0.0.1, which is also the default place that the BIND DNS client library expects a proxy DNS server to be, in the absence of explicit configuration.systemd-resolved
talks to other proxy DNS servers, which may well talk to yet further proxy servers, forwarding the query along a chain until the query reaches a resolving proxy server.systemd-resolved
to use other proxy DNS servers instead of Google's, the chain will be longer. Examples of such configuration include (in a rough best-to-worst order) using a local resolving proxy DNS server on the LAN, using a proxy DNS server that is running in a router/gateway at the edge of the LAN, or using a third-party proxy DNS server that is out on Internet at large.systemd-resolved
at the near end of that chain, to the DNS client library in the applications.In RFC 1034 terms, for contrast, the "resolver" here is in fact a huge black box encompassing the BIND DNS Client library,
systemd-resolved
, and Google Public DNS, because it is defined by the RFC as having "user programs" on one side and content DNS servers (providing referrals and database information "directly") on the other. People often will mis-use the term, sometimes because they misunderstand the RFC 1034 architecture-neutral concept of a "resolver" to be the same as one single Unix or Linux server program, which it is not. HTTP terminology does not have the huge black box.Further reading
dnscache
,tinydns
, andaxfrdns
services". nosh Guide. Softwares.