[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10
paul at nohats.ca
Sun Jun 5 18:29:20 UTC 2016
On Fri, 3 Jun 2016, Phil Regnauld wrote:
>> ... apparently it doesn't do source port randomization. Ouch.
>> That's a real step backwards if that's the case.
> Ok, this was implemented in systemd 220:
> * systemd-resolved now implements RFC5452 to improve resilience against
> cache poisoning. Additionally, source port randomization is enabled
> by default to further protect against DNS spoofing attacks.
systemd-resolved requires a forwarder. It is not a full DNS recursive
server. So source port randomization is pretty useless as you are most
likely just doing DNS on the local network.
Also, "improve resilience against cache poisoning" is quite the weasel
wording. Especially since it trusts faster answers over slower ones over
different interfaces. The design is still horribly broken.
At devconf, the systemd people described the system to us. Things might
have changed since then and we should verify that. With that, let me
mention what I remember:
- It uses nsswitch to basically take over gethostbyname*() and
getaddrinfo(). This means any software using a DNS library like ldns,
unbound, bind, knot, etc bypasses this system and gets an inconsistent
DNS view from the rest of the system. It explictely does not support
those kind of applications. Due to its issues below, this is a problem
for applications insisting on DNSSEC answers (eg postfix). It does not
supply a "local DNS server" that those dns libraries could use to get
a consistent view.
- it fudges with /etc/resolv.conf, but it does not provide a DNS server.
So it cannot put 127.0.0.1 in resolv.conf. This means ANY application
using /etc/resolv.conf that does not use glibc is going to go around
systemd-resolvd. Yet systemd-resolvd messes with resolv.conf.
- The process turns a request for binary DNS data into into XML, feeds it
into the sytemd/dus ecosystem, which turns it into binary DNS to send
it to the forwarder. The binary DNS answer then gets turned into XML
goes through systemd/dbus, then is turned back into binary DNS to feed
back into glibc. Apart from errors in this process, like last year's
CVE on cache poisoning attacks, this means the systemd people need to
very actively maintain their code whenever a new feature or RRTYPE is
added to the DNS protocol. Maintenance and bugfixes is not systemd's
strong point. This architecture is overly complex and unneccessary.
- It won't work well with applications that have their own DNS code
itside. Such as browsers. This becomes worse when you think about
browsers supporting draft-shore-tls-dnssec-chain-extension.
- It is yet another program/daemon that runs races with other software
in controlling /etc/resolv.conf. Eg VPN software adding nameservers.
- There is no option to become a full recursive DNS server. It depends
on a forwarder being obtained via DHCP. This means any broken
forwarder leads to a broken setup. eg an upstream that strips DNSSEC.
- It accepts DNS forwarders for all its interfaces. That means if you
are on wifi and 3g, or ethernet and wifi, you have more than one
DNS server from logically different networks. With no way of
guaranteeing which logical network you asking.
- It sends out a DNS queries over all its obtained DNS servers all the
time. This means DNS queries for split-DNS view resources leak all
over the internet.
- It accepts the first valid answer. This could be an unsigned answer.
This means a local attacker (eg wifi hotspot) has an advantage over
the actual real DNS forwarders.
- It prefers an answer over an NXDOMAIN as workaround for the above.
So if some A record does not exist, the NXDOMAIN is ignored in
favour of a forged, or rogue wildcard type, answer.
- It does not implement RFC-5011 properly. It might remove trusted keys
upon seeing the revoke bit instead of waiting the time period
specified in RFC-5011.
- I believe it does not support DNS-over-TLS
- I _believe_ it does not support network changes that requre a cache
flush, for instance a VPN network with an internal *.corp.company.com
whose entries need to be removed from the cache when the network is
- I _believe_ it does not handle trust anchors linked to DNS nameserver
IP addreses. Needed for DHCP servers relaying multiple domain names
for resolving and VPN situations like draft-pauly-ipsecme-split-dns-01
- I _believe_ it will not able to reconfigure forwarders on the fly.
I was told it was not a caching dns server. But that seems to be the
case now. Which in a way makes things worse, because hotspots could then
keep long lived forged records in my cache? Unless they flush all the
cache on any network interface change, which in itself would cause me
to leave my fingerprints all over the internet for pervasive monotiring
More information about the dns-operations