On Dec 13, 2011, at 1:52 PM, Jason wrote: > On Tue, Dec 13, 2011 at 09:53:09AM +0000, Simon Kelley wrote: >> On 08/12/11 15:48, Jason wrote: >>> I found this [1] comment from 2010 regarding source control. Have you >>> considered migrating to one? I only ask because I'm partial to git (I >>> use it all day, every day ;-) ), and I'd like to submit a patch. >> >> Please do. > > Oops, it'll have to wait. My patch was going to be integrating dnscrypt > into dnsmasq... I hope it, or something similar takes off.
Slightly off topic, but I would focus on DNSSEC validation long before DNSCurve/DNSCrypt. DNSSEC provides integrity of the data, and is deployed today. Integrity is critical, because that's the primary role of DNS. Of particular importance, DNSSEC validation protects against the recursive resolver's misbehaviors, which has included such things as NXDOMAIN wildcarding and MITM attacks on user search traffic, run by some ISPs, in order to change user search results to redirect through paid affiliate links! The latter provides ONLY confidentiality and integrity against an "on the wire" adversary. It provides no protection against the recursive resolver, either confidentiality OR integrity. And the "on the wire" integrity and confidentiality benefit from DNSCrypt/DNSCurve is surprisingly low: Someone who can see your DNS traffic can likely see the rest of your traffic: so it doesn't matter that they don't see you looked up 'www.bigpornsite.com', because they will see your HTTP request itself. And they can inject packets into the TCP flows generated, limiting the benefit of on-the-wire integrity as well. Thus if you wish to spend the time implementing cryptographic DNS operations, I'd focus on DNSSEC with a reasonable fallback (do a from-the-most-verified-terminal direct fetch and accept), rather than DNSCurve/DNSCrypt.
