Internet Performance Delivered right to your inbox

DNSSEC and DNSCurve – Why they cannot be compared

Reading a few mentions of DNSSEC v. DNSCurve lately and I cannot help but think that the comparison is skewed. Both technologies set out to solve different problems but are being billed as alternatives. One is more focused with authentication while the other is more about encryption.

As a client of a network, I need to resolve names into numbers. In a home, corporate, or open wireless network, that generally means that I obtain a DHCP lease and a series of DNS servers along with my IP address, gateway, and netmask. How can I trust that the answer I receive is what DNS is supposed to return on a network that I do not trust? How do I verify that the DNS response is what DNS returned and not something an attack injected?

DNSSEC and DNSCurve approach this problem differently. In DNSSEC, the middle may not be trusted but it’s the stub resolver that can perform the validation and ultimately decide whether to use or not use the answer. DNSCurve does not protect me against a bad set of RDNS servers.

There is still an operational practice missing known as the this last-mile problem with DNSSEC. To perform validation, my stub resolver needs a key to be authentically delivered to verify signatures. If I cannot trust my DNS/DHCP servers, another mechanism is needed. This issues is neither solved/created in the DNSSEC protocol. It needs to implement some operational best practices to make it go away.

DNSCurve ultimately introduces privacy. I can do DNS lookups on a network with privacy. On that untrusted wireless network, the network operator could merely look at my netflow to see what I am accessing. There is a built in hop-to-hop authentication but it’s not end-to-end trust. Unless everyone implements DNSCurve, the link-layer is broken.

I can verify some .org domains and detect now whether my query responses are indeed authentic – exactly what I want DNS to be.

Share Now