deFUDing “DNSSEC has failed”

It’s easy to forward or like an article of which the title says something you agree with, without actually reading the content. It seems “DNSSEC has failed” is one of those that showed up in my twitter feed. It’s so defunct of facts, it’s pretty clear most people have just read the title and retweeted it. Hopefully, they will at least read this post before not retweeting it.

It starts comparing the DNSSEC protocol with the SSH protocol. It claims ssh just works. It fails to take into consideration that the two are completely different trust models. With ssh, you tend to own both end points. So there is no issue of PKI or key distribution or trust. And even so, I am willing to bet the author never actually checks his SSH fingerprints when connecting to new servers, and just depends on the ssh leap of faith. Well, security is easy when you can assume you are not under attack. Most ironically, the easiest and only cross-trust-domain SSH public key distribution system out there is the DNSSEC protected SSHFP record. The only other one I know of is GSSAPI and other hooks into centrally-managed systems – eg all systems under one administrative control. Trust is pretty easy when you centrally distribute trust anchors.
Let’s also not talk about the debian ssh disaster, which was a pretty spectacular failure compromising thousands of ssh servers. Let me conclude the ssh comparison with inviting the author to login to using ssh in a fully trusted matter. He will end up 1) calling me to verify the ssh host key, 2) trusting the SSHFP key in DNSSEC or 3) leap-of-faithing it and hoping he was not under attack.

Next, the author brings up the tremendously easy to use and success of TLS. Never mind that we still need to run SSL 2.x for WinXP compatibility, most servers run TLS 1.0 which is severely broken, we just had the TLS 1.2 resumption/renegotiation disaster, about 4 CA compromises in 2013, and browsers running to patchwork solutions like hardcoded certificate pinning and Certificate Transparency registries that uses “n of m” style “it is probably the right certificate” solutions. There are about 600 (sub)CA’s that can sign any TLS certificate for any domain on the planet, ranging from Russia, to Iran to the U.S – all parties that are known to coerce parties and with a heavy industrial espionage component.

If TLS was successful, port 80 would be dead. Port 80 is the proof that the TLS trust model has failed. It involves money and so these certifications are only available to corporations. While DV certificates are now basically free, they are also considered worthless (protection against passive attack only) EV certificates are now dropping in price – which will make them finally available for more people but unfortunately because of that also lose their value. And all of this security hinges on the (mostly hidden) CABforum and browser vendor decisions on which CAs to include, and which CAs not to include.

While on most proprietary OSes, these preloaded CAs are at least managed by the vendor, the situation in Linux is a disaster. OpenSSL doesn’t support blacklists, NSS does. GnuTLS I don’t even know. Where are these CAs and blacklists? Do you know applications using openssl for their TLS are using the same CA bundle as applications using NSS or GnuTLS? Only very recently has Fedora and RHEL moved to a system where this is guaranteed. Even worse, most python wrappers using TLS don’t even check anything of your TLS connection. Presenting the wrong certificate will just cause that software to continue. And then look at the latest Apple TLS bug where anyone could bypass all TLS checks completely. How the author can even point to TLS as a security success is a complete mystery to me. It’s the worst computer security disaster we ever created! Look at the amount of complete failure TLS deployments at SSL Pulse – 30% allows weak ciphers, 6% has a broken certificate chain, less then 30% supports TLS 1.2, 6% vulnerable to the renegotiation/resumption attack, 70% vulnerable to the BEAST attack, 13% vulnerable to the compression attack, 56% allow RC4 and 50% does not support PFS. And that according to the author is the “success” that DNSSEC should take a lesson from?

Having listed the “success” stories of ssh and tls, he than looks at DNSSEC. His first factual statement regarding DNSSEC is “Most resolving software supports DNSSEC, but none have enabled it by default“. He is wrong. I have been the package (co)maintainer of bind, unbound and nsd for Fedora and EPEL for many years. On Fedora and EPEL/RHEL the default install enables DNSSEC for all three, and has done so for many years – even before the root was signed with DNSSEC!

Next he claims “To enable DNSSEC we have a ‘tutorial’ by Olaf Kolkman which spans a whopping sixty-nine pages“. As I said, the author is wrong. Simply “yum install bind nsd unbound” and the software comes with dnssec enabled, using the root key as trust anchor.

He then points to a DNSSEC training that takes “multiple days” and claiming that shows the complexity. The same vendor lists a two day DHCP course, a two and a five day “plain DNS & bind” course, and a two and five day IPv6 course. Does that mean those technologies are all failures too because it takes so many days to teach a course about it? According to the author, DHCP would be a failure and no one can deploy it because it “requires” a two day training? It’s just simplistic cherry-picked FUD.

His next argument is “Furthermore, there are almost no simple instructions for enabling DNSSEC, especially none that use KSKs and ZSKs, and include instructions on how to do key rollovers.“.

First, let me ask you how you do an ssh host key rollover? How do you make that seamless so it won’t trigger anyone who ever connected before from seeing a changed key? Where do they go to confirm the changed key is installed by the administrator and not the result of a hacked server or connection? Does this mean ssh has failed too? Again, amusingly enough the only way to rollover ssh keys is piggybacking on SSHFP in DNSSEC or GSSAPI trust models. But I don’t see the author claiming ssh has failed because it cannot do rollovers on its own. More cherry-picking.

The reality is, ssh and DNSSEC can do fine without rollovers. Only TLS requires rollovers because the trust model depends on the fact that you regularly pay the trustees managing that whole disaster. But if you do want or need to do a rollover, with ssh you’re fucked, with TLS you have to pay and with DNSSEC you have a seamless transition method. Let me repeat that – only DNSSEC actually implements a free and seamless key rollover mechanism! So of course, the author just states it is too hard to use. But again does not compare it against TLS or ssh at all. Cherry-picking all the way down. And by the way, there are also good reasons why you do not need to worry about DNSSEC rollovers at all.

As I said before, DNSSEC is already “enabled”, so let’s interpret the author’s quest for “simple instructions to enable DNSSEC” to mean “how do I sign my zone?”. Let us assume he is running bind right now with his zone in /var/named/ The author now has to issue the following complicated sequence of commands:

$ dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE
Generating key pair........+++ ..+++
$ dnssec-keygen -a RSASHA256 -b 1024 -n ZONE
Generating key pair........................................++++++ ..................++++++
$ cat*.key >>
$ dnssec-signzone -o -k
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

Edit named.conf and load the file instead of and you’re done. And whenever you change your zone, re-run that dnssec-signer command.
(NOTE: and as pointed out to me, if you don’t have zone edits every week, do run that signer command in a cron job weekly to refresh the DNSSEC signature records)

You can put this into a git hook and maintain the whole thing without ever realising there is a signing step in between. Hardly rocket science. I think we can argue whether or not this is harder or easier than creating a CSR for Apache, get it signed, and than installed (and too many people will forget to actually get the intermediate CAs installed in apache, and their deployment is actually even broken!)

The author’s issue with opendnssec is that it is “yet another daemon” using a “database backend”. I guess he is also not running postfix because that thing has more daemons than I can remember the names of. Opendnssec’s default “database backend” is sqlite. If you hate those, there is a lot of software you’ll going to have to purge from your servers. Sqlite is a perfect backend for small databases that are just too complex for simple text files. For those of us who don’t mind two extra daemons and some sqlite files, to sign your domain from scratch with opendnssec:

# yum install opendnssec
# systemctl enable opendnssec.service
# systemctl start opendnssec.service
# ods-ksmutil zone add –zone –input /var/named/ –output /var/named/
# ods-signer sign

Change named to load the .signed zone instead of the unsigned zone and done. Shockingly complicated! Unsuitable for “common engineers” according to the author.

To make these instructions complete, the last step is to send your DS record to your Registrar which involves using their custom webgui to send them the following data:

yum install ldns
dig dnskey >
ldns-key2ds -n

And if you want to do all of this within the same bind daemon and without sqlite, you can use bind’s builtin inline-signing management features instead.


Saying the tools are there for ssh (which doesn’t have ANY rollover support) and tls (which over half the world has misconfigured regardless of rollovers) but not for dnssec, is really short-sighted and wrong. What the author has done is taken his prejudice, and written some cherry-picked text justifying it. The only credit I can give him, is that he did not have to rely on the FUD statements by djb.

16 thoughts on “deFUDing “DNSSEC has failed”

  1. This article started out so well and then you said this “It involves money and so these certifications are only available to corporations.” only to continue with DV is now basically free and EV prices are dropping. So which is it?

    • certificates haven’t seen widespread adoption in the past because of money. Now that it is basically free, we see a little more adoption, but that does not mean the business model works. Because the profit margins dropped significantly, the CA industry can spend less money on their infrastructure and security. So I believe the value of the certificates right now is dropping because of that. The problem with CAs has always been that you only need one of them compromised to get what you want. With DNSSEC, at least I have a choice of Registrar (and Registry) and I can pick one that I think is more secure than the others.

  2. I agree that too many people re-tweet without reading or understanding.

    It is truly comical that five command lines are “Unsuitable for “common engineers” “, should they really be at the console or dealing with DNS if this is the case ?

    Excellent response, well written and I hope this gets the same coverage.

  3. Thanks Paul, great rant. I too have the DNSSEC religion. :)

    But there is one thing I have to quibble with: this bit where you say entering lots of commands (and let’s face it, without understanding what they really do, until you’ve read parts of the relevant RFCs and lots of DNS software documentation) is suitable for the average sysadmin. I mean, sure, lots of admin tasks are thankless and hard, and you really *should* know what you’re doing, but DNS is one of those things that has been neatly abstracted out by most web hosters and registrars and thank goodness for it, because there’s enough broken DNS as it is. I don’t think it’s so unreasonable to say that the DNSSEC “UX” is a bit sucky right now. We need more registrars to host DNSSEC and perhaps sacrifice a bit of security (trust on the registrar), instead of deferring it to self-hosters, who will inevitably either not do it or not have the time to understand it sufficiently, much as it is the case with DNS today. SSL and SSH, by contrast, are basically autonomous if you follow the directions given by your CA (or delete the known_hosts file), and are basically trivial to explain in a few paragraphs.

    Anyway, thanks again for this, was really hoping for the rebuttal, and am not disappointed. :)



  4. Did you really have to take this down to the ad hominem level?

    I never said ssh and https are perfect. But at least people have some idea how to use them and they add some layer of security. Especially if you follow the instructions properly, which are easy to google for both.

    For dnssec there are almost no instructions, which you have demonstrated by having to write it down yourself and not being able to point to an easy to follow tutorial.

    Yes I put it more bluntly to get attention to this fact. And that succeeded a lot better than I thought it would. But I’m also going to work on improving this.

    And next time please don’t insult someone just because you disagree with them.

    • You said on twitter “I exaggerated” and in a comment here “I put it more bluntly to get attention”. Isn’t that a confirmation that you were using FUD for your own goals?

      The article contained two broken comparisons and a few misleading statements. Which I countered factually. Which I’m happy to hear I’m wrong about. None of that is ad hominem.

      Sure, I could have left out the comments about “more FUD”, but oddly enough you confirmed that your tactics was in fact FUD?

      So I’m not entirely sure how I insulted you. Did I call your bluff, yes.

  5. Sorry to interrupt you. You made a huge mistake (a lot of people did and do this mistake over and over again)

    You wrote: “Edit named.conf and load the file instead of and you’re done. And whenever you change your zone, re-run that dnssec-signer command.”

    Unfortunately it is not *that* easy. DNSSEC does not rely on key rollovers (as you point out), but heavily on signature rollovers (most people try to forget)

    So you have to make sure, that expiring signatures are renewed early enough. You can use opendnssec-signer or bind-inline signing. But if you do it manually, you will have a hard awake a few weeks after finishing the project.

    This is a completely new issue for admins: If something is set up and seems running for a few days, it will run forever. With DNSSEC this assumption is broken: You have to *maintain* your system regularly.

    So you are cherry-picking, too :-)

  6. I think DNSSEC has failed, or is on its way to fail, because of a different reason.

    I don’t think it is the core infrastructure part. It *is* possible to run DNSSEC properly. We have many domains that are properly setup and that number is rising nicely. It is hard and requires new skills, but it is possible.

    No, I think the reason it is on its way to fail is that after all these years there is still practically zero *mainstream* client support. Not in end-user routers, not in end-user operating systems and not in end-user applications.

    • crypto libraries move very slow, but openssl, nss and gnutls are on their way to get DANE-TLS support. So I think you are wrong.

      The browsers have been fighting a low-latency/speed war. Users don’t care about 1ms – at least not more than having good security. So I see the pendulum swinging back now. Applications are starting to use DNSSEC (See the giant ‘trust AD bit’ IETF discussion as an example)

      • I think it would be good to have registrars support EPP or some other standardized protocol (JSON anyone ?).

        This will allow people that have more than a few domains to manage to push that DS up the chain more easily.

        There are also people that are still concerned about the location and governing body of the DNSSEC root keys.

        A few days ago, I was thinking: has anyone ever made a script that will make auto-trust-anchors for Unbound for all the TLDs and all reverse zones of all the RIRs ?

        That would remove the dependency on the DNSSEC root key after running the script the first time.

        You would only need to run that script in a cron job to create a new auto-trust-anchor every time a new TLD is added (it could even send a notification email when it does so).

  7. Just my two cents – we are also working very hard on automating the DNSSEC in Knot DNS to the level, you can just enable it, send the DS/DNSKEY to the parent and it should just work. The first working version was introduced in 1.4.0 and we are going to release next version this year with easy key management.

    On some level the DNSSEC has a learning curve, but so does proper DNS, but the tools gets better and the technology is fortunately not horribly broken like PKIX is.

Leave a Reply

Your email address will not be published. Required fields are marked *