5 ms·

Namebench says... Mean response (in milliseconds): -------------------------------- 8.8.8.8 ########### 71.90 192.168.1.1 #######

by blfr 9y ago

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.

BillinghamJ 9y ago
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.
- quotha 9y ago
  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 9y ago
    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. :(
- deleted 9y ago
  [deleted]
- _wmd 9y ago
  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 9y ago
    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).
- 0x0 9y ago
  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.
justinjlynn 9y ago
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 9y ago
  Judging by the distribution, it's not doing better there either: https://goo.gl/c9xBT6 https://goo.gl/c9xBT6 https://goo.gl/cUZMDE https://goo.gl/cUZMDE
  - quad9_dre 9y ago
    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 9y ago
      What does PCH mean?
      - YouKnowBetter 9y ago
        Packet Clearing House, partner with IBM for said service. https://www.pch.net/ https://www.pch.net/
        atsaloli 9y ago
        Thanks!
quad9_dre 9y ago
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 9y ago
  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.
abiox 9y ago
> give it some time i see what you did there. hopefully they can improve things.

by blfr 9y ago

BillinghamJ 9y ago

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.

quotha 9y ago
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 9y ago
  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. :(
deleted 9y ago
[deleted]
_wmd 9y ago
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 9y ago
  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).
0x0 9y ago
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.

justinjlynn 9y ago

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 9y ago
Judging by the distribution, it's not doing better there either: https://goo.gl/c9xBT6 https://goo.gl/c9xBT6 https://goo.gl/cUZMDE https://goo.gl/cUZMDE
- quad9_dre 9y ago
  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 9y ago
    What does PCH mean?
    - YouKnowBetter 9y ago
      Packet Clearing House, partner with IBM for said service. https://www.pch.net/ https://www.pch.net/
      - atsaloli 9y ago
        Thanks!

quad9_dre 9y ago

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 9y ago
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.

abiox 9y ago

> give it some time i see what you did there. hopefully they can improve things.