Over on TechTarget, Michael Heller wrote this week about some of the criticisms around DNSSEC and how some of them may be rooted in misunderstandings of what DNSSEC is all about. His article is:
I’m admittedly NOT a fan of title TechTarget gave the piece – it’s got that negative slant along the lines of “well, at least DNSSEC isn’t as bad as CAs” – but putting the title aside I thought it was quite a good article. Michael Heller starts out quoting John Levine about TLS certificates, which is what we know of in the technical realm as the DANE protocol.
He then went on to quote me more extensively than I expected … and I’m quite pleased overall with what he did. Particularly that he led with what I’ve been saying endlessly in presentations and articles for years now:
DNSSEC does one thing and one thing only: It protects the integrity of the information stored in DNS. DNSSEC ensures that the information for a domain name that you get out of DNS is the same information that the operator of that domain name put into DNS.
Every time someone on Twitter or Hacker News gets excited about how DNSSEC doesn’t protect the confidentiality of DNS information I always go back – that’s not the point!
As Heller writes later in the article, the work of the DPRIVE Working Group inside IETF is aiming to work on part of the confidentiality of DNS queries.
The other point I was pleased to see was that he addressed the issue of government control of top-level domains (TLDs). Some critics of DNSSEC continue to maintain that using DNSSEC is giving over control to governments. My point was that it depends upon what TLD you are talking about. Certainly some country-code TLDs (ccTLDs) are controlled by governments and so a government could in fact change your DNS information … but that can happen regardless of DNSSEC. (The case of Art.sy and the Syrian .SY TLD is an interesting example of challenges with ccTLDs.)
So… if you are concerned about this… well… don’t use one of those TLDs!
Stick with one of the TLDs where you know who the entity behind it is.
He also did cover what I do think is an important point about DNSSEC:
“Historically, DNS servers have often been boxes that network administrators set up and then generally ignored, as they’ve just been off running. Adding DNSSEC requires that some additional care must be given to the DNS servers,” York said.
This is very true. DNS servers often are just started up and then ignored. With DNSSEC you do have to be aware of them and plan for regular changing of the keys, ensuring the server times are in sync, etc. It’s not necessarily a great amount of work… but you do have to pay attention to DNS servers.
I was also pleased that he captured the point at the end that DNSSEC evolves. We’ve just recently seen that evolution with CloudFlare rolling out their DNSSEC services on a massive scale using the newer ECDSA elliptic curve encryption algorithm that is more secure cryptographically than RSA algorithms and has a smaller packet size. We also see the evolution with the proposed Internet-Draft about using Ed25519 elliptic curve algorithms. Yes, getting these changes deployed out into the field will take time, as resolvers and DNS servers all need to be changed to support them, along with user interfaces and more.
The point, though, is that DNSSEC is not a fixed and static technology. It can – and will evolve as security concerns change.
It’s good to see this piece out there and I do hope it encourages more people to look into how they can get started with DNSSEC.
Speaking of that… if you want to get started with DNSSEC please visit our Start Here page to find resources tailored to your type of organization!