[blfr]

Namebench says...

    Mean response (in milliseconds):
    --------------------------------
    8.8.8.8          ########### 71.90
    192.168.1.1      ############# 85.92
    9.9.9.9          ##################################################### 369.26

    Mean response (in milliseconds):
    --------------------------------
    8.8.4.4          ################# 85.49
    9.9.9.10         ################################################## 252.25
    9.9.9.9          ##################################################### 268.93

... give it some time.

[quad9_dre]

As you hinted at (i think this is where you were going with it), as our caches get nice and toasty the latency should start to come down a bit. Then as we add more nodes to the anycast cloud, that will also help. Finnally as we continue to tune our resolvers and infrastructure we should again bring latency down. I will say this, being compared against google is a very high bar to clear! Our focus will always be on trying to give the end users the best experience we can performance, security, and privacy wise. (not easy, but we will try)

[exikyut]

Thanks for the honesty.

Question: I'm in Sydney, Australia, aka the home of the most expensive bandwidth/peering in the world, IIUC :)

When I initially pinged 9.9.9.9 (I read "Quad9" and, despite having _just_ woken up, make sense of the nice name) it didn't work. Okay...

And theennnn:

  $ ping 9.9.9.9
  PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
  64 bytes from 9.9.9.9: icmp_seq=1 ttl=52 time=5006 ms
  64 bytes from 9.9.9.9: icmp_seq=2 ttl=51 time=4006 ms
  64 bytes from 9.9.9.9: icmp_seq=3 ttl=51 time=3006 ms
  64 bytes from 9.9.9.9: icmp_seq=4 ttl=51 time=2007 ms
  64 bytes from 9.9.9.9: icmp_seq=6 ttl=52 time=155 ms
  64 bytes from 9.9.9.9: icmp_seq=7 ttl=52 time=154 ms
  64 bytes from 9.9.9.9: icmp_seq=8 ttl=52 time=154 ms
  64 bytes from 9.9.9.9: icmp_seq=9 ttl=52 time=157 ms

  [a bunch of skipped lines w/ 155ms avg, 252ms peak]

  ^C

  --- 9.9.9.9 ping statistics ---
  33 packets transmitted, 27 received, 18% packet loss, time 32027ms
  rtt min/avg/max/mdev = 154.626/655.770/5006.544/1264.522 ms, pipe 6

Ahahaha nope that's not going to work for my primary DNS server. Not at this point.

For reference:

  $ 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=2 ttl=56 time=6.92 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=7.22 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=7.17 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=6.69 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=7.78 ms
  64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=6.94 ms
  64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=7.01 ms
  64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=6.77 ms
  64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=7.40 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  10 packets transmitted, 9 received, 10% packet loss, time 9010ms
  rtt min/avg/max/mdev = 6.695/7.105/7.788/0.318 ms

This is a very cool service though and I wish you the best (and hope you get enough resources thrown at you to make a real difference!).

Apparently someone else who tried to email you has found that your email address bounces. I'd like to keep in touch in case I can help with further testing. I also wonder if and how I could get further involved with this - global-scale networking is a very interesting performance optimization target, the kind of thing I find really interesting.

[lokedhs]

From Singapore:

  $ 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=60 time=2.04 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=1.96 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=2.18 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=2.10 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=1.99 ms                                   
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=60 time=1.97 ms                                   
  64 bytes from 8.8.8.8: icmp_seq=7 ttl=60 time=2.18 ms                                   
                                                                                        
  --- 8.8.8.8 ping statistics ---                                                         
  7 packets transmitted, 7 received, 0% packet loss, time 6016ms                          
  rtt min/avg/max/mdev = 1.965/2.063/2.185/0.099 ms                                       
  $ ping 9.9.9.9
  PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.                                            
  64 bytes from 9.9.9.9: icmp_seq=1 ttl=60 time=2.23 ms                                   
  64 bytes from 9.9.9.9: icmp_seq=2 ttl=60 time=2.18 ms                                   
  64 bytes from 9.9.9.9: icmp_seq=3 ttl=60 time=2.28 ms                                   
  64 bytes from 9.9.9.9: icmp_seq=4 ttl=60 time=1.97 ms
  64 bytes from 9.9.9.9: icmp_seq=5 ttl=60 time=2.05 ms
  64 bytes from 9.9.9.9: icmp_seq=6 ttl=60 time=2.22 ms
  64 bytes from 9.9.9.9: icmp_seq=7 ttl=60 time=1.93 ms
  64 bytes from 9.9.9.9: icmp_seq=8 ttl=60 time=2.08 ms
  64 bytes from 9.9.9.9: icmp_seq=9 ttl=60 time=2.17 ms
  64 bytes from 9.9.9.9: icmp_seq=10 ttl=60 time=2.05 ms
  ^C
  --- 9.9.9.9 ping statistics ---
  10 packets transmitted, 10 received, 0% packet loss, time 9018ms
  rtt min/avg/max/mdev = 1.939/2.121/2.289/0.115 ms

It's possible that their APAC mirror is in Singapore.

[josh64]

From Perth, Western Australia:

  $ ping 9.9.9.9 -c 10
  PING 9.9.9.9 (9.9.9.9): 56 data bytes
  64 bytes from 9.9.9.9: icmp_seq=0 ttl=57 time=1.014 ms
  64 bytes from 9.9.9.9: icmp_seq=1 ttl=57 time=1.038 ms
  64 bytes from 9.9.9.9: icmp_seq=2 ttl=57 time=1.023 ms
  64 bytes from 9.9.9.9: icmp_seq=3 ttl=57 time=0.918 ms
  64 bytes from 9.9.9.9: icmp_seq=4 ttl=57 time=0.968 ms
  64 bytes from 9.9.9.9: icmp_seq=5 ttl=57 time=1.121 ms
  64 bytes from 9.9.9.9: icmp_seq=6 ttl=57 time=0.946 ms
  64 bytes from 9.9.9.9: icmp_seq=7 ttl=57 time=0.978 ms
  64 bytes from 9.9.9.9: icmp_seq=8 ttl=57 time=1.001 ms
  64 bytes from 9.9.9.9: icmp_seq=9 ttl=57 time=1.140 ms

  --- 9.9.9.9 ping statistics ---
  10 packets transmitted, 10 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 0.918/1.015/1.140/0.067 ms

[exikyut]

Hmmmmmmm.

Glares at telstra what are you doing to my internet connection

(It's 11Mbps and I'm ~2.5km away from the exchange, so the line quality seems alright.)

[psandersen]

Melbourne here with ADSL2, seems to match Google...

  ~ 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=57 time=35.810 ms 64 bytes from 9.9.9.9: icmp_seq=1 ttl=57 time=35.669 ms 64 bytes from 9.9.9.9: icmp_seq=2 ttl=57 time=36.421 ms 64 bytes from 9.9.9.9: icmp_seq=3 ttl=57 time=35.021 ms 64 bytes from 9.9.9.9: icmp_seq=4 ttl=57 time=37.837 ms 64 bytes from 9.9.9.9: icmp_seq=5 ttl=57 time=36.547 ms ^C --- 9.9.9.9 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 35.021/36.217/37.837/0.882 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=36.042 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=67.986 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=36.123 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=35.603 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=43.381 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=58 time=37.085 ms ^C --- 8.8.8.8 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 35.603/42.703/67.986/11.614 ms

[jlgaddis]

Tip: indent two spaces each line of your output for proper formatting

[kartickv]

This is a great idea, and much less intrusive than antivirus software, app stores, or security prompts. Please make it faster from Bangalore, and I'll switch. Google DNS takes 18ms, and yours, 47.

[justinjlynn]

You'll want the 95th and 99th percentile latencies as well. The mean latency is what you'll experience on average but the outliers are what you'll feel badly.

[blfr]

Judging by the distribution, it's not doing better there either:

https://goo.gl/c9xBT6

https://goo.gl/cUZMDE

[quad9_dre]

god I love this place. :)

I know the PCH guys will see this post, so hopefully we can move the needle a bit more on this side of things. Thanks for taking the time to poke and provide feedback.

[atsaloli]

What does PCH mean?

[YouKnowBetter]

Packet Clearing House, partner with IBM for said service.

https://www.pch.net/

[atsaloli]

Thanks!

[BillinghamJ]

Wait, is 9.9.9.10 the secondary? That's in the same allocation as 9.9.9.9. What's the point in having a secondary if there's no real separation or redundancy?

8.8.8.8 and 8.8.4.4 are separate allocations - both /24.

[_wmd]

The most useful reason to have two addresses is for client resolvers that often demand them, assuming the whole configuration is running anycast with multiple PoPs, the extra "redundancy" provided by Google DNS is essentially meaningless thanks to BGP route aggregation, a /24 is too small to be treated uniquely for internetwork routing in the general case, and in any case, both of Google's subnets are announced by the same AS 15169. The most likely use for Google's subnet is to make the backup address more memorable.

In both networks, those IP addresses are almost certainly treated identically, virtualized to all hell with multiple physical termination points leading to the same pools of machines. One extra /24 isn't going to help reliability much if at all, especially considering it is part of the same AS.

Perhaps I'm wrong and Google use the /24 somehow for the purposes of internal routing. If that's true, in the same scenario IBM may be content to have just these two /32s in their internal tables where route aggregation could be be made to not apply.

[toast0]

Having the backup in a separate /24 allows the option of steering BGP announcements differently at different peering points (even if they aren't announced differently in the everything is working case).

[quotha]

Is there a service that Quad9 offers that does not have the blocklist or other security?

The primary IP address for Quad9 is 9.9.9.9, which includes the blocklist, DNSSEC, and other security features. However, there are alternate IP addresses that the service operates which do not have these security features. These might be useful for testing validation, or to determine if there are false positives in the Quad9 system.

Secure IP: 9.9.9.9 Blocklist, DNSSEC, No EDNS Client-Subnet

Unsecure IP: 9.9.9.10 No blocklist, no DNSSEC, send EDNS Client-Subnet

Note: Use only one of these two addresses. Some networking software may include terminology such as “Secondary DNS Server” in configuration windows; this can be left blank. Putting both 9.9.9.9 and 9.9.9.10 into “primary” and “secondary” fields may result in unsecure results in rare circumstances.

[gca_dre]

Hey guys sorry for lag in response, a bit slammed right now on our side.

9.9.9.10 does not have blocking, it also has edns enabled (so assume less privacy than 9.9.9.9 given edns will be transmitted on 9.9.9.10)

We will make sure to push out some documentation on the different services on each ip. The launch we focused on 9.9.9.9. There will be a blocking +edns ip soon we just dodnt get it done in time. :(

[0x0]

It's not the secondary, it's a different kind of service. The faq explicitly says to not mix the two in the same configuration.

[abiox]

> give it some time

i see what you did there. hopefully they can improve things.