|
I think it's more likely that encryption will be used to support DNS than the other way around. The Domain Name System, designed to identify and locate Internet-connected devices, is a public database and inherently insecure. As long as DNS query requests and results can be intercepted or altered, the Domain Name System is unlikely to make a sound base for providing some form of support service for encryption.
Take DNS cache poisoning, for example. Attackers use this technique to trick a DNS server into believing it has received authentic information when, in reality, it has not. In fact, it's because DNS responses are not usually cryptographically signed that there are so many attack possibilities.
As the use of DNS outgrows its original purpose -- it's being used with an increasing myriad of Internet-connected devices from smartphones to kitchen appliances -- it is becoming more important that both DNS queries and responses are better protected. Yet securing DNS is proving difficult, as any changes have to be backwards-compatible with older systems and yet still scale to the size of the Internet. This and a lack of cooperation between major Internet players are why initiatives to improve the security of DNS, such as the Domain Name System Security Extensions (DNSSEC), have yet to be widely adopted (DNSSEC modifies DNS to add support for cryptographically signed responses).
Another approach to help validate DNS results is Forward Confirmed Reverse DNS (FCrDNS). FCrDNS checks that an IP address has both forward and reverse DNS entries that match each other. These entries are used to authenticate a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is strong enough that it can be used for whitelisting purposes. Because of a statistical correlation between machines that send spam and machines that fail FCrDNS check, spammers and phishers usually can't bypass this verification when they use compromised computers to forge the domains.
Even with encryption, a DNS server can become compromised by a virus or a disgruntled employee who could redirect the server's IP addresses to a malicious address with a long time-to-live (TTL) value. Every DNS server that cached the bad IP data would have to be manually purged, as a TTL can be set for as long as 68 years!
Then there's the problem of typos. How often have you misspelled the address of the website you want to visit but still ended up at a website? For example, paypal.com and paypa1.com are different domain names, yet users may be unable to distinguish between them, particularly if their typeface doesn't clearly differentiate the letter l and the number 1. This problem is even more serious in systems that support internationalized domain names, since many characters that are different, from the point of view of ISO 10646, appear identical on a typical computer screen. This vulnerability is often exploited in phishing.
As with most protocols used on the Internet, it is becoming imperative in the interest of security and privacy to prevent the disclosure of dialogues between the intended client and server. If a large number of popular name servers were to adopt strong cryptography, many attacks on DNS would be rendered useless. Even so, DNS would still be a long way off from the point where it is secure enough to be part of a cryptographic service.
More information:
Since researcher Dan Kaminsky notified the world about an amazing DNS exploit, numerous tools and attack techniques have emerged to take advantage of the flaw. John Strand explains how the DNS vulnerability has been weaponized.
Learn how to patch DNS vulnerabilities.
|
