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
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
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
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.
8.8.8.8 and 8.8.4.4 are separate allocations - both /24.
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.
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.
i see what you did there. hopefully they can improve things.
[1] https://developers.google.com/speed/public-dns/privacy
[2] https://www.quad9.net/#/faq#does-quad9-collect-and-store-per...
If you want a more private DNS look at OpenNIC [0].
[0] - https://www.opennic.org/
172.104.136.243 (ns2.he.de): 96.51% uptime
5.135.183.146 (ns12.fr): 95.63% uptime
Now that is some uptime I want for my DNS...
That way, nobody can log and aggregate the queries you run, and nobody can mess with it either, unless they manage to break DNS itself in a big way.
"When an entity or an individual is using the Quad9 infrastructure, their IP address is not logged in our system. We, however, log the geo-location of the system (city, state, country) and use this information for malicious campaign and actor analysis, as well as a component of the data we provide our threat intelligence partners. "
Not logged in 'our' system, reads to me, it is still logged somewhere. And the 'data we provide our threat intelligence partners', seems a little too vague for my likings.
We do for a short period of time have the ip address in memory, it is very quickly used to do a geo location look up, that data (the geo location data) then essentially replaces the src ip in the data structure that is used in our logs and telemetry. We can of course as outlined in that page during times of ddos or troubleshooting enable a higher level set (thing router/infrastructure) set of logging that could provide that data to the infrastructure operator (pch). When that occurs that data is not mixed with the “daily operational data” that is generated by the normal functioning of the system. This is/was the best balance we could come up with to maintain privacy and ability to mitigate/resolve technical issues with infrastructure and the operation of what we do with telemetry around blocks in the system.
So quick recap, even when things go sideways and we need to mitigate a ddos or trouble shoot weird routing/anycast/other issues and enable the capture of ip/asn’s that data is generated/processed/used seleratley than the telemtry data we store, generate, and share. (On the sharing side we only share telemetery with the to vendors who gave us data to produce those blocks, so its segmented as well).
I get the same results from opendns, 8.8.8.8 etc:
$ for ns in $(cat /etc/resolv.conf | grep nameserver | awk '{print $NF}'); do dig @$ns google.de +short; done
172.217.22.67
172.217.22.67
172.217.22.67
172.217.22.67
172.217.22.67
I think I'll pass for now.
» dig @9.9.9.9 news.ycombinator.com +short
news.ycombinator.com.cdn.cloudflare.net.
104.20.44.44
104.20.43.44
I tried to archive the pages with archive.is but it did not appear to be loading for them either.
Hopefully the site comes back up soon but I have to say I expected to see yet another surveillance capitalism service and I was pleasantly surprised. I'll try it out for a week and see how it goes.
[0]https://screenshots.firefox.com/LiNdj97Ck3qaLXze/www.quad9.n... [1]https://screenshots.firefox.com/YEsWa5TwhGYQDZFZ/www.quad9.n...
The list of resolvers they have there it's not exactly obvious why I should trust any of those more? (and OpenDNS is on that list) https://dnscrypt.org/dnscrypt-resolvers.html
Here's the Turris documentation on how it handles DNS: https://www.turris.cz/doc/en/howto/dns
9.9.9.9 is allegedly with security features. 9.9.9.10 does not have any security features.
People will put 9.9.9.9 in the Primary DNS, 10 in the secondary in many of OSes.
Also What is Quad9 resolves to a video rather than a quick explanation. There is almost no information that this is a DNS server service on landing.
>It's easy to setup Quad9 on your Mac or PC. Watch the video for your operating system.
Where is Linux? I doubt people who are using those OSes will bother changing their dns.
Video is not documentation.
* Google: 8.8.8.8 * Quad9.com: 9.9.9.9 * http://OpenDNS.com: 208.67.222.222 * https://CleanBrowsing.org: 185.228.168.168
Results:
New York:
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=1.62 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=60 time=0.924 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=60 time=1.18 ms
64 bytes from 185.228.168.168: icmp_seq=2 ttl=57 time=1.93 ms
Montreal:
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=13.0 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=56 time=16.7 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=56 time=16.5 ms
64 bytes from 185.228.168.168: icmp_seq=2 ttl=50 time=9.18 ms
Dallas:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=1.09 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=59 time=29.8 ms
64 bytes from 208.67.222.222: icmp_seq=1 ttl=58 time=1.03 ms
64 bytes from 185.228.168.168: icmp_seq=1 ttl=57 time=1.29 ms
Paris:
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=4.61 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=56 time=6.71 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=56 time=4.60 ms
64 bytes from 185.228.168.168: icmp_seq=2 ttl=54 time=3.85 ms
Tokyo:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=1.10 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=55 time=65.7 ms
64 bytes from 208.67.222.222: icmp_seq=1 ttl=57 time=1.57 ms
64 bytes from 185.228.168.168: icmp_seq=1 ttl=59 time=0.551 ms
But I will still try it out and hope they keep supporting it.
Much better and more secure solution could be assembled in 15 minutes using dnscrypt-proxy with ip and domain filtering and caching. [^1]
Additionally I am always suspicious why IBM suddenly wants to collect my DNS queries? Sorry big corpo but I don’t trust your good intentions any more. We are long past the innocence of first years of the Internet.
If IBM or any other big name really wants to help with DNS security why don’t they give financial and material help to heroes like jedisct1, Martin 'd0wn' Albus, soltysiak and others who put their time, effort and money into running DNSCrypt servers? Money plunged just in design of Quad9 webpage they could have kept some servers running for years[^2]
[1] https://github.com/jedisct1/dnscrypt-proxy/wiki
[2] According to soltysiak his monthly costs are c.a. 40€/month but as it is his private expense he had to limit memory in his server.
Doesn't DDoS defense fall in the "internet threat protection" bucket? :p
Maybe it's better now, but a couple years back I found streaming iTunes movies (I think Apple used Akamai at the time and may still) would not work at all if not using my ISP's DNS servers. So I had to configure dnsmasq to forward CDN domain lookups to my ISP's DNS servers.
I wonder if a good compromise for EDNs w.r.t. privacy would be that instead of forwarding the client subnet, instead have a lookup table mapping the client IP to their ISP's DNS servers, and then insert subnet of the ISP's DNS servers. I suppose it could be any "representative" subnet of the client ISP though.
Also, minor typo in the FAQ answer for "Does Quad9 implement DNSSEC?": "... Note that some variations of our resolver (differente IP addresses) may not provide DNSSEC."
Different has an extraneous trailing "e".
From US:
# ./dnseval.py -f google-vs-quad9.txt -c 50 -C yahoo.com
server avg(ms) min(ms) max(ms) stddev(ms) lost(%) ttl flags
----------------------------------------------------------------------------------------------------
8.8.8.8 31.857 31.278 33.416 0.434 %0 1332 QR -- -- RD RA -- --
8.8.4.4 31.865 31.361 32.872 0.336 %0 1330 QR -- -- RD RA -- --
9.9.9.9 93.703 92.797 95.362 0.586 %0 1391 QR -- -- RD RA -- --
# ./dnseval.py -f google-vs-quad9.txt -c 50 -C yahoo.com
server avg(ms) min(ms) max(ms) stddev(ms) lost(%) ttl flags
----------------------------------------------------------------------------------------------------
8.8.8.8 105.093 90.046 130.871 9.749 %0 3590 QR -- -- RD RA -- --
8.8.4.4 99.458 84.472 133.375 11.308 %0 3585 QR -- -- RD RA -- --
9.9.9.9 96.231 83.957 134.709 9.503 %0 3595 QR -- -- RD RA -- --
$ 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=53 time=98.011 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=53 time=96.444 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=53 time=96.556 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=53 time=96.769 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=53 time=104.274 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=53 time=102.235 ms
64 bytes from 9.9.9.9: icmp_seq=6 ttl=53 time=97.185 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=45 time=54.808 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=54.407 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=55.173 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=45 time=55.058 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=45 time=54.583 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=45 time=54.589 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=45 time=54.645 msIf they cannot handle the HN hug of death, I am not so sure if they can ward off a serious attack.
The idea - Realtime blacklisting via DNS - is not bad. But if the first impression I get is a page that loads very slowly, I am doubtful if they can implement it well.
Website is being worked, dns infrastructure is solid and working well. Sorry for brief response, a bit busy ;)
I hope you succeed. Filtering out bad actors via DNS is a good idea, you will have to be very careful about false positives, though. ;-)
I think a similar approach is already being used for mail servers to detect spam... but I am short on details, because the only mail server I have ever taken care of is the Exchange server at work, and Exchange is not all that proactive when it comes to spam.
Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 11ms, Maximum = 32ms, Average = 18ms And Pinging 9.9.9.9 with 32 bytes of data: Reply from 9.9.9.9: bytes=32 time=20ms TTL=54 Reply from 9.9.9.9: bytes=32 time=17ms TTL=54 Reply from 9.9.9.9: bytes=32 time=18ms TTL=54 Reply from 9.9.9.9: bytes=32 time=17ms TTL=54
Ping statistics for 9.9.9.9: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 17ms, Maximum = 20ms, Average = 18ms
Joking aside, shouldn't they have an alternative DNS server, too, like Google does with 8.8.4.4? Maybe 9.9.7.7 or 9.9.3.3?
149.112.112.112 - blocking, no edns (same setup/config as 9.9.9.9)
I will see about adding this to the list of things to add to documentation. (thanks for the feedback guys!)
Yes. Quad9 operates identical services on a set of IPv6 addresses, which are on the same infrastructure as the 9.9.9.9 systems.
Secure IPv6: 2620:fe::fe Blocklist, DNSSEC, No EDNS Client-Subnet
Unsecure IPv6: 2620:fe::10 No blocklist, no DNSSEC, send EDNS Client-Subnet
(Recent versions of Unbound do support it, but you might be running an older version or missing the right dependency.)
(Example zone: ed25519.nl.)
I'm sure people in the dnscrypt community would rather trust privately hosted servers but I really don't see the difference in risk.
To clarify, I have a dnsmasq but I also have a dnscrypt forwarder. Dnsmasq only resolves LAN names and forwards the rest to dnscrypt.
So I'd have to forward to a service that supports DNS over TLS to use quad9.
Edit: Unbound does this.
https://www.comodo.com/secure-dns/
8.26.56.26
8.20.247.20
Why not share the database with the public? This is meant to be a free service, isn't it?
"Quad9 is designed to provide these protections without affecting the speed that users expect when accessing websites and services."
Very careful choice of words. It does not say it will not affect the speed. It says it will not affect the "speed which user expect". What speed is that?
I already check domains against a database of ones I want to block. I do this locally using djbdns, without needing to send DNS queries over the internet. The speed is better than any third party DNS service, including 8.8.8.8 or 9.9.9.9. IMO, there is no need to send personal, private DNS queries to "18 further threat intelligence providers".
"Telemetry data on blocked domains from Quad9 will be shared with threat intelligence partners to improve their threat intelligence responses for their customers and Quad9."
Telemetry. So they are collecting data about users' DNS queries. This would explain how the service is "free".
When a user tries to access a blacklisted domain, a host of "threat intelligence partners" are notified.
"PCH, which provides Quad9's network infrastructure; and IBM, which provides IBM X-Force threat intelligence and the easily memorable IP address (9.9.9.9)."
Quad9 suggests IP addresses can be memorized. I will rememeber that.
"The personal information protections and selectable DNS encryption, DNSSEC, and blocklist that are in place show that this project is in line with PCH's values," he said. "Quad9 will inspire trust in both individuals and businesses who understand the importance of securing their private browsing data."
If someone digitally signs a document, does anyone believe the document is hence "encrypted"?
When DNSSEC is used, does anyone believe that DNS is hence "encrypted"?
A less misleading description might be something like "DNS record signing".
Using DNSSEC does not mean the DNS packets are encrypted. Anyone sniffing the network can read them.
DNSSEC also makes DDOS easier for malfeasants.
Have those providing the DNSSEC signed records and those providing DNSSEC enabled third party DNS service solved this problem yet?
I am not implying that this "service" could not be useful for users who must use third party DNS service. The question is whether users who really care about security issues must use third party DNS services.
source: http://www.computerweekly.com/news/450430188/Free-Quad9-inte...
"HQ
1442 A Walnut Street
Suite 501
Berkeley CA 94709"
source: https://www.quad9.net
Is this an office of IBM?
We should be working on that front right now.