This blog deals with lots of details on how DNSSEC can be rolled out, but should also touch upon why it is a good idea. It will be clear that rolling it out as a professional service is by no means straightforward, so the question is warranted what advantages it brings.
The common but unimaginary answer is that it thwarts the Kaminsky attack. This is an attack that can be used to fill a cache with DNS data that is falsified, for example to redirect website traffic or email to an attacker’s server. Kaminsky devised a practically achievable attack for which a pattern was long known to be theoretically possible: a cache poisoning attack. While it is absolutely necessary to overcome this problem in our modern internet with its many commercial and privacy-related uses, this is not the only benefit to be gained from using DNSSEC.
A general problem on the Internet is that we deal with remote parties that we may never have met before. This generally raises concerns of trust in such a person. There are parties that believe that assured identities can solve these matters, but if you ever tried to talk to the police about arresting a distant crook who somehow fooled you into an illegal trick, you will know that this is not the real answer.
Of course there are some situations where online identities are grounds for trust; you might trust someone with an email-address under sec.gov with financial details that you would not freely share with others; you might send your credit card information to amazon.com but not just anywhere, and so on. Online identities such as domain names can be useful to gain trust in a distant person, even if you never spoke to such a person before. But even then, we need ways of establishing that a person represents a domain that we trust.
The general challenge in first-contact situations over a distance is to establish a secure link. For instance, how to be sure that an email came from the domain it said to come from, or how to send an encrypted email that can only be read within that domain. To do that, cryptography can help, but only after getting hold of a public key that is somehow linked to that domain.
The current approach for this is reliance on trusted third parties which are paid quite a bit of money to establish the identity and domain ownership of the party you never met. Unfortunately, to reduce the cost of such services, they often rely on mechanisms that are susceptible of traditional fraud, so it is not very reliable. In the end, even a trusted thrid party often boils down to legal or moral grounds of trust; this simply is the best that we currently have.
But then DNSSEC enters the scene. What it does is sign the content that any domain owner can publish in their own zn, with trust links from the root down. The path from the root to a privately owned domain traverses infrastructure that is maintained by technicians, not commercial-grade performers. These technicians already have ways of establishing domain ownership, and are therefore rather attractive trusted-party role players.
What remains to be done now is to publish information securely in DNS, sign it with DNSSEC and setup client software to use that as a trust foundation. A few highly appealing things have already been standardised.
- There is an SSHFP record that stores a server’s Secure Shell fingerprint. This adds value because it avoids the single weak point in the SSH protocol, namely first access between a client and server machine. When properly maintained, SSHFP can make the security of SSH absolute. And quite interestingly, it is already very powerful when used internally in a company!
- There is a CERT record that can store identity information falling under a domain. Both X.509 and OpenPGP certificates are possible. Although there currently does not seem to be a mechanism to use this for trust in self-signed server certificates, this is definately possible. Plus, given the abundance of IP addresses that the future has in store with IPv6, secure servers can easily become the default practice of tomorrow’s Internet!
- There is an ENUM infrastructure to store personal contact information under one’s phone number. Such details should not be sidetracked, for risk of tapping your conversations. The obvious answer to protect against that is DNSSEC.
I’m sure this is just the beginning. DNSSEC may not be pretty on a bit level (but then again, what part of DNS is?) but at least it brings us fundamentally new possibilities. If you are not satisfied with “just” solving the ability of attackers to sidetrack your domain, then there are plenty of places where the overall security of your online operations benefit from the introduction of DNSSEC. Beating the Kaminsky attack is a must, but there is enough to make DNSSEC worthwhile on its own account. DNS is everywhere, so protecting it through DNSSEC has a lot to offer to all of us net-savvies.