How does DNSCurve protect against forgery in a man-in-the-middle attack scenario?
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?"
