Systemd Could Fallback to Google DNS? - SANS Internet Storm Center

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

Xme

392 Posts
ISC Handler

This is definitely present on Ubuntu 17.04 (zesty zapus); it uses the same location as the other systemd-based distros: /etc/systemd/resolved.conf.

Paul

3 Posts Posts

We might want to reconsider if free software is always developed in good faith, or if the developers would compromise in some areas of privacy/security that you wouldn't be happy with for your own use case. We're slowly learning how to defend in-depth against possibly-backdoored hardware like Intel ME and black-box HWRNGs. So we can apply the same principles like sandboxing to software to make it easier to trust.

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.

Steven C.

171 Posts Posts