Trusted name resolution with DNSSEC

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.


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.


  1. Multiple standards documents specify DNSSEC: RFC 4033 (Intro), RFC 4034 (Records), RFC 4035 (Protocol), and RFC 3658 (DS):
  3. ISC name server:
  4. DNSSEC-Tools:
  5. ISC DLV registry:

The Author

Eric Amberg has worked for many years as a system engineer for IT networks in large companies. His special subjects are Linux and network security. In addition, Eric has published various articles and the book Linux Servers with Debian GNU/Linux.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More