Additional Security

Of course, DNSSEC cannot replace other security measures, such as VPNs or public key infrastructures. Public PKIs manage certificates signed by acknowledged CAs. And if SSL/TLS use is based on this technology, the level of authenticity and trust is far more than DNSSEC can hope to offer. DNSSEC is particularly useful for protecting users who would accept untrusted certificates.

Strengths and Weaknesses

Setting up a chain of trust with DNSSEC is fairly easy, but managing one is more difficult. All the stakeholders – from the root to the last zone delegated by it – need regularly updated keys if the resolver is to work correctly.

The NSEC records make it possible to read all the records in a zone with zone-walking techniques. Because the developers of DNS designed the protocol to be open and freely accessible, they deliberately did not design DNSSEC for confidentiality. On the other hand, confidentiality is an unequivocal data protection objective.

Many registrars view zone walking as a data protection problem. The NSEC3 draft details a potential solution to the problem that relies on encryption. Skeptics question whether publicly resolvable DNS names are worth protecting; although they see the problem of unauthorized persons systematically listing zones, they object that other measures provide more in the line of data protection and trust. They include Access Control Lists and client authentication, but do not extend to freely available DNS records. Of course, the decision will be influenced by your company's security policies. Experts say that another issue preventing the introduction of DNSSEC is that a DNSSEC name server's cryptographic processes put twice as much load on the infrastructure as a normal server.

Conclusions

As is so often the case, politics also plays a role. The question of who manages the private key in the root zone is still open. On the one hand, RIPE and other registrars have asked the Internet Corporation for Assigned Names and Numbers (ICANN) to sign the root zone as soon as possible; on the other hand, some people worry about handing complete control of the private key to a US authority.

Many people regard the root zone server as the last line of defense against state intervention, and it is understandable that they do not want to place the root zone behind a private key. Global discussions have not prevented private zone administrators from testing and introducing DNSSEC. Most private zones are not affected by the NSEC data protection issue because they only contain www, mail, and other public records.

If they publish the KSK centrally – in a DLV registry, for example – third parties can use DNSSEC without any trouble.

Where personal data is at stake, as in online banking or shopping, providers can boost trustworthiness by creating a DNSSEC-protected zone.