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?
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?
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.
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).
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.
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.
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.
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.
As result, SNI is here to stay.
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
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.