The Internet runs on DNS. More specifically, DNS (Domain Name System) is the protocol by which machine-friendly 32-bit IPv4 (ex: 220.127.116.11) and 126-bit IPv6 (ex: 2002:4A7D:E291:0:0:0:0:0) addresses are translated into human friendly representations like www.google.com. 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 18.104.22.168 rather than www.msnbc.com 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 www.yourpersonalbank.com 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.https://o1.qnsr.com/log/p.gif?;n=203;c=204660766;s=9477;x=7936;f=201812281312070;u=j;z=TIMESTAMP;a=20392931;e=i
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.
DNSSEC works by signing domains (including root and top level) and zones using public/private key cryptography, thereby creating a chain of trust. Note that to be backwards compatible with non-DNSSEC enabled servers and clients, queries are completed using standard DNS when DNSSEC is not available. In other words, when DNSSEC is not available throughout the entire chain - from requestor client to resolver/caching nameserver to authoritative nameservers - the system reverts to regular DNS. However, if DNSSEC is available throughout the chain, the client has a level of assurance that the DNS query response is signed and trustworthy starting from the root and chaining all the way down to the domain and subdomains. The following illustration provides a high-level overview of DNSSEC in action:
DNSSEC is one way to improve the overall security of DNS. But before you going running off and planning for full implementation of DNSSEC at your organization, note that there are some criticisms and caveats. Because DNSSEC was designed to respond with complete, signed, authoritative information about a domain or sub-domain, it does not work well with traditional split (or split-horizon) DNS architectures. In split DNS architecture, some machine information is available to all requestors while other information, such as servers with highly sensitive data that should be accessible only from the trusted internal network and not from the Internet, is kept private. Since DNSSEC makes previously private information public, it opens zones up to enumeration/walking exposures which allows attackers to use DNSSEC information to determine a definitive list and map of hosts in a zone. To mitigate this issue, the extension DNSSEC Hashed Authenticated Denial of Existence (a.k.a. NSEC3) was introduced in 2008, but is not yet in wide use.
As noted earlier, if DNSSEC is not used and supported throughout the entire chain, the system reverts to standard DNS. So an organization that spends time and money to support DNSSEC on their own clients and servers may still be getting mostly standard DNS responses for sites and hosts outside of their organization. Since DNS trust starts at the top, a positive step forward in the US occurred on July 15, 2010, when the signed root zone became publicly available. But DNSSEC is still a ways from being a no-brainer deployment option. While full deployment would increase the reliability and robustness of the DNS infrastructure – without widespread adoption utility will be limited.
Diana Kelley is a partner at IT research and consultancy firm SecurityCurve and a frequent contributor to eSecurityPlanet.com.