DNSCrypt: A tool for securing communications between a client and a DNS resolver | Hacker News Reader

DNSCrypt: A tool for securing communications between a client and a DNS resolver

dnscrypt.org

63 pointsgits122530 comments

It would be nice to have encrypted DNS, but it is pointless if the server is untrustworthy. This defaults to Open DNS, a commercial service that gives false results (replacing NXDOMAIN) unless the user signs up giving personal info!

And for the same reason I don't want to use my ISP's DNS. I did a quick websearch for public DNS servers that give honest results without requiring an account, but did not see any mention of encryption compatible with this.

It defaults to OpenDNS because they have been sponsoring development and run the only publicly available DNSCrypt resolvers.

You are free to modify the code for the clients to point to your own server, setup your own server using the proxy code provided, or configure your authoritative DNS servers to talk securely to OpenDNS and protect the entire chain using DNSCurve (which DNSCrypt is based on).

The best i've been able to come up with is using something like dnsmasq plus a public resolver. it'll filter the results for you so that you can have their fake A records get turned into nxdomains. it's not a perfect solution (they can change the a records and you have to reconfigure) but it certainly seems to help.

You don't need dnsmasq for that. dnscrypt ships with the ldns-blocking plugin to block list of domains and IPs: https://github.com/jedisct1/dnscrypt-proxy/blob/master/src/p...

This isn't any better than using Google's DNS, your ISP's or OpenDNS directly. All your requests eventually go through a central location where they can be logged. Better to install your own caching dns server so they at least can't do traffic analysis on your repeat requests.

Depends on what you're trying to do. If you're trying to avoid logging, then sure, this doesn't get you much. If you're trying to secure yourself against local-network DNS attacks, this could be useful.

There's also nothing to stop you from using a caching DNS server with DNScrypt (in fact, they give you instructions to do so).

Run dnscrypt-wrapper or unbound on your router. Then run dnscrypt-proxy or dnssec-trigger on your clients. You get secured against local-network DNS attacks, and this let you use any upstream resolvers (or none).

OpenDNS has open sourced technology that allows you to secure DNS against eavesdropping, something no other technology will let you do at the DNS level (DNSSEC only does security, not privacy). They are also a major backer of DNSCrypt which provides transport security between recursive and authoritative servers.

Without OpenDNS'es work, your cute little caching DNS server at home is still subject to the same interception as queries flowing to your ISPs DNS cache.

So what if they optionally replace some NXDOMAIN queries so they can make a little bit of money? If they didn't have a business model that was up front, you'd claim they were obviously funded by the government.

We as a community need to not be so hard on commercial companies that are actually trying to protect us. Some of them are ran by genuine geeks like us and trying to help out.

let's be honest here: they've released this in an attempt to stop/muddle DNSSEC adoption, as DNSSEC represents an existential threat to their business: messing with the answers to DNS requests

Thats just overly cynical. https://yourlogicalfallacyis.com/genetic

DNSSEC is only signatures for DNS. It provides no secrecy of queries or responses. In light of the current PRISM disaster, DNSSEC does nothing to protect you.

I'll copy a snippet from OpenDNS' original announcement [1] here: Our support for DNSCurve doesn’t prevent our adoption of DNSSEC — they are not mutually exclusive. While we have reservations about DNSSEC, we can and will implement it when we see more demand and traction, but in the meantime, when we see a viable technology that can be quickly implemented to improve security for DNS users, that’s a no-brainer in our book.

1. http://blog.opendns.com/2010/02/23/opendns-dnscurve/

In light of the current PRISM disaster, DNSSEC does nothing to protect you.

Let's say Nation State A has all the data that prism has collected and Nation State B has the same exact dataset minus DNS traffic. Do you really think there is a lot that A can do that B can not?

EDIT: Changed hypothetical actors from me/you to state a/ state b. It made it seem personal and its not i was just being lazy.

There's nothing you can do with the DNS at all, regardless of whether we use DNSSEC, DNSCurve, DNSCrypt, or 1995 BIND where the query IDs increase monotonically, that will deter any nation state actor. DNS security is marginally relevant to online crime, and to nothing else.

This was my point but I was leaving open the possibility that I was completely oblivious to something. The only situation where I can think of DNS privacy having any impact is with an overlay (VPN/Tor) that leaks DNS requests at the client endpoint.

Is DNSCurve an existential threat to Daniel Bernstein somehow? Because this is just a consumer-friendly implementation of DNSCurve.

I wrote dnscrypt-proxy as a weekend project, and I still work on it on my spare time. And I'm a strong supporter of DNSSEC.

Unbound didn't support SSL back then, so that was a quick hack to achieve something similar. Let Unbound do caching, DNSSEC validation and filtering, and still authenticate DNS queries&responses between my remote Unbound server and my laptop.

"Without OpenDNS'es work, your cute little caching DNS server at home is still subject to the same interception as queries flowing to your ISPs DNS cache."

Encrypting your DNS queries and responses doesn't help much when they log the IP addresses and ports you connect to.

Encryption by default is a good thing. I might get around to playing with DNSCurve at some point, but it's not a priority for me, because practically speaking it doesn't give me that much benefit and I already have DNSSEC support.

In all fairness, their "work" is based on djb's (dnscurve). In fact, the entire company OpenDNS was built off of dnscache. And djb gives it all away fro free. That's what I call community.

If your "cute little DNS server at home" is dnscache, then I'd say you're on equal footing with OpenDNS. And if you configure CurveDNS or some other implementation of dnscurve then I'd say you're achieveing everything you could achieve with DNSCrypt. And it won't cost you anything... like OpenDNS spying on your queries and serving you ads.

The truth is, there are hardly any authoritative servers on the internet that support encrypted queries from dnscurve clients; dnscurve, as impressive as it is, remains obscure. If you're worried about someone sniffing or modifying queries off the wire as they travel from OpenDNS's or your home dnscache server to authoritative DNS servers, you'll have to restrain yourself to querying an extraordinarily small number of domains that have configured dnscurve. All other queries will fall back to being sent unencrypted.

Why not just do TCP queries over SSL?

If you install your own cache server, not only can all of your DNS request be logged off the wire, but you're vulnerable to DNS spoofing attacks. Those attacks are probably impractical today, but might not remain so.

I think securing the DNS is a poor approach in general, and we should instead concentrate on making an insecure DNS a chronic inconvenience rather than a fatal flaw. But if you're going to try to secure the DNS, the DNSCurve hop-by-hop approach is superior to DNSSEC's approach.

I am curious about "but not remain so." You don't think that increased adoption of DNSSEC will make dns spoofing less practical for zones that are signed (assuming properly configured local resolvers eg unbound on 127.0.0.1:53)?

Side note:† In the past I recall you supporting developers "pinning" certificates by rolling their own CAs and bundling the keys with their applications. I have always thought that DANE/TLSA records are an application layer agnostic method for certificate pinning. Do you think I have placed too much trust in DANE?

Given widespread adoption of DNSSEC, DANE records seem like an easier way to manage "certificate pinning" than having to push application updates. Plus I can use the same DANE records that my mobile app uses to protect the third party API for my service. Whereas embedding keys into apps leaves the API unprotected.

I realize "Assuming widespread adoption of DNSSEC" is the big "if" when speaking about the public in general. However for controlled environments (I'm thinking of anything ending in .gov/.mil) DANE records seem like an easy win.

† In this section I am shoveling words into your mouth so I apologize if I have misconstrued/misremembered previous posts.

I meant that DNS spoofing vulnerabilities that are currently impractical against unencrypted DNS might not always be impractical against unencrypted DNS.

In the recent discussions about NSA surveillance, a technological anchor we could repeatedly point to was the fact that Google baked the identities of their keys directly into the binaries for Google Chrome. Firefox has adopted the same approach. I don't think it's hyperventilation to suggest that NSA has at least one trusted CA key in its possession, but despite that, NSA probably can't invisibly MITM Google Mail sessions because Chrome's trust anchor for Google Mail isn't a CA certificate.

In a DNSSEC world where DANE was used for key pinning, we'd be back to trusting a PKI root. Moreover, the PKI root we'd most often be trusting is one controlled by the US Government. How, exactly, is that a step forward?

step forward

Duh, thank you. I don't know why I was approaching it as if the clients had the DNSSEC keys hardcoded for each zone. It seems that there is not a lot of hope for a solution that is easily interoperable (BYO Browser/MTA) when your threat model includes nation state and sub-nation state threats.

This is what's good about DNSCurve; it provides value immediately and deploys incrementally without boiling the ocean, and it doesn't come with a whole new PKI that would (for instance) force every .LY app to trust the government of Libya.

I had issues with DNSCrypt after using it for a few months. I had strange DNS resolution issues, felt I couldn't truly trust it, and found myself disabling/re-enabling it too often to see if it was the point of failure. I now use https://proxy.sh for a private VPN with the Viscosity VPN client which properly sends DNS traffic over the VPN.

That said, I'll probably give DNSCrypt a try again in the coming months. YMMV

I've been using DNSCrypt on linux for probably a year. The only issue I had a few times some months ago was that the first nameserver would stop responding, the solution would be to switch to the second nameserver. Lately though I haven't had any issues, for me at least it has been fast and reliable.

Note to DNSCrypt users: Apparently the update feature of 0.10 doesn't work. I've been running that version since it came out and it always said it's up to date. I assumed they just weren't actively developing it. Apparently it just didn't update because the current version is 0.19.

I don't get why this is on the HN front page. dnscrypt is 2 years old, and nothing special happened to it lately. Did I miss something?

How does it compare to DNSCurve (http://dnscurve.org)?

How does it compare to DNSSIG? (http://dnssig.org)?

I think DNSSIG is (at least designed) more for relationships among DNS servers and especially to protect the integrity of the DNS records, while this project seems more for securing the client-to-relay channel, with (I guess) focus on confidentiality.

Both focus on integrity. Read the dnscrypt project description and grep for "authentic", then grep for "encrypt".

DNS confidentiality is useful when running an IP-over-DNS tunnel like iodine, not so much in combination with other protocols.

Reply on news.ycombinator.com