Table of Contents
As the author of a nameserver, I get a lot of questions about what I think of DNSSEC. I think DNS is of too little importance to merit complicated cryptosystems. This document sets out what the elements of security are and the tiny role DNS can play in it.
Information Security is generally considered to consist of the following:
Your data should not be readable by others.
It must be possible to determine if the message was sent by who it appears to come from.
It must be provable that the data received has not been tampered with.
Once received, the sender of a message should not be able to deny that he sent it.
There are existing solutions to ensure that all these four conditions are met.
DNS is the phone book of the internet. In it, we look up which IP address we should connect to in order to deliver email to a recipient. It also tells us the IP address of the webserver serving a domain.
Once the IP address is in, your mailer or web browser can start its real work.
Unlike the 'real' phone book, which is locally run by a single organization, the DNS is distributed all over the world by the use of 'referrals'. A question for 'news.bbc.co.uk' would initially be sent to the 'root-servers', the master servers who have little knowledge themselves, but know where all questions can be answered.
Next, the question is sent to the UK servers, who, like the rootservers are not very knowledgeable, but they do know where to ask questions for domains ending on 'co.uk'. This server knows more specifics, but still does not have the final answer, and instead refers the question to the BBC nameservers, which then finally supply the answer we were looking for.
This long winded process is generally short-circuited because the nameservers tend to remember previous answers, and use them to speed up subsequent questions. For example, to figure out how to send mail to firstname.lastname@example.org after performing the query above, requires only one additional question.
This system is very pretty and has, so far, succeeded very well in being almost invisible. Most Internet users will never know that this is all going on under the hood, it just works.
One reason is that DNS is pretty simple and uncomplicated and has a tendency to be robust in the face of network disruptions and misconfiguration.
Part of this simplicity is the complete lack of confidentiality, authentication and integrity. Instead, tricks are employed to get something that can pass for authentication, making it hard for third parties to spoof answers.
DNSSEC attempts to add authentication and integrity to DNS. Given the distributed nature of the Domain Name System, in the example above four different nameservers were involved, making the existing protocol secure requires that the solution is implemented all the way downwards.
Furthermore, as most questions are in fact answered using data remembered from earlier queries, any cryptography added needs to be cached as well.
Over the past five years or more, some of the smartest people involved with internet protocols have been hammering out a system that has near-perfect authentication and integrity, is distributed and survives caching and it appears that they may have succeeded. This is an impressive feat as the demands on the protocol are nearly impossible to match.
However, in meeting all these demands, the protocol has grown very complicated. It now includes keys, key signing keys, 'no-exist' records, signatures, delegation-signer records, zone signing keys, secure entry points, 'dithered time fudge' and opt-in tagged no-exist records. Furthermore, there are whole doctrines involved in changing these keys, which needs to happen on a pseudo-regular basis.
As mentioned earlier, the DNS is the phone book of the internet. It provides us with the right IP addresses, but that's it. In the grand scheme of things, it is but a tiny piece of security.
Having the right IP address is only the start of things and does nothing to absolve us from making sure the webpage we visit was not intercepted or modified in transit. It also does not protect us against domains being hijacked, DNSSEC only protects the DNS side of things, not the integrity of the registry.
DNSSEC makes sure we get the IP address as recorded by the owner of a domain. It does not confirm to us who registered the domain, it does not protect the communication with the IP address.
As said before, DNSSEC is vastly more complicated than DNS. This means that nameserver software is a lot bigger and hence more prone to security problems, where it should be known that nameservers already have a shabby reputation for hacker vulnerabilities. DNSSEC will only exacerbate those problems.
Furthermore, DNSSEC is sensitive to many configuration errors, the slightest of which cause a domain to stop working for those using DNSSEC. The easy solution, to fall back on regular DNS in case of errors, is not possible as this allows third parties to disable DNSSEC by simple means, losing any benefits that secure DNS would provide.
As mentioned above, to perform as intended, DNSSEC needs to be deployed on all servers involved in answering a query which means a massive overhaul which would be nothing short of a revolution to achieve.
So far, information security has been implemented at higher levels, DNS being at the lower end of the protocol stack. Examples of existing solutions include PGP (Pretty Good Privacy) for transmitting files or email messages, HTTPS (secure http) for accessing webservers and IPSEC for encrypting transmission from end-to-end. Many corporations also use Virtual Private Networks to provide end-to-end security.
These higher levels verify the authentication, and supply integrity at a higher level, irrespective of the way a message or file or webpage was transferred. Hence, they are oblivious to DNS. Furthermore, being involved in the message itself and not just with the phonebook, they can also ensure the confidentiality of messages, something that DNS is powerless to do.
Lastly, a failure in a higher level often does not disrupt communications. The end-user may get notified that a message could not be decrypted, or was damaged in transit, but the message does arrive. This allows for easy troubleshooting, or the user can choose to ignore warnings about integrity and authenticity and open a message regardless. The contents may be convincingly authentic.
While it would be good to increase the authentication and integrity of DNS messages, it would do little to increase the general security of the internet. Combined with the complexity of DNSSEC, its inherent lower robustness and hence availability of domains, the increased vulnerability of the larger amount of code needed to support encryption in nameservers, I can only draw the conclusion that DNSSEC is not worth it.
Furthermore, I predict that the additional downtime that will inevitably be caused by DNSSEC misconfigurations will quickly raise the perception that DNSSEC is unreliable.
Because of the small role DNS plays in information security, it only warrants very non-intrusive solutions which need not rise above the 'pretty good' level.
 Taken from Applied Cryptography by Bruce Schneier
 In reality, it involves six different nameservers as things are somewhat more complicated than explained here