EPIC - DNSSEC (original) (raw)

• Overview |
• Complexities |
• |
• Resources

Top News

• Google Expands Control of Internet Architecture: Google has announced Google Public DNS, which will route all requests for internet addresses, a core Internet function, through Google's servers. These requests would normally only pass through the servers of the users' internet service providers. Google's DNS service does not use the new authentication standard DNSSEC, but instead uses a proprietary security method. By tradition, DNS is a distributed function, subject to an open standard-setting process. For more information, see EPIC DNSSEC. (Dec. 8, 2009)
• Rod Beckstrom to Head ICANN : The Internet Corporation for Assigned Names and Numbers appointed Rod Beckstrom as its new CEO and president. ICANN manages the administration of the internet including assignment of domain names, IP addresses, preserving operational stability, and developing policies. Beckstrom is an author, entrepreneur, non-profit board member, and expert in decentralized organizations. He resigned as the Director of the National Cybersecurity Center in March 2009 warning of the increasing role of the National Security Agency in domestic security. See EPIC DNSSEC, EPIC WHOISand The Public Voice. (Jun. 29, 2009)
• Two US Government contractors and the National Institute of Science and Technology have released a white paper, "Statement of Needed Internet Capability," detailing possible alternatives and considerations for a Trust Anchor Repository (TAR) to support DNSSEC deployment. The document was released through the DNSSEC-Deployment Group this week with a request that it be circulated as widely as possible to gather feedback. Read more on the IPG blog. (June 13)
• Trust Anchor Repository white paper to be released at ICANN Paris: The DNSSEC Deployment Coordination Initiative expects to disseminate a white paper titled Statement Of Needed Internet Capability: Trust Anchor Repositories as part of the June 25 DNSSEC session scheduled for the ICANN meeting in Paris. (June 12)
• The ICANN Registry Services Technical Evaluation Panel (RSTEP), a committee of technical experts, released its report on PIR's proposal. The Internet Governance Project (IGP) blogs that the report points both at the technical and the political risks of implemting DNSSEC for the .ORG zone. They conclude that most of the risks stem from the fact that the rootzone is not signed. IGP points at the US government's insistence on maintaining control of the root zone file as one of the reasons why the root zone is not signed. Another risk that IGP points at is the increased complexity because of the compulsory vertical separation of registrar and regisrty functions. (June 9)
• EPIC Supports New Internet Privacy Standard. EPIC has expressed support for the DNSSEC proposal now under consideration at ICANN. The DNS security extension should help protect users from attempts by hackers to spoof, masquerade and hijack websites. The Public Interest Registry proposed to implement DNSSEC for the .ORG domain. DNSSEC is already in use by the top-level country code domains of Sweden, Bulgaria, Brazil and Puerto Rico. See EPIC Page on DNSSEC. (May 26)
• ICANNs announces the Request for Comments for Public Interest Registry (PIR)'s proposed implementation of DNS Security Extensions (DNSSEC). ICANN will accept comments until May 24 2008. (April 28, 2008)

Overview

What is DNSSEC?

The Domain Name System (DNS) is a distributed hierarchical system used by servers that use the Internet Protocol (IP)to convert IP adresses (such as 85.135.343.120) into names and vice versa. Web browser, FTP clients and mail clients use DNS so end user don't have to type in IP adresses but can just use 'www.epic.org'. However, DNS was never designed to be secure. This gives rise to a set of problems which originate from the fact that a request for a domain name to a server is not authenticated. This means that any server can pretend to be a Domain Name System Server. Most users of the Internet use their default DNS server from their ISP. Hackers can divert the traffic from this server to another DNS, which can direct you to malicious websites. Without the end user noticing, he or she can be directed to malicious websites that ask him for personal credentials, so-called phishing.

DNSSEC was developed by the Internet Engineering Task Force (IETF) to overcome these problems. Authentication of responses is the main mechanism that provides security in DNSSEC. When a client (Internet resolver) is requesting the domain name for an IP address, DNSSEC foresees in sending a reply with a signature. With this signature, the client can authenticate the message.

Use of DNSSEC in Sweden, Bulgaria, Brazil and Puerto Rico

DNSSEC has been implemented in Sweden, Bulgaria, Brazil and Puerto Rico. In Sweden DNSSEC was part of a pilot program by the Swedish registry of ICANN to implement DNSSEC as a commercial service. Participants were the Ministry of Enterprise, Energy and Communications, the registry of .SE, Swedish ISP TeliaSonera, Swedish bank Swedbank group and the Swedish National Post and Telecom Agency.

A survey amongst top-level domain owners in Sweden showed that the biggest barrier for DNSSEC is adoption. Only 14% of the top-level domain owners said that DNSSEC is very interesting as a commercial service and 54% indicated that a 50-euro annual charge was rather high. Furthermore, the biggest Swedish ISP pointed out that DNSSEC could be a waste of resources if the hosting of websites is DNSSEC but the pointers to those websites (the DNS resolvers) are not supporting DNSSEC. As most Internet users only use the resolvers provided by their (domestic) ISPs this means that adoption by these ISPs forms a bottleneck.

Use of DNSSEC for the .ORG domain

After the implementations of DNSSEC in Sweden, Bulgaria, Brazil and Puerto Rico ICANN has announced a Request for Comments on implementing DNSSEC on the Public Interest Registry's. This means that all the .org domains would be fitted with the DNSSEC extension. As of March 15 2008, only one comment has been placed on the forum of ICANN.

Complexities

Technical complexities

• DNSSEC forces the exposure of information that by normal DNS best practice is kept private. DNSSEC reports with an authenticated message that a certain name doesn't exist. It was designed top report a signed message that a range of names doesn't exist. As Justin Fielding notes: "Even if no confidential data is stored in the DNS records, knowing which hostnames exist and which do not can greatly aid an attacker in mapping a remote network." NSEC3 was developed to overcome this problem and is now being used with DNSSEC.
• Devising a backward-compatible standard that can scale to the size of the Internet.

Social complexities

• Many players are interested in deploying DNSSEC at the root zone, as this would increase security on top-level domains. The opinions differ on who should guard this master key at the root zone. The US Department of Homeland Security has shown interest in the master key, but many others are sceptic about this option.
• The DNS system consists of both resolvers (find the DNS data for a DNS name) and hosts (those that publish DNS data for a domain name). The pilot in Sweden has shown that DNSSEC is only of value when both the hosts and resolvers deploy DNSSEC>
• The pilot in Sweden has shown that top-level registrars are not willing to pay 50 euros a year for DNSSEC. The implementation of DNSSEC has proven to be pricely and it is difficult to develop an viable business model and pricing strategy. Sweden proposed a skimming strategy: setting the price high and lowering it to increase demand.

Resources

General

• DNSSEC Deployment Initiative website
• Wikipedia on DNSSEC: history, controversies and deployment.
• The Internet Governance Projects weblog on DNSSEC.
• Overview of DNSSEC from ICANN New Delhi meeting. (Febuary 2008)
• RFC4035: Protocol Modifications for the DNS Security Extensions (March 2005)
• RFC4034: Resource Records for the DNS Security Extensions (March 2005)
• RFC4033: DNS Security Introduction and Requirements. (March 2005)
• Threat Analysis of the Domain Name System (DNS). (August 2004)

Technical complexities of DNSSEC

• Technical analysis of DNSSEC security with graphical depictions. (April 2007)
• The Internet Society Task Force (IETF) memorandum on DNS Security Introduction and Requirements. (March 2005)

Policy implications of DNSSEC

• Securing the Root: A Proposal for Distributing Signing Authority. The Internet Governance Projects proposal for distributing the signing authority. (May 2007).
• Department of Homeland Security wants master key for DNSSEC. (March 2007)

Other coverage

• NLnet Labs, a Dutch research and development group that focuses on those developments in Internet technology where bridges between theory and practical deployment need to be build, has a website on implementing DNSSEC in the Netherlands' .NL domain.
• Justin Fielding from TechRepublic on DNSSECs technological and policy implications and controversies. (April 2007)
• Experience with DNSSEC in Sweden and Bulgaria: meeting proceedings. (28 March 2007)
• Paul Vixie, father of the Domain Name System, on DNSSEC. (December 2006)

Share this page:

Subscribe to the EPIC Alert

The EPIC Alert is a biweekly newsletter highlighting emerging privacy issues.

EPIC Alert archive »