This Question is about DNSCurve. I thought of DNSCurve as "HTTPS for DNS" (like in this Answer) but had some resent thoughts about the trust-relationship between resolvers and nameservers serving the public-keys.

Here an example to explain what I am talking about:

Lets assume we got a default MitM setup with Bob as victim and eve as attacker.

  • Eve has found a way to control Bobs network traffic (e.g. with arp poisoning).
  • Now Bob tries to lookup www.nytimes.com with a local, dnscurve-only resolver (empty cache). His resolver works recursively through . (root) -> .com. -> nytimes.com. -> www.nytimes.com
  • Eve analyzes the requests, forwards them to the real destination and finally delivers the answers back to bob.
  • When bob's resolver asks the .com NS for the nytimes.com Nameserver the response would be a DNSCurve NS-Record like uz5xgm1kx1zj8xsh51zp315k0rw7dcsgyxqh2sl7g8tjg25ltcvhyw.nytimes.com. Eve now takes her own key-pair and generates a spoofed DNSCrypt-Record so she can decrypt the requests.
  • Bob's resolver would assume that nytimes.com has Eve's Public-Key, builds a DNSCurve-Request and sends it to the NS.
  • Eve intercepts this message, decrypts it's payload (= the dns request), requests the real record from the real NS (with or without DNSCurve), forges the response (with DNSCurve) and sends it to Bob.
  • Bob receives Eve's forged request, but because Eve also forged the initial NS Record Bob's resolver thinks that this is the valid public-key to validate the answer against, concluding that this is a valid response.

If I understand DNSCurve correctly it should protect against this kind of situation. DNSSEC provides a Cain-Of-Trust to prevent this kind of attacks, TSIG uses shared keys that has to be exchanged out-of-band, how is DNSCurve handling this problem? The official Documentation even stated that "If a name contains several DNSCurve public keys, use the first one" (https://dnscurve.org/in-implement.html) which sounds like a even bigger problem because it could enable even simpler attacks (classical DNS Spoofing with Sniffing and UDP Spoofing).

I'm pretty sure I missed something here but after hours of research I could not find any answer to that question. The heart of this question is "where is the trust-relation establishment process in DNSCurve?"

1 Answer 1


The described attack works because the parent zone that provides NS records (which include the encoded public key of the name servers) does not necessarily use DNSCurve, and an attacker can substitute its own public key encoded as the name server's public key. Later, when the recursive resolver uses the substituted public key to communicate with the name servers, the MitM attacker can decrypt the query, as the recursive resolver is using the attacker's key. DNSCurve does not introduce any chain-of-trust like DNSSEC, and this leads to these types of attacks, as the recursive resolver cannot verify the public keys.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .