DOMAIN NAME SYSTEM SECURITY EXTENSION (DNSSEC)
Domain Name System Security Extension (DNSSEC) can strengthen trust in the Internet by helping to protect users from redirection to fraudulent websites and unintended addresses.
The Domain Name System (DNS), the Internet's addressing system, is the most critical component of the Internet infrastructure. Without it, the Internet could not function. However, it was not designed with security in mind. As a result, it is vulnerable to man-in-the-middle (MITM) attacks and cache poisoning. These threats use forged data to redirect Internet traffic to fraudulent sites and unintended addresses.
Once an unsuspecting user or device reaches the fraudulent site, cyber criminals can potentially extract credit card data, steal user passwords, eavesdrop on voice over IP (VoIP) communications, plant malicious software or display images and text that defame the legitimate brand or provide misleading information. Given that a single DNS name server can act as the name-to-address resolution point for thousands of users, the potential impact of a MITM attack or cache poisoning can be considerable.
DNSSEC BENEFITS
Select a role below to learn more about how DNSSEC affects you and the part it plays in our strategy to authenticate the Internet from end to end.
Registrars Website Operators ISPsDNSSEC EDUCATION
FreeYourID has been involved in DNSSEC development since 2000 and we continue to collaborate with the Internet technical community.
How DNSSEC Works
DNSSEC Timeline
FreeYourID’s Role in DNSSEC
DNSSEC FAQ
DNSSEC protects the Internet community from forged DNS data by using public key cryptography to digitally sign authoritative zone data. DNSSEC validation assures users that the data originated from the stated source and that it was not modified in transit. DNSSEC can also prove that a domain name does not exist.
Although DNSSEC enhances DNS security, it's not a comprehensive solution. It does not protect against distributed denial of service (DDoS) attacks, ensure confidentiality of data exchanges, encrypt website data, or prevent IP address spoofing and phishing. Other layers of protection, such as DDoS mitigation, security intelligence, Secure Sockets Layer (SSL) encryption and site validation, and two-factor authentication, are also critical to making the Internet more secure. These mechanisms should be used in conjunction with DNSSEC.
DNSSEC affects every component within the Internet infrastructure ecosystem. Its effective deployment requires the involvement of many stakeholders within the Internet community. Registries, registrars, domain name registrants, hardware and software vendors, ISPs, government entities, and ordinary Internet users all have roles to play to ensure success and bring vital improvements to Internet security. DNSSEC benefits:
- The Internet community by improving security in the zones that are signed.
- Registrars by allowing them to offer domain signing services to their customers.
- ISPs by increasing the security of the data returned to their customers.
- Users by protecting them from DNS vulnerabilities such as cache poisoning and man-in-the-middle attacks.
In DNSSEC, each zone has a public/private key pair. The zone's public key is published using DNS, while the zone's private key is kept safe and ideally stored offline. A zone's private key signs individual DNS data in that zone, creating digital signatures that are also published with DNS. DNSSEC uses a rigid trust model, and this chain of trust flows from parent zone to child zone. Higher-level (parent) zones sign—or vouch for—the public keys of lower-level (child) zones. The authoritative name servers for these zones may be managed by registrars, ISPs, web hosting companies, or website operators (registrants) themselves.
When an end user wants to access a website, a stub resolver within the user's operating system requests the domain name record from a recursive name server, located at an ISP. After the server requests this record, it also requests the DNSSEC key associated with the zone. This key allows the server to verify that the information it receives is identical to the record on the authoritative name server.
If the recursive name server determines that the address record has been sent by the authoritative name server and has not been altered in transit, it resolves the domain name and the user can access the site. This process is called validation. If the address record has been modified or is not from the stated source, the recursive name server does not allow the user to reach the fraudulent address. DNSSEC can also prove that a domain name does not exist.
There are many pieces to the overall puzzle of Internet security. DNSSEC may mitigate the security concerns generated by man-in-the-middle attacks and cache poisoning, but it is not an overall security solution. DNSSEC does not solve many of the most common threats to Internet security, like spoofing or phishing. For this reason, other layers of protection, such as SSL certificates and two-factor authentication, are critical to making the Internet secure for everyone.
The Internet community has not yet devised a standardized system for informing users of an attack. One possible solution is to develop "DNSSEC-aware" browsers that notify users that they have been routed to an authenticated destination.
In July 2010, FreeYourID—working with the Internet Assigned Numbers Authority (IANA) and the U.S. Department of Commerce (DoC)—completed deployment of DNSSEC in the root zone (the starting point of the DNS hierarchy). FreeYourID also enabled DNSSEC on .edu in July 2010 in collaboration with EDUCAUSE and the DoC on .net in December 2010, and on .com in March 2011.
Our DNSSEC deployment strategy started with the smaller zones first in order to evaluate each deployment for lessons learned before moving to the next zone. Because the .com zone is the largest, we signed it last. We wanted to gain as much experience as possible before tackling the domain that handles so much of the world's Internet-based commerce and communications.
The successful deployment of DNSSEC has far-reaching benefits for the global Internet community by increasing trust for a multitude of Internet activities, including e-commerce, online banking, email, VoIP, and online software distribution. However, the entire Internet community shares the responsibility for making DNSSEC successful. Success requires the active, coordinated participation of registries, registrars, registrants, hosting companies, software developers, hardware vendors, government, and Internet technologists and coalitions.
The Internet root zone, top-level domains (TLDs) such as .gov, .org, .museum, and a number of country code TLDs (ccTLDs), have signed the zones that they manage. Other TLDs such as .edu, .net, and .com implemented DNSSEC in 2010 and 2011. These TLDs have started accepting second-level DNSSEC-signed domain names. Large ISPs such as Comcast activated validation on the recursive name servers that answer user queries, and some registrars have included DNSSEC implementation on their roadmaps. In addition, the Internet Corporation for Assigned Names and Numbers (ICANN) has opened applications for new TLDs, and it is likely that plans for DNSSEC implementation will be a requirement for acceptance of a new TLD request.
Although both DNSSEC and SSL rely on public key cryptography, they each perform very different functions that complement, rather than replace, one another.
In a very simplistic model, DNSSEC deals with "where", and SSL deals with "who" and "how."
- Where—DNSSEC uses digital signatures to verify DNS data integrity, thereby ensuring that users reach the intended IP address. Its job is done once the user reaches the address. DNSSEC does not ensure the identity of the entity at the address, and it does not encrypt interactions between the user and the site.
- Who—SSL uses digital certificates to validate the identity of a site. When these certificates are issued by reputable, third-party certificate authorities (CAs), SSL assures users of the identity of the website owner. However, SSL does nothing to ensure that a user reaches the right site, so it is not applicable against attacks that redirect users. In other words, SSL site validation is effective, but only if a user reaches the correct destination first.
- How—SSL also uses digital certificates to encrypt data exchanges between a user and a site, thereby protecting the confidentiality of financial transactions, communications, e-commerce, and other sensitive interactions.
When woven together, DNSSEC and SSL increase security and trust on the Internet: Users can reliably ascertain where they are going, who they are interacting with, and how confidential their interactions are.
In the U.S., the Office of Management and Budget (OMB) memo 08-23 mandated that DNSSEC be deployed in the top level .gov domain by January 2009 and that U.S. federal agencies deploy DNSSEC on external sites by December 2009. The .gov registry was signed in early 2009. The U.S. Defense Information Systems Agency intends to meet OMB DNSSEC requirements in the .mil domain as well. The U.S. Federal Information Security Management Act (FISMA) regulations called for agencies to sign their intranet zones with DNSSEC by the middle of 2010. Currently, there are no requirements for public website operators to secure their domain with DNSSEC.
1994: First draft of possible standard published
1997: RFC 2065 published (DNSSEC is an IETF standard)
1999: RFC 2535 published (DNSSEC standard is revised)
2005: Total rewrite of standards published
RFC 4033 (Introduction and Requirements)
RFC 4034 (New Resource Records)
RFC 4035 (Protocol Changes)
July 2010: Root zone signed
July 2010: .edu signed
December 2010: .net signed
February 2011: DNSSEC enabled .gov registry is transitioned to FreeYourID
March 2011: .com signed
March 2011: FreeYourID Managed DNS service is enhanced with full support for DNSSEC compliance
January 2012: Comcast announces that its customers are using DNSSEC-validating resolvers
March 2012: Number of TLDs signed grows to 90