[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10

[Paul Wouters]

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:
>
> https://github.com/systemd/systemd/blob/master/NEWS
>
> * 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
    lost.

- 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
attacks.

Paul