Originally posted by computerquip
Originally posted by rtfazeberdee
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.
Comment