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
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?