Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1.1.1.1: Fast, privacy-first consumer DNS service

blog.cloudflare.com

Post reply on HN
Print view View original

631–640 of 695 posts

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

#631

Post by deadlocked »

cleanbrowsing wrote: post #299

And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork 2 msec 1 msec 2 msec 19 msec Toronto 2 msec 28 msec 17 msec 27 msec Atlanta 1 msec 2 msec 1 msec 19 msec Dallas 1 msec 9 msec 1 msec 7 msec San Francisco 3 msec 21 msec 15 msec 20 msec London 1 msec 12 msec 1 msec 14 msec Amsterdam 2 msec 6 msec 1 msec 6 msec Frankfurt 1 msec 9 msec 2 msec 9 msec Tokyo 2 msec 2 msec 81 msec 77 msec Singapore 2…

ICMP round-trip times don't necessarily prove anything - you need to be examing DNS resolution times.

Lots of network hardware (i.e., routers, firewalls if they're not outright blocking) de-prioritise ICMP (and other types of network control/testing traffic) and the likelihood is that Google (and other free DNS providers) are throttling the number of ICMP replies that they send.

They're not providing an ICMP reply service, they're providing a DNS service. I'd a situation during the week where I'd to tell one of our engineers to stop tracking 8.8.8.8 as an indicator of network availability for this reason.

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

#632

Post by dojo999 »

1.0.0.1 and 2606:4700:4700::1001 return the same PTR info as 1.1.1.1 and 2606:4700:4700::1111 do.

  $ host 1.0.0.1
  1.0.0.1.in-addr.arpa domain name pointer 1dot1dot1dot1.cloudflare-dns.com.

  $ host 2606:4700:4700::1001
  1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa domain name pointer 1dot1dot1dot1.cloudflare-dns.com.
I would've expected these to return 1dot0dot0dot1.cloudflare-dns.com.

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

#633

Post by tialaramex »

dfox wrote: post #510
tialaramex wrote: post #253

Earlier quoted context omitted.

It's really hard to fix this. https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encrypti... is the state of the art -- note that's a Draft, and really, really not finished, help is doubtless welcome. If it was easy, it would have been done during the TLS 1.3 process, but after a lot of discussion we're down to basically "Here is what people expect 'SNI encryption' would do for them, here's why all the obvious stuff…

It is hard because of the TLS's pre-PFS legacy and to some extent also because of (very meaningful) intention to reduce roundtrips. The way to do SNI-like stuff is obvious: negotiate unauthenticated encrypted channel (by means of some EDH variant, you need one roundtrip for that) and perform any endpoint authentication steps inside that channel. This is what SSH2 does and AFAIK Microsoft's implementation of encrypted…

So, it feels like you're saying this is how SSH2 and rdesktop work, and then you caveat that by saying well, no, they actually don't offer this capability at all it turns out.

You are correct that you can do this if you spend one round trip first to set up the channel, and both the proposals for how we might encrypt SNI in that Draft do pay a round trip. Which is why I said they're slow and ugly. And as you noticed, SSH2 and rdesktop do not, in fact, spend an extra round trip to buy this capability they just go without.

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

#635

Post by MertsA »

majewsky wrote: post #331
Operyl wrote: post #303

Earlier quoted context omitted.

You just solved your own question. Cloudflare creates an opensource client that users install locally.

Where's the button to install your own DNS resolver on iOS? Or non-rooted Android, for that matter.

Well with SNI the concern isn't DNS. Any TLS connection that supports SNI (basically everything that isn't ancient) would have to be fixed. Also, ANI is a pretty useful thing to have and getting rid of it doesn't exactly fix much. Without SNI the server only has the destination IP address to determine which site and thus which certificate to send to the client. Having https sites with multiple certificates hosted on one IP address only works because of SNI. You would break a large portion of the web by disabling it. Also, even if you do disable SNI, the server still sends back the certificate with the domain names in it. And even if you ignore all of that, there's still reverse DNS which will probably be accurate if they send mail from that server and you can always do a DNS lookup for every domain name there is to get a map of which domains point to a given IP. Due to DNS based geolocation that won't work for every site but the sites using that are going to be big enough to find their IP address ranges via another method.

In short, there's really no good solution here but an amendment to TLS could conceivably make it to where it wouldn't be possible to narrow it down to which site that an IP address hosts the user was visiting. That could actually be good enough for traffic to e.g. cloudflare.

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

#637

Post by originalsimba »

The idea is solid on the surface, but I don't trust it's parent. Setting up hundreds of millions of internet machines to be reliant on a single corporation's service offerings is asking for disaster, and Cloudflare has a sleeeeaazy history.

But hey, they say their product is legitimate, so it must be true.

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

#638

Post by bgdkbtv »

brod wrote: post #587
bgdkbtv wrote: post #578

Earlier quoted context omitted.

Australia :( 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=17.580 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=18.025 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=17.780 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=18.231 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=17.906 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=18.447 ms

Melbourne, Australia :) PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=5.044 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=6.447 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=6.371 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=6.308 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=7.317 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=5.989 ms

Woah! That's pretty good. Mine was on Belong NBN in Brisbane.

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

#640

Post by MaysonL »

cleanbrowsing wrote: post #299

And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork 2 msec 1 msec 2 msec 19 msec Toronto 2 msec 28 msec 17 msec 27 msec Atlanta 1 msec 2 msec 1 msec 19 msec Dallas 1 msec 9 msec 1 msec 7 msec San Francisco 3 msec 21 msec 15 msec 20 msec London 1 msec 12 msec 1 msec 14 msec Amsterdam 2 msec 6 msec 1 msec 6 msec Frankfurt 1 msec 9 msec 2 msec 9 msec Tokyo 2 msec 2 msec 81 msec 77 msec Singapore 2…

Pasadena, CA

1.1.1.1 continually timed out.

1.0.0.1 succeeded

18 packets transmitted, 18 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 10.178/11.128/12.585/0.576 ms

Post reply on HN