Hacker News Reader

Comment by syncerr | Hacker News Reader

I'd vote for DNS-over-HTTPS or similar tech. Encrypting domain name resolution should help mitigate a gateway or proxy (Comcast) from knowing or blocking sites you visit.

View on HN

I always found DNS to be one of the most compelling uses of the blockchain. Namecoin actually did a great job at this.

Effectively if put into practice, ISPs would run name servers that effectively mirror the whole DNS system via blockchain. And if you really wanted to have ultimate privacy you could run it locally on your machine and there would be no way for anyone to know what domains you've looked up.

SNI puts the DNS names you're connecting to in plaintext at the start of every TLS connection. Running your DNS over an encrypted channel won't stop someone from knowing or blocking the sites you connect to.

Luckily, from 2018 on, SNI will be mostly unnecessary, as LE will support Wildcard certificates, with DNS verification, for many domains in a single certificate.

SNI will still be necessary for when you have multiple servers under one IP (until IPv4 is deprecated, this is necessary), for example on a shared host (which might even have shared IPs under IPv6).

IIRC there are some ways SNI will be encrypted with TLS 1.3 so it's not a problem to begin with.

DNS is a non-trivial amount of traffic to go moving from a lightweight UDP protocol to something like HTTPS. Furthermore, that would dramatically increase page load times (for reasonably sized pages) since HTTPs requires more turns.

> dramatically increase page load times

This is true, but with a reasonable cache design, it shouldn't be too bad.

Unfortunately a single page load often contains files from many different domains. Sometimes 10+. So caching may be of limited use.

Although this may be a nice driving factor to get eCommerce sites to stop putting 50 tracking pixels on every page.

That's true. DNS lookups seem like something you can do in parallel though, so I still don't think it's that big of a hit.

Presumably you would keep-alive your DNS over HTTPS connection. That would keep the packet turns the same.

No need to go full https with it, dh once per session, then exchange data (could be over udp)

DNS Crypt (https://dnscrypt.org/) at least partially addresses some concerns with the current DNS specification providing for the authentication of DNS entries (spoofing prevention). I don't think it addresses the privacy concerns of ISP or 3rd party sniffing though.

Doesn't https://dnscrypt.org do that?

Nope, it simply gives you an assurance that the DNS entry you receive hasn't been spoofed and is coming from the DNS server that you expect it to originate from. See their homepage explanation.

There's DNSCurve by djb which does pretty much that.

https://dnscurve.org/

I second this. DNS is still a privacy killer

But then how would the Food Standards Agency get access to my browsing history?

https://www.reddit.com/r/unitedkingdom/comments/5ei5dz/list_...

Reply on news.ycombinator.com