I subscribe to the fundamental tenets of Greg Ness’s Infrastructure 2.0 postulate: That core network services will become more strategic, and that these services must become more dynamic and better automated to support next-generation information technology. But every time I read about Infrastructure 2.0, I worry about DNS and the other protocols that underpin our networks.<\/p>\n
These protocols, as nearly everyone knows, were designed in the Dark Ages of the Internet, before DHCP and WiFi and Dan Kaminsky. It’s a tremendous credit to the adaptability and scalabilty of their original designs that DNS and its kin can support today’s global Internet. At the same time, it’s required a small army of dedicated protocol engineers working within the IETF to create the modern version of DNS, with its dynamic updates and signed zone transfers.<\/p>\n
But many of us in the DNS community believe that we’ve reached a critical point in the evolution of DNS. The recent Kaminsky vulnerability reinforced what some of us already knew: That there are fundamental, protocol-level security weaknesses in DNS, and these threaten the integrity of every DNS transaction. While we managed to buy ourselves time through clever coding, those deficiencies remain. And the only proven defense we have in our arsenal – our nuclear option, if you will – is DNSSEC, the DNS Security Extensions.<\/p>\n
DNSSEC leavens DNS with asymmetric cryptography, allowing suitably configured and upgraded DNS resolvers to validate data they receive from remote name servers. With DNSSEC, you can trust your naming service again.<\/p>\n
This matters because, in the absence of DNSSEC, Cloud Computing is an unparalleled opportunity for hackers to siphon off critical data or disrupt your business by redirecting you to a foreign cloud, a hostile nimbus.<\/p>\n
So why isn’t everyone discussing Infrastructure 2.0 talking about DNSSEC as a prerequisite? Wouldn’t it be folly to build our Castle of Cloud Computing on sand?<\/p>\n