Systemd Could Fallback to Google DNS?
Google is everywhere and provides free services to everyone. Amongst the huge list of services publicly available, there are the Google DNS, well known as 8.8.8.8, 8.8.4.4 (IPv4) and 2001:4860:4860::8888, 2001:4860:4860::8844 (IPv6). But Google is far from being a non-profit organisation and they collect a lot about you via their DNS[1]. Nothing is free and, when you get something for “free”, you (your data) are the valuable stuff. Never forget this!
It is already known that many systems are using the Google DNS as a fallback configuration. Docker is a good example. As written in the documentation[2]:
After this filtering, if there are no more nameserver entries left in the container's /etc/resolv.conf file, the daemon adds public Google DNS nameservers (8.8.8.8 and 8.8.4.4) to the container’s DNS configuration. If IPv6 is enabled on the daemon, the public IPv6 Google DNS nameservers will also be added (2001:4860:4860::8888 and 2001:4860:4860::8844)
Yesterday, there was some interesting tweets passing around about the same kind of behaviour but for systemd[3].
"systemd" is the new system introduced in 2012 to replace the good old “init”. It is used to manage processes started at boot time (in userland space). systemd introduced a lot of new features but also was the reason of major flamewars in the Linux community about pros and cons of the new system.
In the GitHub repository of systemd, in the configure.ac file, we can read the following block of code[4]:
AC_ARG_WITH(dns-servers, AS_HELP_STRING([--with-dns-servers=DNSSERVERS], [space-separated list of default DNS servers]), [DNS_SERVERS="$withval"], [DNS_SERVERS="8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844"])
How to interpret this code? systemd has a built-in fallback mechanism that specifies, at compilation time, that if no resolvers are configured, it uses the Google DNS by default! I performed a quick check on different Linux distributions (installed out-of-the-box):
Distribution | Comments |
---|---|
ArchLinux | Found the commented line in /etc/systemd/resvolved.conf: #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844 |
CentOS | Nothing found |
CoreOS | Nothing found |
Debian | Nothing found |
Fedora | Found the commented line in /etc/systemd/resvolved.conf: #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844 |
Gentoo | Nothing found |
OpenSuse | Nothing found |
RedHat ES | Not tested |
Suse ES | Not tested |
Ubuntu | Nothing found |
Some distributions, like Slackware, never implemented systemd.
This ‘FallbackDNS’ purpose is defined here[5]
A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Any per-link DNS servers obtained from systemd-networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf. This setting is hence only used if no other DNS server information is known. If this option is not given, a compiled-in list of DNS servers is used instead.
I also found an old report about this in the Debian bug tracker[6].
But the DNS configuration is not the only one to be affected, a list of default NTP servers is also preconfigured at compilation time[7]:
AC_ARG_WITH(ntp-servers, AS_HELP_STRING([--with-ntp-servers=NTPSERVERS], [space-separated list of default NTP servers]), [NTP_SERVERS="$withval"], [NTP_SERVERS="time1.google.com time2.google.com time3.google.com time4.google.com"])
Ok, nothing really critical here. Based on the tested distributions, there is almost no risk to see systemd falling back to the Google DNS. However, this is a good signal to keep in mind that some developers might introduce dangerous features and/or configurations in their code. Grepping for static IP addresses in configuration files is always a good reflex. About the DNS, my recommendation is to restrict the DNS traffic on your network and run your own resolver.
[1] https://developers.google.com/speed/public-dns/privacy
[2] https://docs.docker.com/engine/userguide/networking/default_network/configure-dns/
[3] https://en.wikipedia.org/wiki/Systemd
[4] https://github.com/systemd/systemd/blob/a083537e5d11bce68639c492eda33a7fe997d142/configure.ac#L1305
[5] https://www.freedesktop.org/software/systemd/man/resolved.conf.html#FallbackDNS=
[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
[7] https://github.com/systemd/systemd/blob/master/configure.ac#L1218
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
Reverse-Engineering Malware: Malware Analysis Tools and Techniques | Amsterdam | Jan 20th - Jan 25th 2025 |
Comments
Anonymous
Jun 15th 2017
7 years ago
For this specific example, a blackhole route to 8.8.4.4 etc. would have been sufficient. With iptables you could block all outgoing DNS queries except to a whitelist of destinations. Or, filter outgoing network traffic per-uid using the "-m owner" match, and either LOG or DROP everything else.
I particularly like where OpenBSD is going with pledge(), which is even able to restrict ability of daemons to do things like file I/O. Maybe systemd is such a large beast that something like it couldn't be implemented there, and if that's the case I would suggest to simply steer clear of it.
Anonymous
Jun 16th 2017
7 years ago