DNSSEC has seen a long road through development, but it has not been an easy task.  Adding security extensions to the this critical database that is basically the Internet address lookup table involves a lot  of time and effort from many organizations, from standard-setting to software implementation.

According to  Dan Kimball at dns.com, DNSSEC will not protect against all DNS attacks, nor will it replace existing security measures such as SSL… that is not its purpose.   DNSSEC addresses the weakness/flaws in the DNS protocol, and how it is applied in software and implemented is what is still being worked out.

ICANN, ISPs, Registries and Registrars, and third party application developers all have a stake in this, but a stake with very little monetary incentive and with potential unknown liabilities.  101Domain is fully committed to supporting DNSSEC on our networks, and are working to make a transparent implementation for our end users.  We currently provide a full suite of domain security products and will soon provide Brand Protection and a variety of full range SSL certificates.

Here follows a reprint of Mr. Kimball answering some DNSSEC questions:

What is holding back DNSSEC?

The biggest issues DNSSEC still faces in November 2010 are:

  1. We must define a standard for placing keys in DNS
  2. We must secure the “last mile” from the service provider’s DNS resolver to the end-user’s computer
  3. Unknown liabilities

The first issue is one of standard-setting which the Internet is quite familiar with. On the technical side, the community still needs to collectively decide what these DNS records look like.

The second issue requires building more functionality into end users’ software so that it can do cryptographic validation of DNS results instead of blindly trusting its upstream DNS resolver. Ultimately this has to be built into the “stub resolver” — which runs locally on your computer and asks for the results from the upstream resolver.

The question of liability over DNSSEC remains. With earlier methods to secure the Web, such as SSL, the liabilities were known and controlled.  With the current state of DNSSEC being run by ICANN and the registries, issues of liability have yet to be accepted, which leaves registrars on the hook for liabilities that are unknown and uncontrolled.

From a registrar’s point of view, they are expected to invest in building out an as yet undefined technical infrastructure for a product for which demand has not yet been demonstrated and will cannibalize existing revenues (SSL certificates) to incur unknown and uncontrolled revenues.

The current ICANN proposal for DNSSEC is still just a proposal. Before we have a system people can use there have to be technical standards, validation criteria and a business model. The DNSSEC  community has not developed the process for consumers and companies to utilize and implement it. This is comparable to purchasing a certificate without having the ability to put it on your website.

DNS.com has attended some of the discussions held by VeriSign and are participating in the IETF to promote useful adaptations of DNSSEC, such as Extended Service Description (ESRV) records, DNS resource records that provide information to applications attempting to establish a network connection.

Scope of DNSSEC protection

DNSSEC does not protect against the Kaminsky DNS vulnerability and BIND’s DNSSEC implementation itself is at risk from a cache-poisoning attack. Even if it is worked out what resolvers and applications should be doing when a signature verification fails, real world DNS will still be vulnerable against the far simpler and more frequent name-jacking attack and the difficult to defend against BGP layer attack.

There is an important purpose for DNSSEC that only DNSSEC can provide.  But that is not replacing a facility that the Web already has with one that provides less security than the weakest form of SSL currently deployed.

Have expanded DNS amplification attacks affected DNSSEC?

Attacks on internet are evolving (ie: new types). Changes open up opportunity for new attacks. DNSSEC addresses the protocol weakness/flaws in DNS protocol but not the application layer or how you implement it.

How long will it take for DNSSEC to trickle down to ISPs?

According to VeriSign and Forrester, 30% of ISPs will be DNSSEC enabled in 18 months. 70% are not quite there. For the entire ecosystem to get to a stable state, it will be a 5-7 year effort across the industry.

To enjoy the benefits of DNSSEC, does it require all of these implementations across ISPs, developers, etc.?

For it to be successful, most of the apps would need to ask for DNSSEC signatures. Most of the large domain registrants would have or support DNSSEC (in house or outsource). ISPs and application developers are the key item for success of DNSSEC implementation.

Who are the early adopters of DNSSEC?

Ecommerce companies are the most concerned about security. Financial services are also early adopters, as are ISPs, media, entertainment, and news.

Will there be a push for this app once implemented?

It is a chicken/egg problem, there is no incentive to implement if there is no market. If a fair portion of large domain registrants, ISPs, and applications support it then we will be on the way. It is not yet at the tipping point but more ISPs are announcing DNSSEC support. In the next 12 months we will see many more applications.