Most active commenters
  • chrissnell(3)
  • hartator(3)

←back to thread

1.1.1.1: Fast, privacy-first consumer DNS service

(blog.cloudflare.com)
1895 points _l4jh | 63 comments | 01 Apr 18 12:14 UTC | HN request time: 0.42s | source | bottom
Show context
cleanbrowsing ◴[01 Apr 18 17:09 UTC] No.16729310[source]▶
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 msec           2 msec           1 msec           189 msec         
  Sydney                             1 msec           130 msec         1 msec           165 msec
Very impressive CloudFlare.
replies(20): >>16729423 #>>16729467 #>>16729545 #>>16729560 #>>16729939 #>>16729952 #>>16730034 #>>16730110 #>>16730198 #>>16730229 #>>16730567 #>>16730893 #>>16731389 #>>16732068 #>>16732273 #>>16732936 #>>16733149 #>>16733462 #>>16733833 #>>16761330 #
1. chrissnell ◴[01 Apr 18 17:43 UTC] No.16729467[source]▶
Where are you testing from? I'm going to guess: a datacenter. Residential customers won't see anything this fast. I'm in a small town in Kansas, connected by 1 Gbit ATT fiber. I'm getting ~26ms to 1.1.1.1 and ~19ms to my private DNS resolver that I host in a datacenter in Dallas. Google DNS comes in around 19ms.

I suspect that Cloudflare and Google DNS both have POPs in Dallas, which accounts for the similar numbers to my private resolver. My point is, low latencies to datacenter-located resolver clients is great but the advantage is reduced when consumer internet users have to go across their ISP's long private fiber hauls to get to a POP. Once you're at the exchange point, it doesn't really matter which provider you choose. Go with the one with the least censorship, best security, and most privacy. For me, that's the one I run myself.

Side note: I wish AT&T was better about peering outside of their major transit POPs and better about building smaller POPs in regional hubs. For me, that would be Kansas City. Tons of big ISPs and content providers peer in KC but AT&T skips them all and appears to backhaul all Kansas traffic to DFW before doing any peering.

replies(9): >>16729476 #>>16730076 #>>16730117 #>>16730356 #>>16731306 #>>16731480 #>>16732326 #>>16732414 #>>16733837 #
2. hartator ◴[01 Apr 18 17:44 UTC] No.16729476[source]▶
If you are on ethernet, I am able to get 1-2ms pings. On same AT&T Fiber Gigabit. Wifi ruins both bandwidth and latency for me.
replies(3): >>16729519 #>>16729537 #>>16729994 #
3. cthalupa ◴[01 Apr 18 17:52 UTC] No.16729519[source]▶
You should invest in some better wifi gear, it sounds like!

On a Unifi nano hd, with moderate signal, my latency only goes up 1ms.

Getting ~3.5 ms on wifi to 1.1.1.1, ~2.5ms ethernet

replies(3): >>16729656 #>>16730628 #>>16731784 #
4. chrissnell ◴[01 Apr 18 17:55 UTC] No.16729537[source]▶
I'm on Ethernet and fiber all the way. This may have to do more with how AT&T has constructed their fiber in this region. Where do you live?

https://chrissnell.com/hn/traceroute-1.1.1.1.png

replies(2): >>16729662 #>>16730420 #
5. hartator ◴[01 Apr 18 18:17 UTC] No.16729656{3}[source]▶
That's impressive. My AT&T wifi router caps bandwidth at 300mb/s (instead of 1gbs on ethernet) and add 10-20 ms to latency. And this is standing next to it and using 5ghz.
6. hartator ◴[01 Apr 18 18:18 UTC] No.16729662{3}[source]▶
Austin, TX.
7. nodesocket ◴[01 Apr 18 19:33 UTC] No.16729994[source]▶
AT&T Fiber Gigabit in Nashville TN.

    iMac   ~ 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=64 time=0.688 ms
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.814 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.153 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=0.752 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=0.755 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=0.789 ms
    64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=0.876 ms
    64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=0.869 ms
    64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=0.830 ms
    64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.387 ms
    --- 1.1.1.1 ping statistics ---
    10 packets transmitted, 10 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.688/0.891/1.387/0.204 ms
Pinging 8.8.8.8 averages 8ms. CloudFlare must have a POP here in Nashville?
replies(3): >>16730334 #>>16731984 #>>16735821 #
8. PeterStuer ◴[01 Apr 18 19:53 UTC] No.16730076[source]▶
Small village next to a provincial town in Europe on Cable: getting 11ms avg.
replies(1): >>16732768 #
9. markbnj ◴[01 Apr 18 19:59 UTC] No.16730117[source]▶
Comcast in Northern NJ USA about 45 MI from NYC

  $ 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=56 time=10.8 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=11.3 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=10.7 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=10.9 ms

  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=60 time=10.7 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=11.3 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=11.1 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=10.5 ms
replies(1): >>16730452 #
10. chrissnell ◴[01 Apr 18 20:42 UTC] No.16730334{3}[source]▶
Given that they're a CDN, I would expect them to. I'm jealous that BNA has AT&T peering but Kansas City has minimal/no peering.
11. magoghm ◴[01 Apr 18 20:48 UTC] No.16730356[source]▶
I'm in Mexico:

1.1.1.1 60 ms

8.8.8.8 20 ms

12. thomas88 ◴[01 Apr 18 21:03 UTC] No.16730420{3}[source]▶
How did you get that beautiful traceroute output?
replies(1): >>16730637 #
13. Nition ◴[01 Apr 18 21:09 UTC] No.16730452[source]▶
From a residential connection in New Zealand:

    $ ping 1.1.1.1

    Pinging 1.1.1.1 with 32 bytes of data:
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60

    $ ping 8.8.8.8

    Pinging 8.8.8.8 with 32 bytes of data:
    Reply from 8.8.8.8: bytes=32 time=27ms TTL=60
    Reply from 8.8.8.8: bytes=32 time=27ms TTL=60
    Reply from 8.8.8.8: bytes=32 time=27ms TTL=60
    Reply from 8.8.8.8: bytes=32 time=28ms TTL=60
Seems that 1.1.1.1 is even faster than my local ISP's primary DNS:

    $ ping 202.180.64.10

    Pinging 202.180.64.10 with 32 bytes of data:
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
replies(3): >>16730673 #>>16731176 #>>16731263 #
14. fudgy73 ◴[01 Apr 18 21:43 UTC] No.16730628{3}[source]▶
Out of curiosity, what is your complete Unifi / network setup?
replies(1): >>16785420 #
15. tekacs ◴[01 Apr 18 21:45 UTC] No.16730637{4}[source]▶
The GP is using mtr:

https://en.m.wikipedia.org/wiki/MTR_(software)

16. RantyDave ◴[01 Apr 18 21:51 UTC] No.16730673{3}[source]▶
Four! I'm getting 14 from fibre in Wellington. Google are 35 ish.
17. lancewiggs ◴[01 Apr 18 23:36 UTC] No.16731176{3}[source]▶
Residential in Auckland, NZ (Vibe, UFB)

64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=0.966 ms

Outstanding.

64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=25.478 ms

Not so great.

18. spludge ◴[01 Apr 18 23:58 UTC] No.16731263{3}[source]▶
Fastest Bigpipe residential connection available in the middle of Auckland:

  $ ping -c 4 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=56 time=29.0 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=27.7 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=30.5 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=28.6 ms
  
  --- 1.1.1.1 ping statistics ---
  4 packets transmitted, 4 received, 0% packet loss, time 3004ms
  rtt min/avg/max/mdev = 27.731/28.993/30.573/1.028 ms

  $ ping -c 4 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=27.7 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=30.7 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=28.5 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=30.6 ms

  --- 8.8.8.8 ping statistics ---
  4 packets transmitted, 4 received, 0% packet loss, time 3005ms
  rtt min/avg/max/mdev = 27.772/29.409/30.710/1.280 ms
I'm starting to feel I should change ISPs...
replies(2): >>16731458 #>>16740129 #
19. sesutton ◴[02 Apr 18 00:07 UTC] No.16731306[source]▶
I think AT&T's fiber modems are using 1.1.1.1. I'm getting < 1ms ping times and according to Cloudflare's website there's no data center close enough to me for that to be possible without violating the speed of light.
replies(1): >>16731739 #
20. mwilcox ◴[02 Apr 18 00:50 UTC] No.16731458{4}[source]▶
On WiFi in Cambridge NZ

  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=59 time=7.65 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=8.53 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=10.2 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=8.04 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=7.92 ms
  64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=7.85 ms
  64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=7.88 ms
  64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=7.73 ms
  64 bytes from 1.1.1.1: icmp_seq=9 ttl=59 time=7.73 ms
21. matthberg ◴[02 Apr 18 00:57 UTC] No.16731480[source]▶
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 time=11 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=13 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=45 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=14 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=11 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=34 ms
Quad9:

  64 bytes from 9.9.9.9: icmp_seq=0 ttl=53 time=10 ms
  64 bytes from 9.9.9.9: icmp_seq=1 ttl=53 time=69 ms
  64 bytes from 9.9.9.9: icmp_seq=2 ttl=53 time=14 ms
  64 bytes from 9.9.9.9: icmp_seq=3 ttl=53 time=58 ms
  64 bytes from 9.9.9.9: icmp_seq=4 ttl=53 time=52 ms
One thing I noticed is that when I first pinged 1.1.1.1 I got 14ms, which then quickly dropped to ~3ms consistently:

  64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=14 ms
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=14 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=3 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=1 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=128 time=4 ms
replies(6): >>16731753 #>>16731779 #>>16731866 #>>16732407 #>>16732515 #>>16733059 #
22. f2n ◴[02 Apr 18 02:00 UTC] No.16731739[source]▶
what happens if you go to https://1.1.1.1 in a browser? It should have a valid TLS cert and have a big banner that says, among other things, "Introducing 1.1.1.1". If your ISP's CPE or anything else is fucking with traffic to that IP, it wont load/display that
replies(2): >>16731813 #>>16731834 #
23. Tree1993 ◴[02 Apr 18 02:02 UTC] No.16731753[source]▶
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=6 ttl=52 time=239.427 ms
  64 bytes from 1.1.1.1: icmp_seq=7 ttl=52 time=247.911 ms
  64 bytes from 1.1.1.1: icmp_seq=8 ttl=52 time=260.911 ms
  64 bytes from 1.1.1.1: icmp_seq=9 ttl=52 time=281.153 ms
  64 bytes from 1.1.1.1: icmp_seq=10 ttl=52 time=300.363 ms
  64 bytes from 1.1.1.1: icmp_seq=11 ttl=52 time=234.296 ms
replies(4): >>16732175 #>>16732615 #>>16732754 #>>16732978 #
24. shaklee3 ◴[02 Apr 18 02:09 UTC] No.16731779[source]▶
It might be your isp caching the DNS in a local data center after you first request it
replies(1): >>16731825 #
25. snuxoll ◴[02 Apr 18 02:09 UTC] No.16731784{3}[source]▶
Man, wish I could ever get pings this low - the link from my VDSL2 model to the local CenturyLink CO alone is 8-15ms depending on the day.

Sucks that VDSL2 no longer supports fastpath, not that I could use it on an ADSL line due to bonding anyway :/

26. sesutton ◴[02 Apr 18 02:16 UTC] No.16731813{3}[source]▶
I just get connection refused.
replies(2): >>16731926 #>>16731996 #
27. jasongill ◴[02 Apr 18 02:22 UTC] No.16731825{3}[source]▶
There is no DNS involved when you're connecting directly to an IP address
replies(1): >>16731876 #
28. asd ◴[02 Apr 18 02:23 UTC] No.16731834{3}[source]▶
Here's what I'm seeing.

https://i.imgur.com/piisG5D.jpg

29. dannyw ◴[02 Apr 18 02:30 UTC] No.16731866[source]▶
It could be a technique they use to filter out all the junk traffic.
30. rootusrootus ◴[02 Apr 18 02:34 UTC] No.16731876{4}[source]▶
Unless you tell it not to, ping will try a reverse lookup on the IP you are pinging in order to display that to you in the output. It's a good idea to keep that in mind when you ping something, especially if you notice the first ping is abnormally slow.
replies(1): >>16731945 #
31. f2n ◴[02 Apr 18 02:46 UTC] No.16731926{4}[source]▶
Call your ISP and ask them why they're blocking access to some websites. Ask them if there are any other websites they're blocking. Tweet about it. Etc
32. dingo_bat ◴[02 Apr 18 02:52 UTC] No.16731945{5}[source]▶
That reverse lookup time is not counted in the first ping.
replies(1): >>16734357 #
33. mxpxrocks10 ◴[02 Apr 18 03:00 UTC] No.16731984{3}[source]▶
haha, I knew that was you when I read Nashville, nodesocket
34. dubya ◴[02 Apr 18 03:02 UTC] No.16731996{4}[source]▶
I'm getting this on Comcast in Knoxville. https://1.0.0.1 works fine, and https://1.1.1.1 works on my phone if I turn off wifi.
35. bgdkbtv ◴[02 Apr 18 03:49 UTC] No.16732175{3}[source]▶
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
replies(3): >>16732296 #>>16732349 #>>16732580 #
36. marcus_holmes ◴[02 Apr 18 04:18 UTC] No.16732296{4}[source]▶
Cambodia - crappy office wifi

  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.806 ms
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=23.321 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=24.379 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=25.869 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=24.485 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=24.165 ms

  PING 8.8.8.8 (8.8.8.8): 56 data bytes
  64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=23.005 ms
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=22.867 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=24.461 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=23.680 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=35.581 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=21.033 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=41.634 ms
replies(1): >>16732480 #
37. alwillis ◴[02 Apr 18 04:25 UTC] No.16732326[source]▶
I’m getting similar ping times from my Digital Ocean droplet in one of their NYC data centers where my website is hosted:

    PING 1.1.1.1 (1.1.1.1): 56 data bytes

    --- 1.1.1.1 ping statistics ---
    10 packets transmitted, 10 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 1.335/1.431/1.517/0.053 ms
38. brod ◴[02 Apr 18 04:31 UTC] No.16732349{4}[source]▶
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
replies(1): >>16733782 #
39. tayo42 ◴[02 Apr 18 04:46 UTC] No.16732407[source]▶
Something interesting I saw pointed out on the reddit thread about this is the ttl between 1.1.1.1 and 8.8.8.8 is the ttl is way different.

Your pings also have the same thing showing up 128 vs 53. I tried on my laptop and get something simmilar. traceroute to 1.1.1.1 is 1 hop which is wrong. 1.0.0.1 shows a few hops.

`dig google.com @1.1.1.1` doesn't work for me.

40. deathanatos ◴[02 Apr 18 04:48 UTC] No.16732414[source]▶
> Residential customers won't see anything this fast.

The standard Comcast black-box router/modem I have has a mean ping of ~9ms, and a min of ~3ms, so yeah, I'd have to agree.

(I get ~28ms to 1.1.1.1.)

41. kukkukb ◴[02 Apr 18 05:08 UTC] No.16732480{5}[source]▶
Johannesburg, South Africa. 100mb/s home fibre:

  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=58 time=1.36 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.32 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.34 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=1.38 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.37 ms

  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=56 time=1.33 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=1.38 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=1.35 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=1.36 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=1.35 ms
42. alea12 ◴[02 Apr 18 05:25 UTC] No.16732515[source]▶
From Tokyo, Japan:

$ 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=58 time=111.781 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=102.982 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=102.206 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=110.135 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=110.085 ms

$ 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=58 time=6.886 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=5.475 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=5.674 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=5.557 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=7.066 ms

$ ping 9.9.9.9 PING 9.9.9.9 (9.9.9.9): 56 data bytes 64 bytes from 9.9.9.9: icmp_seq=0 ttl=58 time=5.880 ms 64 bytes from 9.9.9.9: icmp_seq=1 ttl=58 time=5.534 ms 64 bytes from 9.9.9.9: icmp_seq=2 ttl=58 time=5.251 ms 64 bytes from 9.9.9.9: icmp_seq=3 ttl=58 time=5.194 ms 64 bytes from 9.9.9.9: icmp_seq=4 ttl=58 time=5.698 ms

43. predakanga ◴[02 Apr 18 05:45 UTC] No.16732580{4}[source]▶
Interesting that they're announcing 1.1.1.1 in Australia, while their CDN traffic still goes via Hong Kong
replies(1): >>16733005 #
44. oldsharp ◴[02 Apr 18 05:54 UTC] No.16732615{3}[source]▶
Hangzhou:

    $ ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    Request timeout for icmp_seq 4
    Request timeout for icmp_seq 5
    Request timeout for icmp_seq 6
    Request timeout for icmp_seq 7
    Request timeout for icmp_seq 8
    Request timeout for icmp_seq 9
    Request timeout for icmp_seq 10

    $ ping 1.0.0.1
    PING 1.0.0.1 (1.0.0.1): 56 data bytes
    64 bytes from 1.0.0.1: icmp_seq=0 ttl=50 time=167.359 ms
    64 bytes from 1.0.0.1: icmp_seq=1 ttl=50 time=165.791 ms
    64 bytes from 1.0.0.1: icmp_seq=2 ttl=50 time=165.846 ms
    64 bytes from 1.0.0.1: icmp_seq=3 ttl=50 time=166.755 ms
    64 bytes from 1.0.0.1: icmp_seq=4 ttl=50 time=166.694 ms
    64 bytes from 1.0.0.1: icmp_seq=5 ttl=50 time=166.088 ms
    64 bytes from 1.0.0.1: icmp_seq=6 ttl=50 time=166.460 ms
    64 bytes from 1.0.0.1: icmp_seq=7 ttl=50 time=166.668 ms
    64 bytes from 1.0.0.1: icmp_seq=8 ttl=50 time=166.753 ms
    64 bytes from 1.0.0.1: icmp_seq=9 ttl=50 time=165.670 ms
    64 bytes from 1.0.0.1: icmp_seq=10 ttl=50 time=166.816 ms
Seem not China friendly :-(
45. anielsen ◴[02 Apr 18 06:34 UTC] No.16732754{3}[source]▶
Copenhagen:

  PING 1.1.1.1 (1.1.1.1): 56 data bytes
  64 bytes from 1.1.1.1: icmp_seq=0 ttl=55 time=14.053 ms
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=12.715 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=13.615 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=14.018 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=12.261 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=11.428 ms
  64 bytes from 1.1.1.1: icmp_seq=6 ttl=55 time=11.950 ms
  64 bytes from 1.1.1.1: icmp_seq=7 ttl=55 time=13.034 ms
  64 bytes from 1.1.1.1: icmp_seq=8 ttl=55 time=13.679 ms
  64 bytes from 1.1.1.1: icmp_seq=9 ttl=55 time=12.415 ms
  64 bytes from 1.1.1.1: icmp_seq=10 ttl=55 time=12.088 ms
replies(2): >>16735753 #>>16738765 #
46. robarr ◴[02 Apr 18 06:38 UTC] No.16732768[source]▶
from Lima, Peru

PING 1.0.0.1: 64 data bytes

--- 1.0.0.1 ping statistics ---

14 packets transmitted, 14 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 120.784/126.222/128.433/2.036 ms

1.1.1.1 timed out, must be blocked by my iso.

47. karthikkolli ◴[02 Apr 18 07:41 UTC] No.16732978{3}[source]▶
PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=61 time=15.860 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=61 time=15.799 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=61 time=15.616 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=15.769 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=61 time=15.431 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=61 time=16.459 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=61 time=15.860 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=61 time=15.930 ms
48. djd20 ◴[02 Apr 18 07:49 UTC] No.16733005{5}[source]▶
Dubai: PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=48.728 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=48.450 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=47.266 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=45.320 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=46.470 ms
49. 6t6t6t6 ◴[02 Apr 18 08:02 UTC] No.16733059[source]▶
Tokyo, domestic 2Gbps FO but connected through Wifi:

    PING 1.1.1.1 (1.1.1.1): 56 data bytes
    64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=5.531 ms
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=4.420 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=5.450 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=5.438 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=4.231 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=5.933 ms



    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=6.440 ms
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=4.574 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=4.684 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=4.992 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=5.942 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=5.955 ms
50. bgdkbtv ◴[02 Apr 18 11:50 UTC] No.16733782{5}[source]▶
Woah! That's pretty good. Mine was on Belong NBN in Brisbane.
51. luochen1990 ◴[02 Apr 18 12:05 UTC] No.16733837[source]▶
HangZhou:

  Pinging 1.1.1.1 with 32 bytes of data:
  Reply from 1.1.1.1: bytes=32 time=1ms TTL=128
  Reply from 1.1.1.1: bytes=32 time=1ms TTL=128
  Reply from 1.1.1.1: bytes=32 time=1ms TTL=128
  Reply from 1.1.1.1: bytes=32 time=2ms TTL=128

  Pinging 8.8.8.8 with 32 bytes of data:
  Reply from 8.8.8.8: bytes=32 time=91ms TTL=37
  Request timed out.
  Reply from 8.8.8.8: bytes=32 time=66ms TTL=37
  Request timed out.

  Pinging 1.0.0.1 with 32 bytes of data:
  Reply from 1.0.0.1: bytes=32 time=146ms TTL=50
  Reply from 1.0.0.1: bytes=32 time=144ms TTL=50
  Reply from 1.0.0.1: bytes=32 time=142ms TTL=50
  Reply from 1.0.0.1: bytes=32 time=140ms TTL=50
52. rootusrootus ◴[02 Apr 18 13:41 UTC] No.16734357{6}[source]▶
Perhaps that depends on operating system. In the 30 years I have been using ping on Linux, the reverse lookup time is absolutely included in the first ping time.
replies(1): >>16736195 #
53. MarcysVonEylau ◴[02 Apr 18 16:03 UTC] No.16735753{4}[source]▶
Pinging 1.1.1.1 with 32 bytes of data: Reply from 89.228.6.1: Destination net unreachable. Reply from 89.228.6.1: Destination net unreachable. Reply from 89.228.6.1: Destination net unreachable. Reply from 89.228.6.1: Destination net unreachable.

Any idea why my ISP redirects this IP?

replies(1): >>16738979 #
54. dragonwriter ◴[02 Apr 18 16:09 UTC] No.16735821{3}[source]▶
That's probably because AT&T is using 1.1.1.1 for something internal and breaking the public internet for it's users: you get a really fast ping on 1.1.1.1, but it's not the 1.1.1.1 you are trying to reach.
replies(2): >>16737376 #>>16772158 #
55. dingo_bat ◴[02 Apr 18 16:40 UTC] No.16736195{7}[source]▶
If true, that's a bug.

Edit: Assuming this is the right file: https://github.com/iputils/iputils/blob/master/ping.c, I don't see the reverse lookup code anywhere. But then I'm not the most proficient in reading linux code.

56. nodesocket ◴[02 Apr 18 18:12 UTC] No.16737376{4}[source]▶
Is this just speculation or can anybody confirm?

    traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
     1  1dot1dot1dot1.cloudflare-dns.com (1.1.1.1)  1.117 ms  0.710 ms  0.727 ms
replies(1): >>16741212 #
57. ◴[02 Apr 18 20:08 UTC] No.16738765{4}[source]▶
58. rashomon ◴[02 Apr 18 20:29 UTC] No.16738979{5}[source]▶
Maybe an advertisement re-direct for NXDOMAINS?
59. michaelmurfy ◴[02 Apr 18 22:41 UTC] No.16740129{4}[source]▶
BigPipe, Spark, Skinny and Vodafone don't believe in peering and thus don't peer with Cloudflare at APE. If you wanted the best performance then 2degrees, Orcon, Voyager or Slingshot are the best for this since they peer.
replies(1): >>16752297 #
60. ◴[03 Apr 18 01:41 UTC] No.16741212{5}[source]▶
61. gunkaaa ◴[04 Apr 18 05:47 UTC] No.16752297{5}[source]▶
Vodafone have come to the party and are on AKL-IX now.
62. _nickwhite ◴[06 Apr 18 10:10 UTC] No.16772158{4}[source]▶
Seems AT&T uses 1.1.1.1 inside of their modems. Oops!

Using 1.0.0.1 works.

63. cthalupa ◴[08 Apr 18 09:53 UTC] No.16785420{4}[source]▶
GW/Firewall: USG-XG Switches: 2x US-16-XG, 1x US-48, 2x US-8 APs: 2x Nano HD, 2x AC Pro