The Internet is about to get a lot safer
DNS, the Domain Name System, is one of the major pillars of the Internet. It’s a critical service, and without it we would all have to use IP addresses instead of handy domain names like “Pingdom.com” when we want to visit websites, send emails, and so on.
However, DNS has a huge flaw. Because DNS lacks security features it has been relatively easy for hackers to trick DNS servers with false information. By tricking DNS servers, hackers have been able to hijack entire websites. Needless to say, attacks such as these are a security nightmare and can be used for a large variety of malicious purposes such as site defacement, phishing, malware installations, and more.
For example, last December (on the 17th) visitors to Twitter.com were redirected to a completely unrelated website for over an hour. All because of compromised DNS servers.
In a step to counter these kinds of threats, a set of security extensions called DNSSEC have been developed. However, actually deploying these security extensions and making them part of the Internet’s DNS infrastructure has proven a long and arduous process with many delays. DNSSEC adoption today is in all practicality pretty much non-existent.
Now finally something big is about to happen.
DNS security, the story so far
DNSSEC stands for Domain Name System Security Extensions, and just as its name implies, it adds a layer of security on top of the otherwise unsecure DNS. DNSSEC protects the integrity of DNS data and makes sure that it comes from a verified source.
With DNSSEC, site owners like for example Twitter can certify that they are the true originator of the Twitter.com domain and are therefore a credible source, and end users looking up domain names can verify that the result they get back is from a trusted source (e.g. the real Twitter).
One of the main problems so far has been that for DNSSEC to be a practical viability, it needs to be incorporated in the root zone, in the DNS root servers of the Internet. They are the core DNS servers that all other DNS servers depend on, like the roots of a tree or the foundation of a building. This so far hasn’t been the case.
But next week, this important step is finally about to happen. Or rather, it will start to happen,
DNS security extensions in the root zone
Next week we will enter a testing phase where ICANN, the main organizing body of the Internet, and Verisign, the registry of .com and .net, start adding DNSSEC to the various DNS root servers on the Internet.
Since the root servers are so critical the rollout will be incremental and is planned to last well into May, with plenty of testing of the results in the meantime to make sure that there are no problems. After all, breaking the root zone would essentially break the entire Internet.
Fortunately there isn’t any one single point of failure. There are 13 sets of root servers, numbered from A to M. In total there are about 200 root servers, spread all over the world.
Above: Map of root server locations. (From root-servers.org.)
Providing the testing goes well, the security changes to Internet’s DNS root servers will be made permanent on July 1. At this point security in the root zone will be switched on and we will have taken a big step toward a more secure Internet.
This is actually Big News. There will still be a lot of work to be done to get the entire DNS infrastructure to properly support DNSSEC on all levels, and this will take time, but once DNSSEC is included in the root zone, DNSSEC adoption is predicted to get a huge boost.
Then what will happen?
Once DNSSEC is part of the DNS root zone, it will be easy for website owners to secure their own DNS settings (in a similar way to how they can use SSL certificates to make secure web pages, to use an analogy). This will make attacks such as the DNS hijacking of Twitter much more difficult.
Expect a large number of big websites to jump on the DNSSEC bandwagon soon after DNSSEC is in place in the root zone, making their domains secure. When a few big names are on board, the rest will follow (or at least that is the theory!).
This is good news for everyone, site owners and end users alike, and we wish ICANN and Verisign the best of luck with the DNSSEC deployment!
The New England Patriots held what seemed to be a commanding lead (17-15) with five minutes left of Super Bowl XLVI last night. But the New York Giants came back and managed to win with 21-17.
As Super Bowl 46 is approaching, fans will flock to the Lucas Oil Stadium in Indianapolis, Indiana, and to TV sets around the world to follow the New York Giants battle it out with the New England Patriots.
Every Friday we bring you a collection of links to places on the web that we find particularly newsworthy, interesting, entertaining, and topical. We try to focus on some particular area or topic each week, but in general we will cover Internet, web development, networking, performance, and other geeky topics.h
Out of the 
Pingdom’s Mobile Podcast is a weekly show about Internet, web, and mobile stuff. 
Jeremy Hitchcock
January 19th, 2010 at 1:43 pm
First, I am huge proponent of DNSSEC and think that it is a necessary DNS extension which will verify the validity of a DNS response from a DNS server. Dyn Inc, the company I work for, is a member of the DNSSEC Coalition, spearheaded by PIR. We have presented at ICANN and to registrars about DNSSEC adoption and implementation. Our Dynect Platform was the first (is still the only?) managed DNS platform to offer managed DNSSEC (automated key rotation, signing, etc.)
I do want to correct your assessment of the Twitter attack. The first write up I see (after seeing the TechCrunch article you linked to) can be found here: http://bit.ly/8ZGyC5 What is mentioned here will not be solved by DNSSEC as the attack was not related to cache poisoning. In fact, I haven’t been able to find any content that muses that DNS cache poisoning was at work here.
Perhaps this is a place to focus attention on a different type of problem that has involved DNS before (Comcast/Network Solutions: http://bit.ly/4LruEO )
Most online systems use email and a password for identification and authentication, respectively. Since forgotten passwords frequently occur (how many logins to websites do we each have online?), providers of such services offer a “forgot password” feature which will send either a link or the password to the address. This is done under the assumption that access to mail is secured only to the recipient intended.
This exposes a much bigger security question which happens to intersect online web application such as a DNS providers. When we use email for identification, what happens to the general model of identification and authentication, especially as we confuse the two? Mail is generally more accessible through a web interface (or still through POP/IMAP) which can be brute forced.
Attackers who access mail systems can look through archived mail and see what other systems their targets have used. A quick forgot password click and you immediately assume the identity of the target. It’s a security model that we should examine.
I’m all for cheering on DNSSEC but let’s get this right.
David Ulevitch
January 20th, 2010 at 9:01 am
The unfortunate thing about DNSSEC is not that it adds a ton of complexity to the DNS system, and is undoubtedly going to cause zone failures due to key management issues, No – it’s real flaw is that it fails to address the more important DNS security issues, which largely revolve around the registrar/registry level.
And when DNSSEC is deployed, expect Pingdom to start showing more downtime for DNSSEC-enabled zones.
James Galvin
January 20th, 2010 at 1:28 pm
I am strong proponent of DNSSEC. I work for Afilias, a global registry services provider. We are the service provider for PIR, the registry for the .ORG TLD. .ORG is the largest TLD to be signed and the first gTLD to be signed.
As Jeremy said above, the Twitter attack would not have been mitigated with DNSSEC. The public reports all say the name servers were hijacked. DNSSEC adds no additional security to a server. It is intended to protect the data itself, independent of its source.
The weak link in the event in question is to determine how the name servers were hijacked. That is where security needs to be improved, which is unrelated to DNSSEC.
Also, while the signing of the root will hopefully drive more TLDs to sign their zones and more domains with those TLDs to be signed, an equally important event necessary to the success of DNSSEC is for the signatures to be validated. This is most likely to happen at ISPs first, who should deploy validating resolvers for use by their customers. That is the group (after the root, registries, and registrants) that needs to be motivated in order for DNSSEC to be successful.
karlzt
January 21st, 2010 at 2:16 pm
hooray!
Czeslaw
May 16th, 2010 at 12:48 pm
Eee…it’s never for sure whit this safety.
اعلانات مبوبه
June 28th, 2010 at 5:46 pm
Also, while the signing of the root will hopefully drive more TLDs to sign their zones and more domains with those TLDs to be signed, an equally important event necessary to the success of DNSSEC is for the signatures to be validated. This is most likely to happen at ISPs first, who should deploy validating resolvers for use by their customers. That is the group (after the root, registries, and registrants) that needs to be motivated in order for DNSSEC to be successful.
Maurice Dono
September 26th, 2010 at 7:18 pm
I doubt this will have any real effect. Where there’s a will there’s a way and someone will find a way to defeat any protections put into place.