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

571–580 of 695 posts

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

#571

Post by eridius »

bluejekyll wrote: post #207
patrickmcmanus wrote: post #185

Earlier quoted context omitted.

rfc 8336. h2 coalescing. h2 push. caching. it starts to add up to a very interesting story.

Thank you for responding, Patrick. As one of the authors of the RFC, your views on this are a great contribution to the conversation. > rfc 8336 I'll have to read up on this, thanks for the link. > h2 coalescing DNS is already capable of using TCP/TLS (and by it's nature UDP) for multiple DNS requests at a time. Is there some additional benefit we get here? > h2 push This one is interesting, but DNS already has optim…

As a complete layperson, h2 push might be interesting because a DNS resolver could learn to detect patterns in DNS queries (e.g. someone who requests twitter.com usually requests pbs.twimg.com and abs.twimg.com right after) and start to push those automatically when they get the query for twitter.com.

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

#572

Post by eridius »

TheSwordsman wrote: post #565

From Comcast in San Francisco, I'm seeing that CloudFlare is the slowest of Google Public DNS, OpenDNS, Level 3, and Comcast's resolver. Definitely not what I was expecting... CloudFlare: $ ping -c 240 -i 0.25 1.1.1.1 ... --- 1.1.1.1 ping statistics --- 240 packets transmitted, 240 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 16.271/17.286/25.105/1.236 ms Google Public DNS: $ ping -c 240 -i 0.25…

You should be measuring DNS time, not ping time. There's more to how fast a DNS resolver responds than the time it takes to send the packet over the wire.

As a Comcast@Home subscriber in SF, 1.1.1.1 is approximately 3x as fast as Comcast's own DNS (testing using dig).

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

#573

Post by mattparlane »

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…

Cafe in Chiang Rai, Thailand:

    $ ping -n 1.1.1.1
    round-trip min/avg/max/stddev = 16.696/18.643/22.571/2.056 ms

    $ ping -n 8.8.8.8
    round-trip min/avg/max/stddev = 38.410/45.663/57.684/8.075 ms

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

#575

Post by cwp »

cwp wrote: post #574
prdonahue wrote: post #544

Earlier quoted context omitted.

Likely that IP address is being used (inadvisably) by something on your network.

Looks that way. 1.0.0.1 works fine though.

And now, so does 1.1.1.1. I suspect it was something sonic.net was doing, and they had to fix it when this announcement was made.

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

#576

Post by djsumdog »

QasimK wrote: post #306
slowsun wrote: post #238

> What many Internet users don't realize is that even if you're visiting a website that is encrypted — has the little green lock in your browser — that doesn't keep your DNS resolver from knowing the identity of all the sites you visit. That means, by default, your ISP, every wifi network you've connected to, and your mobile network provider have a list of every site you've visited while using them. > Network operato…

It’s a step in the right direction. Also is TLS1.3. not supposed to encrypt SNI?

I thought this was one of the big contentious issues with TLS1.3, that got resolved in a recent spec approval?

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

#578

Post by bgdkbtv »

Tree1993 wrote: post #549
matthberg wrote: post #536

Earlier quoted context omitted.

Ping from University of Rochester, over wifi: Cloudflare: 64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=9 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=2 ms Google: 64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=12 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 t…

Beijing: PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=52 time=241.529 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=318.034 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=337.291 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=52 time=255.748 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=52 time=247.765 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=52 time=235.611 ms 64 bytes from 1.1.1.1: icmp_seq…

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

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

#579

Post by alwillis »

cpeterso wrote: post #398

Here are instructions for testing DoH (DNS-over-HTTPS) in Firefox Nightly: https://gist.github.com/mcmanus/766a9564a51325b6543644983539...

DoH on Firefox nightly working great:

    Version: 61.0a1 (2018-04-01)
    OS: macOS High Sierra 10.13.4 (17E199)

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

#580

Post by bigiain »

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…

Pretty sure that google time for Sydney is an outlier

This is from my residential ADSL2 connection in Sydney:

  [Bigs-MacBook-Pro-2:~] bigiain% ping 8.8.8.8
  PING 8.8.8.8 (8.8.8.8): 56 data bytes
  64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=21.257 ms
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=25.831 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=22.231 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=21.498 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  4 packets transmitted, 4 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 21.257/22.704/25.831/1.841 ms
  [Bigs-MacBook-Pro-2:~] bigiain% 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=59 time=22.481 ms
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=38.814 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.923 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.911 ms
  ^C
  --- 1.1.1.1 ping statistics ---
  4 packets transmitted, 4 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 19.911/25.282/38.814/7.882 ms
And this is from an ec2 instance is ap-southeast-2:

  ubuntu@ip-172-31-xx-xx:~$ ping 8.8.8.8
  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=2.24 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=2.27 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=2.30 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=2.26 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=2.31 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=2.25 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  6 packets transmitted, 6 received, 0% packet loss, time 5007ms
  rtt min/avg/max/mdev = 2.244/2.274/2.310/0.066 ms
  ubuntu@ip-172-31-xx-xx:~$ ping 1.1.1.1
  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=1.03 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=1.05 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=1.05 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=1.01 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=1.07 ms
  ^C
  --- 1.1.1.1 ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 1.015/1.046/1.076/0.035 ms
Post reply on HN