The Internet runs on DNS. More specifically, DNS (Domain Name System) is the protocol by which machine-friendly 32-bit IPv4 (ex: and 126-bit IPv6 (ex: 2002:4A7D:E291:0:0:0:0:0) addresses are translated into human friendly representations like Paul Mockapetris wrote and implemented the earliest official version of DNS in 1983 and the original specifications were published as IETF RFCs 882 and 883. If you’re thinking that 1983 seems like a very long time ago in Internet years, you’re right. Back in the early 80s, security and misuse controls were not the top of mind considerations – getting it to work well and reliably in a normal use, hierarchical, distributed environment was. But as use of inter-connected networking grew into what is known as today’s Internet, problems began to arise with the security and vulnerability of the DNS protocols.

What Can Go Wrong?

The purpose of DNS is to shield humans from having to remember long numerical addresses and it does that very well. When was the last time you entered in rather than into your browser when you wanted to check the headlines at MSNBC? But that’s also one of the reasons why tampering with DNS can be so insidious: we implicitly trust that the translation has been done correctly. If an attacker has hijacked or poisoned the DNS and the browser is re-directed to a rogue site, how will a user know? One easy way is if the attacker redirects traffic to a site that doesn’t actually look like the target site. But attackers can use tools like WGET to copy an entire site and stand up a perfect duplicate on their own servers.

In other words, if you type into your browser and you get a page that looks like regular login page, but asks you for information like your SSN or Mother’s maiden name to “register your PC,” would you be suspicious or just assume that your bank needed to re-register your machine? Even if the site is not a duplicate of the expected site, but is otherwise compromised (for example, if the rogue site is infected with drive-by download software) just visiting it could cause an infection Tampering with DNS can also wreak havoc on private or internal networks sending employees or partners to attacker versions of corporate intranet portals and partner pages.

Some attacks use “traffic control” as a way to force victims to do what the attacker wants. In the case of some fake anti-malware, for example, attackers limit the user’s ability to surf to search engines so they cannot look up information about the fake anti-malware that is displaying a “Warning Your PC is Infected!” screen on their device.

And there’s always the Denial of Service (DoS). In the DoS attack scenario, the user is not redirected to a rogue site, but is instead sent into the equivalent of an Internet dead end. This attack can be particularly frustrating because the basic network connection can appear to be functioning normally, while sites aren’t responding normally, leaving the user to wonder if the site is down or something else is wrong.

How DNSSEC Can Help

The core issues underlying DNS insecurity are lack of trust (including mutual authentication), integrity, and availability. Trust relates to whether or not the information received is coming from a trusted/reliable source or not. Integrity speaks to maintaining the validity of the data where it is stored and when it is updated, as well as tamper-proofing during transmission of a query response. Availability includes whether or not the service is able to respond – if a DNS server can’t answer the query, the machine’s numerical address can’t be mapped and a DoS occurs.

One proposed solution to some of the security issues with DNS is a series of IETF specifications known as the DNS Security Extensions (DNSSEC), currently IETF RFC 2535). This was first introduced in November 1993 “at the 28th IETF meeting in Houston.” The core strategy was to use digital signatures to provide data integrity and data origin authentication for DNS queries, but it did not include mutual authentication for changes to DNS records or controls to mitigate availability issues. IETF RFC 3833, “Threat Analysis of the Domain Name System (DNS)” provides a comprehensive overview of the specific vulnerabilities and exposures in DNS that DNSSEC attempts to mitigate.

Page 2: What the Heck is DNSSEC?