DNSCrypt release for Linux
blog.opendns.com
blog.opendns.com
For background, it is the first implementation of DNSCurve designed by DJB (qmail, tinydns, daemontools, etc). See http://dnscurve.org/ or the excerpt below.
DNSCurve uses high-speed high-security elliptic-curve cryptography to drastically improve every dimension of DNS security:
Confidentiality: DNS requests and responses today are completely unencrypted and are broadcast to any attacker who cares to look. DNSCurve encrypts all DNS packets.
Integrity: DNS today uses "UDP source-port randomization" and "TXID randomization" to create some speed bumps for blind attackers, but patient attackers and sniffing attackers can easily forge DNS records. DNSCurve cryptographically authenticates all DNS responses, eliminating forged DNS packets.
Availability: DNS today has no protection against denial of service. A sniffing attacker can disable all of your DNS lookups by sending just a few forged packets per second. DNSCurve very quickly recognizes and discards forged packets, so attackers have much more trouble preventing DNS data from getting through. Protection is also needed for SMTP, HTTP, HTTPS, etc., but protecting DNS is the first step.
Despite its extremely high level of security, DNSCurve is very easy for software authors to implement, and very easy for administrators to deploy.
DNSCurve is part of a larger project to encrypt and authenticate all Internet packets. The techniques used in DNSCurve are easily adapted to other Internet protocols.
DNSCurve is like ssh - no central authority, secures and hides the contents of the connection, not the data at rest. Server keys are published as part of the NS record of the domain.
DNSSEC is like PGP with SSL's centralize certificate authorities - trusted parties use keys to sign zone files which can be stored on an untrusted server but still authenticated. No encryption on server-client communication.
They're really complimentary techniques with different goals and means of achieving them.
That said, if you have control at the registrar level or an intermediary or above the recursive nameserver, you could change the NS records to use your keys and MITM it that way.
http://curvedns.on2it.net/docs
I wrapped the CurveDNS binaries with fpm, which made installing it on all the servers very easy. For the DNS server I used the djbdns stack (already in debian experimental, patched with IPv6 support). The big advantage of this is that tinydns's data format is atomic on a line level, so you just cat all the zone files together and build the data.cdb file. I do this with Rake and and push the zone all over SSH to the servers - making an internet facing change is usually as trivial as adding a single line in a text file and running rake.
Glad to see the client side of things is becoming as easy to set up as the server side.
Cool, just noticed that I haven't seen the term "rockstar hacker" in job ads in a long time. Can't say I miss it.
Personally I've alway felt more like a plumber or carpenter than a rockstar or ninja.
12:57:43.523694 IP mypc-ubuntu.local.38481 > resolver2.opendns.com.domain: 28982 updateM [b2&3=0x666e] [27192a] [30295q] [20660n] [52086au][|domain]
12:57:43.801981 IP resolver2.opendns.com.domain > mypc-ubuntu.local.38481: 29238 updateM [b2&3=0x666e] [27192a] [30295q] [414n] [12287au] Type65535 (Class 13704)? [|domain]
There should have been a third line with the encrypted lines, but it doean't show up for anonymouse.org. Where as the third line with encrypted payload gets shown to the domains that are whitelisted in my network.
I'm currently running my own recursive resolver. I would like to add DNSCrypt support, but I'm not handing over my DNS queries to somebody else.