61–70 of 137 posts
Doesn't TCP, TLS, HTTP, and finally DNS seem like overkill? Why not DTLS + plain DNS requests?
But there are alternatives, DNS over TLS (essentially the same without HTTP) and dnscrypt which uses UDP.
Earlier quoted context omitted.
The limiting resource with large numbers of idle sockets on the server side is memory, not processing power.
Which I doubt is a problem for Cloudflare or Quad9. Anyway, a TCP based DNS service needs to consider those things. Otherwise it is becoming unusable due to very high response times. A standard 8 GB system with Debian 9 gives me 1048576 max file descriptors. I am sure this can be optimized still.
And if you were keeping them open for 5 minutes as suggested, that would still limit you to only 3400 clients / second.
I do actually agree that they need a longer idle timeout on these connections, but I just wanted to point out that comparisons with the processing power required to set up a TLS connection aren't apt.
There are 3 major protocols available for DNS privacy: * DNSCrypt * DNS over TLS * DNS over HTTPS DNSCrypt is the one with better client support and a long list of providers available. If you pick DNS over TLS or DNS over HTTPS you will be restricted to 3 or 4 major players (google, quad9, cloudflare and cleanbrowsing). If you trust them, you are good. For example, this is the list of providers with DNSCrypt support:…
Do the dnscrypt providers actually work , though? I tried setting it up from my machine, and it seemed like many of them were gone. I eventually managed to find a working provider in Iceland, but being that I'm in a country on the opposite side of the planet, the increased latency made the internet markedly more sluggish.
There are 3 major protocols available for DNS privacy: * DNSCrypt * DNS over TLS * DNS over HTTPS DNSCrypt is the one with better client support and a long list of providers available. If you pick DNS over TLS or DNS over HTTPS you will be restricted to 3 or 4 major players (google, quad9, cloudflare and cleanbrowsing). If you trust them, you are good. For example, this is the list of providers with DNSCrypt support:…
DNSCrypt is also the fastest and most secure. It doesn't require sessions (uses UDP by default, like regular DNS, but prevents amplification), enforces safe cryptography and pinned certificates, is trivial to implement, doesn't need OpenSSL, implements padding without inventing yet another DNS extension, and can use unique keys for each question (so that DNS providers can't fingerprint clients, unlike other options d…
Earlier quoted context omitted.
DNSCrypt is also the fastest and most secure. It doesn't require sessions (uses UDP by default, like regular DNS, but prevents amplification), enforces safe cryptography and pinned certificates, is trivial to implement, doesn't need OpenSSL, implements padding without inventing yet another DNS extension, and can use unique keys for each question (so that DNS providers can't fingerprint clients, unlike other options d…
If it's the fastest and most secure, why are people throwing their weight behind DNS-over-HTTPS? There must be a reason for it.
Earlier quoted context omitted.
I guess I was just heading off the flurry of comments along the lines of "Why use DoH when we have DNSSEC?" that always seem to come up when discussing DoH.
DNSSEC has no encryption. It's not for privacy at all.
In theory if the upstream resolver is using DNSSEC to validate all the Records, then the client over the TLS session can be fairly confident in the Records it receives.
Earlier quoted context omitted.
Which I doubt is a problem for Cloudflare or Quad9. Anyway, a TCP based DNS service needs to consider those things. Otherwise it is becoming unusable due to very high response times. A standard 8 GB system with Debian 9 gives me 1048576 max file descriptors. I am sure this can be optimized still.
The default socket receive and send buffers are ~200KB, so you would actually need 400 GB of memory in order to have each of those 1048576 file descriptors connected to a unique socket. And if you were keeping them open for 5 minutes as suggested, that would still limit you to only 3400 clients / second. I do actually agree that they need a longer idle timeout on these connections, but I just wanted to point out that…
I kind of hate this. Taking a decentralised service, and replacing it with a service provided by a small handful of tech giants. "But this doesn’t mean you have to use Cloudflare. Users can configure Firefox to use whichever DoH-supporting recursive resolver they want. As more offerings crop up, we plan to make it easy to discover and switch to them." Only defaults matter. Your average web user wont be interested in…
If only defaults matter, then it's already a dead horse, as the majority of users don't know what DNS even is, and are using their ISP's servers by default.
Earlier quoted context omitted.
DNSCrypt is also the fastest and most secure. It doesn't require sessions (uses UDP by default, like regular DNS, but prevents amplification), enforces safe cryptography and pinned certificates, is trivial to implement, doesn't need OpenSSL, implements padding without inventing yet another DNS extension, and can use unique keys for each question (so that DNS providers can't fingerprint clients, unlike other options d…
AFAIK it isn't possible to combine it with Pi-Hole though.
Earlier quoted context omitted.
If it's the fastest and most secure, why are people throwing their weight behind DNS-over-HTTPS? There must be a reason for it.
Because it's much more complicated to implement, where-as DNS-over-TLS and DNS-over-HTTPS are far simpler to integrate into existing software and operations.
Both HTTPS and TLS implementations require custom software in order to work, as no OS supports this natively (yet).
It boils down to install a stub that your local resolver will use instead of the upstream directly.