Hacker News Reader

Comment by fukusa | Hacker News Reader

As far as I understand this doesn't encrypt communication but authenticates it to ensure it hasn't been tampered with. So it's still out in the open. I also don't understand what the benefit over DNSSEC is.

Edit: Nvm, DNSSEC still has to trust the validating resolver, DNSCrypt solves this.

View on HN

An easy way to think about this stuff is:

  DNSSec => Authenticity of resource records
  DNSCrypt, DNSoverTLS => Privacy of the connection

That's a little of an oversimplification. DNSSEC is indeed limited to authenticity. But the idea of DNSCrypt is that with very widespread deployment, you get most of the benefit of resource integrity, in the same way that we do with TLS even though no system in TLS explicitly "signs" HTML pages.

Sure. But who's running every node in the DNSCrypt graph? I've never been clear about what that looks like.

I still see DNSSec as providing value before the entire graph of DNSCrypt or DNSoverTLS exists.

There isn't one DNSCrypt graph. It's a forest of graphs that, in the event DNSCrypt became mainstream, would effectively converge. But, unlike DNSSEC, DNSCrypt doesn't require universal adoption to provide value.

DNSSEC provides no value at all until graph coverage is reached, and even then provides absolutely no privacy.

dnscrypt is an encrypted channel back to the DNS server. They can tell it's going to OpenDNS because of the IP address, but the cannot see the payload.

Good to know, couldn't find that on their website.

Why would you forward to opendns with a local dnssec enabled resolver? Just implement dnssec and run a proper dns infrastructure. No DNS operator reading HN? This thread is full of misinformation.

Right, but what advantage does DNSCrypt have over a local DNSSEC aware resolver? If you can't trust the local resolver you have more serious problems than DNS.

As others have stated, DNSSec only solves for authenticity of the data, not privacy.

DNSCrypt has been designed to both authenticate, authorize and encrypt the channel.

Using both in conjunction means that you have a private connection with authenticated data coming from the upstream resolver. Now the obvious issue is you don't know what the upstream resolver does with that...

DNSSEC provides no privacy. In fact, DNSSEC provides in the real world very few benefits of any kind, which is one of the reasons it's seen so little uptake in the 22 years during which the IETF has been working on it. Its most credible technical application is as a replacement for the CA system (which is a terrible idea).

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

In the real world, for privacy, there are essentially two competing approaches: DNSCrypt and DNS-Privacy. Both are unrelated to DNSSEC. DNSCrypt uses a custom protocol to encrypt DNS transactions, and DNS-Privacy uses TLS. Neither require, or even benefit from, deployment of DNSSEC.

Reply on news.ycombinator.com