How DNSSEC Dethroned DNS!

Here's a behind the scenes peek at how vulnerable the trusted Domain Name System really was! And what we can expect from its successor.
DNS, the good old domain name system protocol, is undergoing a major change. What has worked well for thirty years is now vulnerable and no longer safe. DNSSEC (domain name system security extensions) is a new protocol that verifies DNS messages with a digital signature. A new consortium, the DNSSEC Industry Coalition, has been formed recently to work hard for wider adoption of this new protocol MCTS Training.

But, DNSSEC is not new--in the sense that it was not conceived recently. It was developed more than 14fourteen years back, but never gained popularity due to the increased overheads and additional processing needed, and the complexity involved. Additionally, there was no real need to adopt it. But, an accidental discovery last year, of a fundamental flaw in the design of the basic DNS protocol, resulted in the revival of DNSSEC. Though the flaw in DNS was fixed, it was felt that it is only a short-term solution and DNSSEC would be the best way forward.

Knowing DNS
The domain name system maps the URLs (uniform resource locator) to the IP (Internet protocol) addresses. When a user types a URL, the request is processed by the Web server. If that Web server has the IP address corresponding to that URL (retained from an earlier request by another user), then it directs the request to the server with that IP address; else, it directs the request to a name server (which maintains the IP addresses for different URLs) maintained by the ISP (Internet service provider). If this name server also does not have the IP address, then it contacts the 13 DNS root servers, one of which will direct the request to the name server that handles the top-level domains, like .org or .net. That server in turn forwards the request to the server specific to a single domain name, such as npr.org. This forwarding continues until a server that has the IP address corresponding to the complete URL is found. If no server has the IP address, then the message, "Address not found" is sent as the response. Paul Mockapetris developed this system in 1983.

The flaw that unseatedttled DNS
Dan Kaminsky, who was the then director of penetration testing at IOActive, a company in Seattle that specialises in security related problems, was researching a good way to stream videos. It was pure serendipity that a flaw in DNS was exposed.
Each name server keeps the IP address corresponding to a URL for a specified time (known as Time To Live or TTL) in its cache. Large sites have multiple servers distributed across the globe so that users are directed to the content server nearest to them. Kaminsky wanted to bypass the TTL value and have the server request an IP each time, so that different Web servers would respond and load would be balanced. It was during this ‘experiment' that he found that bypassing TTL would expose DNS to many types of attacks. Kaminsky demonstrated that it would give attackers nearly infinite chances to redirect requests intended to a legitimate server, to their own fake servers. Apart from this, the fact that almost every network uses DNS made this vulnerability extremely serious and warranted an immediate solution MCITP Certification.

The fix for the flaw
There is an interesting history behind how this very dangerous vulnerability was fixed. After discovering it, Kaminsky immediately contacted Paul Vixie, president of the Internet Systems Consortium. Both of them secretly convened a meeting of top DNS experts in the world at the Microsoft headquarters in Redmond. This team included experts from the US government, and major hardware and software manufacturers such as Cisco. It was so secretive that in Kaminsky's own words, "There were people on jets to Microsoft who didn't even know what the bug was." The group discussed the vulnerability and the method to fix it. They also decided to release the patch on July 8, 2008. It was only about a month later that Kaminsky spoke publicly about the flaw at the Black Hat Conference in Las Vegas on August 6, 2008.

The rise of DNSSEC!
Though the flaw was fixed, it was not considered a long-term solution. Hence, DNSSEC was adopted. It involves using digital signatures to verify DNS messages. Here is what it entails and how it works. DNSSEC, which that stands for DNS Security Extensions, ensures both the authenticity of the server responding to the DNS request and the integrity of the data while in transit. To achieve this, the basic DNS protocol has been modified with four new resource records (RR).

RRSIG - Resource Record Signature
DNSKEY - DNS Public Key
DS - Delegation Signer
NSEC - Next Secure

Two header flags have also been added.

CD - Checking Disabled
AD - Authenticated Data

RFC 3833 describes the DNS and the threats to it along with DNSSEC. Most importantly, DNSSEC does not ensure confidentiality of data. It does not encrypt the data. Also, DDOS attacks are not prevented by this extension.

The public Internet registry maintains the .org domain. It is committed to implementing DNSSEC across all URLs that end with the suffix .org. The US government has also decided to use DNSSEC for all domains ending with .gov. With this kind of commitment, DNSSEC is soon to gain ground and become widely used.