Live data from Hacker News

1.1.1.1: Fast, privacy-first consumer DNS service

blog.cloudflare.com

161–170 of 695 posts

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#161
post #72

9.9.9.9 [1] has been praised by a bunch of people in the thread from a couple days ago [2]. How do those two compare? [1] https://www.quad9.net/ [2] https://news.ycombinator.com/item?id=16716606

I don't use them (even though I would love to) because it takes approximately 3x as long to reach the server. To compare the two, together with Google's DNS as a reference, from a fast connection: 64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=3.62 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=3.60 ms 64 bytes from 9.9.9.9: icmp_seq=5 ttl=60 time=9.20 ms ...and from a slower (home) connection: 64 bytes from 1.1.1.1…

Do you think that ~23ms is going to make any real, perceptible difference to your internet performance? Considering that a) your browser will make any DNS requests it needs in parallel when loading a web page, and b) most DNS requests will be cached anyway.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#163

DNS-over-HTTPS doesn’t make as much sense to me as DNS-over-TLS. They are effectively the same thing, but HTTPS has the added overhead of the HTTP headers per request. If you look at the currently in progress RFC, https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-04 , this is quite literally the only difference. The DNS request is encoded as a standard serialized DNS packet. The article mentions QUIC as being…

>The article mentions QUIC as being something that might make HTTPS faster than standard TLS.

Even with TLS 1.3 0-RTT?

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#164
post #9
post #3

This is the Cloudflare resolver, right? What's the "privacy-first" part about? It's just another third party DNS host. They haven't changed the protocol to be uninspectable and AFAIK haven't made any guarantees about logging or whatnot that would enhance privacy vs. using whatever you are now. This just means you're trusting Cloudflare instead of Comcast or Google or whoever.

Yes they have: "Privacy First: Guaranteed. We will never sell your data or use it to target ads. Period. We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we're doing what we say. Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical step…

Serious question: where is that quote from? The link above is just to the resolver address.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#165
post #125
post #69

Earlier quoted context omitted.

Interesting, mine is bad too. From singtel: Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.254 0.0% 75 1.3 1.6 1.1 14.8 1.6 2. bbXXX-XXX-XXX-XX.singnet.com.sg 0.0% 75 3.4 2.8 1.9 18.7 2.5 3. 202.166.123.134 0.0% 75 3.2 3.5 2.7 15.9 2.0 4. 202.166.123.133 0.0% 75 3.0 3.0 2.4 6.6 0.7 5. ae8-0.tp-cr03.singnet.com.sg 0.0% 75 3.1 3.3 2.8 6.9 0.7 6. ae4-0.tp-er03.singnet.com.sg 0.0% 75 2.9 3.1 2.6 6.7 0.5 7. 203.208.…

What's the tool you used there? From MyRepublic 8.8.8.8 is 2 hops shorter and about a millisecond faster. Disclaimer: I probably don't know what I'm doing :D

mtr aka mytraceroute. Available on homebrew if you're on osx

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#166

DNS-over-HTTPS doesn’t make as much sense to me as DNS-over-TLS. They are effectively the same thing, but HTTPS has the added overhead of the HTTP headers per request. If you look at the currently in progress RFC, https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-04 , this is quite literally the only difference. The DNS request is encoded as a standard serialized DNS packet. The article mentions QUIC as being…

>The article mentions QUIC as being something that might make HTTPS faster than standard TLS. Even with TLS 1.3 0-RTT?

exactly...

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#167
post #157
post #145

I'm probably gonna switch my PiHole over from Google DNS. I trust Cloudflare more than Google to uphold my privacy. Not that I trust either very much. Benchmarking Results for the interested: (sorted worst first, P value is bottom-X-percent) 1.1.1.1: P00.5=48.2ms (55.8ms VPN) P50.0=32.8ms (37.0ms VPN) P95.0=29.1ms (33.0ms VPN) P99.5=29.1ms (32.7ms VPN) 8.8.8.8: P00.5=225.4ms (71.5ms VPN) P50.0=48.0ms (53.6ms VPN) P95…

Why isn't your pihole a stand-alone DNS resolver instead on relying on 3rd-party services ?

I'm not aware of any pihole native setting to enable a resolver instead of using forwarding.

Third-party services like this will also have a huge range of queries cached so the response time will definitely be better than have a rasppi with little free memory try/attempt to cache that.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#168

Earlier quoted context omitted.

Anonymized logging to improve the service and security. Is this different from Cloudflare?

Cloudflare is saying they won't log and will have audits by KPMG yearly to prove as such. Not logging and logging anonymized data are different approaches.

FTA: While we need some logging to prevent abuse and debug issues, we couldn't imagine any situation where we'd need that information longer than 24 hours.

So the difference is how long the logs are kept, and possibly what the log data is used for.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#170
post #55

Earlier quoted context omitted.

Tokyo, Japan: [mason@iMac-Pro-No-5 fubastardo (master)]$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=56 time=2.310 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=2.287 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=2.103 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=2.785 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=2.276 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl…

You're just trying to make Australians jealous aren't you? ping 1.1.1.1 Reply from 1.1.1.1: bytes=32 time=366ms TTL=58 Reply from 1.1.1.1: bytes=32 time=366ms TTL=58 Reply from 1.1.1.1: bytes=32 time=365ms TTL=58 Reply from 1.1.1.1: bytes=32 time=365ms TTL=58 ping 8.8.8.8 Reply from 8.8.8.8: bytes=32 time=402ms TTL=59 Reply from 8.8.8.8: bytes=32 time=373ms TTL=59 Reply from 8.8.8.8: bytes=32 time=373ms TTL=59 Reply…

I'm getting ~40-50ms on both on Internode from Brisbane.
Post reply on HN