Hacker News new | past | comments | ask | show | jobs | submit login

So what use does this have?

DNSSEC already gives us validation of the records, and thanks to SNI, this doesn't give us any privacy.

It is more complex, more centralized, and ends up slower than using actual DNS, and doesn't seem to provide any benefits.

Am I missing something?




There is no good reason DNSSEC shouldn't protect query privacy. It doesn't because the most important Internet users --- developers and operations engineers --- are letting them standardize it that way. If it annoys you that we have to resort to elaborate hacks to keep ISPs from monitoring our queries while at the same time undertaking huge projects to migrate to a new DNS protocol, you're not crazy, and you should make some noise. DNSSEC sees barely any use in the real world, and it is not too late to change it.


Easier to prevent censoring. DNSSEC doesn't hide the fact that you're making a DNS call, correct? With HTTPS, censors/MITMs can only see the domain you go to. The censor/MITM won't know whether I went to google.com to search or perform DNS query. Plenty of countries have blocked DNS providers they don't like, now that's harder w/out also blocking the site as a whole.


Easier to prevent censoring from the ISP, but you're now just reliant on another company's systems.

If you just want a solution for having a remote server execute DNS queries for you, you can just use any of the existing VPN protocols purely for DNS resolution, or even make a better performing version.

All that overhead HTTP adds is wasted for this.


> All that overhead HTTP adds is wasted for this.

When you're in an area where your DNS provider is limited by the state, you won't consider it wasted. But if you're not and you do consider it wasted, don't use it. But saying it doesn't seem to provide any benefit is wrong and just telling people to use a VPN for DNS resolution is also wrong (at least until the ergonomics improve).


It's more a question why a company like Google would pay several engineers who are paid 6-digit sums to build this when they could build for the same or less much more powerful solutions.


It all depends on your threat model. Certainly DNS over HTTPS is not a panacea - but it certainly will help when your ISP is doing crazy stuff with his DNS firewall (anyone here from the UK). The other (darker) side of the coin is that corporate tools to identify e.g. rogue IoT devices by their DNS signatures will have difficulties...


I suspect it wouldn't be too hard for a nation state or similar to determine the signature of DNS over HTTPS requests to see if someone is making a DNS request, unless you add a bunch of noise to the transaction.


Doubt it. How can a DNS HTTP GET look that much different than a favicon.ico GET over TLS? MTU/size alone is all they can use to shape, but there are many small web requests.


Perhaps for a single request, but I wonder if you could infer something by watching longer term patterns.


"... thanks to SNI, this doesn't give us any privacy."

Assumption: All sites use SNI or will use SNI.

True?

Experiment: List all domains posted to HN (pages 1-20) that require https on any given day. Try accessing each one without SNI.

Result: Most do not require SNI.


Wrong.

SNI has to be sent without any previous negotiation. Therefore the client does not know if a site will require SNI or not.

Assumption 1: browser vendors do not want to break sites relying on SNI

(Confirmed by WHATWG)

Assumption 2: at least one major site will continue to use SNI

Conclusion: browsers will continue to send SNI.


"Therefore the client does not know if a site will require SNI or not."

The client that I use assumes no SNI required. (It intentionally does not support SNI.) If it fails because the website is on a shared host and requires SNI, then it retries via a local SNI-enabled proxy bound to localhost.

"Conclusion: browsers will continue to send SNI."

Some clients/browsers will continue to send the domainname in the clear for every https url, even when it is not required.

Some users might consider that as sacraficing their privacy even when it is not necessary.

But not the client I use. It assumes no SNI is required, by default. It never sends the domainname in the clear for https when it is not necessary.


That is awesome (and I personally also always err on the side of safety/privacy there), but I don't think this will help much.

Anyone that can set your setup up can also just openvpn to a remote server, and redirect all DNS queries over that connection (which is quite easily doable, actually).

Everyone that can't do this would still use SNI, so DNS-over-HTTPS wouldn't provide any security win for them.


don't you think SNI leaks will get fixed eventually?


No. All actors currently involved with the web are ideologically opposed to backwards incompatible changes, and, as a result, they'd never make a change that prevents a browser from accessing a legacy site.

As result, SNI is here to stay.


This isn't how backwards compatibility works.

A hypothetical encrypted SNI would be "optional" in the sense that your Firefox 57 wouldn't use it, but a site could implement it, and Firefox 73 could too and then the actual user of that actual site is protected by upgrading to FF 73.

If you were right everything would still be HTML 4 over HTTP 1.1


The problem with SNIis that it happens before all that negotiation.

This is why today your browser sends the SNI info even if the site will never need it.

And that also means for eternity all TLS1.3 or lower connections will continue to use SNI.





Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: