If you work with DNS, you certainly have heard of DNSSEC – Security extensions to the DNS protocol which add cryptographic validitity to the answers a nameserver may provide. In other words, you can trust that the answer you receive is from the place it was supposed to come from — which adds data origin authentication and data integrity to the Domain Name System (DNS) and protects users from DNS protocol attacks. But how, exactly, did it come to be?
As early as 1990, DNS experts were aware of a problem: computers inherently “trust” DNS to provide the correct information that they use to make connections. Unfortunately, the way the DNS protocol was originally crafted it was relatively simple to spoof a hostname within DNS. Therefore, it was possible for someone to maliciously direct computers to connect to the wrong site. To address this problem, the IETF set up a working group (http://datatracker.ietf.org/wg/dnssec/charter/) to work on the problem. Papers were written, debates were held. The results were documented in recommendations in protocol enhancements in 1997 (http://tools.ietf.org/html/rfc2065) and refinements continue through today (http://tools.ietf.org/html/rfc5155). (You can find a more exhaustive summary of this effort on Wikipedia (en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)
Adoption of DNSSEC has been very slow. The protocol was maturing. Server and client software had to be updated. The DNS infrastructure had to be cryptographically signed from the top-down for the security to work. Furthermore, until more automated tools became available, many administrators were hesitant to adopt a feature that required extensive protocol knowledge, understanding of cryptography and the operational effort of keeping ahead of signature expiration and key-rolling schedules. One of the first users to adopt DNSSEC as a bloc has been US Federal Agencies. The US Federal Government Office of Management and Budget (OMB) pushed the adoption of DNSSEC by mandating that all US Federal Agencies that use the .GOV namespace must protect their .GOV domains with DNSSEC. To date, we are now beginning to see adoption by financial institutions and e-commerce companies.
Here at Neustar, our Registry and UltraDNS teams have worked with the Internet Engineering Task Force (IETF) on the development of DNSSEC standards and related changes and updates since 2008. In that time we have supported DNSSEC zones for several TLDs, ccTLDs and over 50 SLD customers, including a large number of organizations within the .GOV namespace.
As you may know, UltraDNS is a proprietary DNS resolver that has been developed from the ground up for speed and security. In 2010, we completed testing of DNSSEC on our SecureDNS test platform. With that experience, we are now rolling out DNSSEC features into our premium UltraDNS anycast production environment. In the meantime, check back at http://www.neustarregistry.biz/services/dnssec-and-neustar for updates.