Trusted name resolution with DNSSEC
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.
- Multiple standards documents specify DNSSEC: RFC 4033 (Intro), RFC 4034 (Records), RFC 4035 (Protocol), and RFC 3658 (DS): http://tools.ietf.org/html
- DNSSEC HOWTO: http://nlnetlabs.nl/dnssec_howto
- ISC name server: http://www.isc.org/
- DNSSEC-Tools: http://www.dnssec-tools.org/
- ISC DLV registry: https://secure.isc.org/index.pl?/ops/dlv/
Buy this article as PDF
Should you trust an online service to store your online passwords?
New B+ board lets you build cool things without the complication of a powered USB hub.
Redmond rushes in to root out alleged malware haven.
New initiative will bring futuristic virtual reality effects to the web surfing experience.
Dyreza malware launches a man-in-the-middle attack that compromises SSL.
New cloud combines worldwide access with local attention to data security.
A first cousin of the recent Heartbleed attack affects EAP-based wireless and peer-to-peer authentication.
FOSS community acts to protect freedom of choice for laptop devices.
Quintessential open source browser shores up its market share with a step toward the proprietary dark side.
Authorities in 16 countries take action against users of the imfamous BlackShades malware tool.