> But even assuming that doesn't happen it's still a huge privacy/data leak.

Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to.

I'm far more concerned with the possibility of intercepting or hijacking http traffic. Sure, an attacker could do this with any non-TLS connection in theory, but it's way way easier to hijack that one DNS response and change the A record.

Your viewpoint is like the post "DNSCrypt – Not Fundamental Enough" (2011) from TrendMicro.

http://blog.trendmicro.com/trendlabs-security-intelligence/d...

The IP address does not always tell you to which site you are connecting to. Many different sites can point to the same IP, more when services like Cloudflare are being used.

Most clients nowadays sent the "server name indication" (SNI) TLS extension though, which contains the name of the site you are connecting to.

The extension is sent unencrypted, even when using TLS 1.3. So everyone sniffing the traffic can tell where you are surfing to, even without DNS.

I don't think many people know this, or at least never think about it. "https means encrypted, that means secret."

And in order to support clients that don't support SNI, you need to have one domain per IP address so an attacker can just try and connect to that IP and then look at the SSL cert that's sent back to get the domain name.

>And in order to support clients that don't support SNI

There is little reason to support clients that do not support SNI. By supporting those clients you are likely putting your entire encrypted infrastructure at risk. SSL3 should be disabled by now. XP clients are legacy and should be taken out back and shot. Older mobile phones are enormous security risks.

With increasing IPv6 adoption this would be less and less true.

>Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to.

Honest question: with an increasing amount of sites being hosted via cloud infrastructure, does an IP really let you know if you are talking to Amazon, Google, or Microsoft vs the multitude of sites hosted by AWS, GCP, or Azure?

I'm assuming they use their own infrastructure, but I could be wrong.

IPs don't matter. SNI tells eavesdroppers the exact domain you are talking to.

Hopefully we will get Encrypted SNI with TLS 1.3

https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...

Yes, VPS services will still assign your instance an IP address of its own.

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.

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.

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.

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

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.

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.

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...

None of the commercial entities involved stand to gain from providing encrypted DNS lookups. It would just be one fewer bullet point in their personal-data sales packages.

I do, which is why I drove the creation of DNSCrypt.

> If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting

Kinda. It still can add a CNAME there, and make you go into another site for what it has a valid cert.

A CNAME isn't a redirect; if you add a CNAME record from thing1.example.net pointing to thing2.example.com, the browser still uses the domain name thing1.example.net for certificates, and just does a DNS lookup on thing2.example.com.

Put another way, a CNAME literally says the answer for any record type for thing1. is found by querying its canonical name, thing2. They're most comparable to symlinks. There is no data for this label; ask over there in that label. (This is why you can't CNAME the top of a zone, because you need SOA and NS there and CNAME can't coexist with other types. It wouldn't make sense.)

In most DNS stacks when an application asks for thing1. the usual way (something like gethostbyname), the resolver side will quietly follow a CNAME answer and resolve thing2. without telling the application anything happened. It's not part of the usual APIs, but that's not to say applications can't find out if desired. Same story with symlinks, where one uses a different API to read the link instead of the target. So for the browser case mentioned, a naive resolver wouldn't even be aware of the CNAME, hence the CN not changing for TLS purposes and the address bar staying the same. No modern browser has a naive resolver, just saying.

People trip up on this a lot, just clarifying.