[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10
erwin at lansing.dk
Fri Jun 3 13:08:09 UTC 2016
Very good analysis Ondřej.
I vividly remember the discussions we had in the FreeBSD community back in the 2013/14 timeframe on how to make DNSSEC ‘on’ the default. We did end up importing unbound as a local caching forwarder, but never solved the issues of real world deployment to actually make validating the default as well. dnssec-trigger has some interesting concepts that could be leveraged, but there was the the issue of actually getting the users attention. Apart from the, erm, more “interesting”, or plain broken, implementations out there, there were too many scenarios where DNSSEC would fail (captive portal anyone?), the user would actually end up being completely without any internet access. Of course, he would indeed be very secure :-)
Opportunistic DNSSEC works around this problem, but at the cost of breaking its security promise. I would very much argue that false security is worse than no security.
> On 03 Jun 2016, at 14:05, Ondřej Surý <ondrej.sury at nic.cz> wrote:
> Hi Peter,
> ok, so here are my reasons:
> 1. DNSSEC="allow-downgrade" aka "Opportunistic DNSSEC" is just a horrible idea. I would compare it to the "I see a wonky certificate, do you want to continue?" in the browsers. We are still recovering from that. Deploying DNSSEC at the end-stations is hard (and as far as I understand the efforts in the Fedora/RedHat, they are still failing). We don't have any way how to signal the user whether the lookup was secure or not, and even if we had the users wouldn't understand the impact. In my opinion, the only way how to make the computers secure is to require the security. (This is similar to not enabling 'dnssec-check-unsigned' in dnsmasq.)
> 2. The static src-ports was already fixed, but I think that making this mistake in the first place is a symptom that writing a secure resolver without talking to the people who deeply understand DNS can turn wrong. I spoke to Lennart after his FOSDEM talk and while I understand his position on "just fixing broken things", I think it's also important to "fixing" them right and not just with huge "ducktape".
> 3. DNS is hard. I've seen to many weird DNS setups to believe that it will not break even if it leaves the heavy-lifting to the upstream DNS resolver. But... systemd-resolved has to be caching DNSSEC-validating forward (otherwise it would be very expensive) and that brings another set of problems. And I simply don't believe that this test set covers all the weirdness in the DNS.
> 4. In the end it might be better than having a default dnsmasq as a resolver, but it still doesn't make it right.
> Perhaps I am wrong and systemd-resolved in Ubuntu 16.10 will be a huge success, but my common sense (aka gut feeling) and experience with DNS tells me otherwise.
> 1. https://github.com/systemd/systemd/tree/master/src/resolve/test-data
> Ondřej Surý -- Technical Fellow
> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury at nic.cz https://nic.cz/
More information about the dns-operations