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)
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.
$ 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.
$ 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
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.
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.
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.
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.
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.
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).
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.
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. :(
Looks like an interesting alternative to Google DNS (8.8.8.8), and possibly a little more anonymous. Google logs your IP address for 24 - 48 hours[1], while Quad9 appears not to[2].
Yes, but typically such a server is either on a private network behind a NAT gateway and/or firewall, or it has a clearly defined set of addresses from which it will accept queries.
At least that is what I would do if I had to set up a recursive resolver. Mine sits in my private network at home behind a NAT router, so the chance of an attacker reaching it is small. If I were responsible for a nameserver with a public IP address, reachable from every corner of the Internet, I would seriously restrict whose queries it answers for a number of reasons. The one you mentioned among them, but also things like DNS cache poisoning.
TBH I am a little surprised that there have not been any large scale attacks on the DNS infrastructure, considering the fact that any sort of security was bolted on to DNS as an afterthought. DNSSEC is a step forward, but I have no clue if any resolvers and/or clients make use of it.
> TBH I am a little surprised that there have not been any large scale attacks on the DNS infrastructure, considering the fact that any sort of security was bolted on to DNS as an afterthought. DNSSEC is a step forward, but I have no clue if any resolvers and/or clients make use of it.
There have been _lots_ of large scale attacks on DNS infrastructure. DDoS against root servers, TLD servers, and well known nameservers is commonplace; occasionally with some success. Because DNS is mostly UDP, it works well with anycast, and anycast with many pops is a great way to handle traffic from a big DDoS. There's also a lot of good decisions in the protocol/general implementations that reduce the impact of outages.
DNSSEC is a bolt on intended to address response forgery, it doesn't address DDoS.
> There have been _lots_ of large scale attacks on DNS infrastructure.
Huh, I did not know that. Fascinating!
What I meant was that there have not been any disturbances that had widespread consequences; imagine that one day, out of nothing, it is impossible to get an answer for the .com zone, just for an hour or so. In my mind I see the news reporting about this the way they would report about a hurricane or earthquake. Unless a lot of their broadcasting / distribution also would be out of order. ;-)
Here's a blog entry [1] about an attack in 2016, with some references to other attacks.
The thing is, you have to maintain an attack for a long time to effectively disrupt service.
The root zone is published -- I imagine large recursive caches may use a local copy, rather than actually querying the root servers; but if they do query the root, the TTLs are 2 days; there's a pretty good chance your recursive resolver will have com. cached. The com. servers also give a 2 day TTL, so for popular domains, there's a good chance those are cached too. DDoS on the nameservers for domains can be effective, though. Even then, it's usually not a total outage.
A recursive resolver does not need to forward queries. ;-)
Conceptually, it starts with the root nameservers and works its way up - dot by dot, recursively, hence the name - until it finds the domain the host in question in it, then asks the nameservers for that zone and caches the result.
It is possible - with BIND9 at least, but I guess other DNS servers offer similar capabilities - to use forward servers for convenience/caching or to redirect queries to specific servers depending on the name in the query. But it is not mandatory.
heh i hope you are kidding :) of course they log.. edit perhaps not YOUR ip address, but enough to identify users. AS number + extra data is almost as good as IP.
"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.
So a quick explanation of what we do. (Its on the website as well, sorry if my response latency is high)
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).
And i think thats perfectly normal. People basically demanding free public services and the operator of that service can't log anything.. thats what i have problems with :)
You shouldn't use it in Germany or Europe. It resolves www.google.de with an IP based in SFO, instead of a local Google server. Even 9.9.9.10 (which is said to support EDNS Client Subnet) doesn't work.
This is a byproduct of edns not being transmitted on 9.9.9.9 resolutions for privacy reasons. 9.9.9.10 will transmit edns, but has no blocking. Soon we will release another ip that will have blocking+edns transmission on it, as well as documentation outlining all this and the differences. We just ran out of time for all that and focused on 9.9.9.9. Sorry for any inconvenience on your end. (Also sorry if my response latency is high, im a big fan of this community so im focusing my attention here as best i can)
Thank you for responding. I think four different DNS IPs on your side could be a little overkill for the standard user in terms of choosing the 'right' one. Apart from that, good luck with the product!
Totally understand, we are trying to find the right balance for those that need options. We can always shift how we present things, configurations, technologies implemented etc based on end users feedback. We really do want folks to help us make this system better.
Yep, pretty much all of Google's internal and premium GCP network is Anycast. You'll be terminated to Google's network on your continent, no matter what the DB says: Obviously that's impossible to tag correctly in any GeoIP database.
After recently setting up Pi-hole on my Turris Omnia I had to choose between using Google's DNS (which supports DNSSEC) or sticking with OpenDNS (which does not...yet?), so I gave up using DNSSEC. The submitted IBM site is really slow to load but I did manage to grab a screenshot of the FAQ page[0] which confirms they do support it. And the privacy policy looks pretty good also[1].
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.
Which still requires you to pick a resolver you trust to send your (then encrypted) traffic to, and if the parent wants DNSSEC it still requires them to find one that supports that (DNSCrypt is not a replacement for DNSSEC)
Could be wrong but it is my understanding that the Omnia either does not support it or it needs additional configuration, which I wasn't interested in performing. Since I was using Pi-hole anyway I stuck with that. Fair question though, not sure about the down-votes you've received.
Hi this is Alex from GCA! Could you please run `dig +short @9.9.9.9 id.server TXT chaos` and post the results here? That will help us troubleshoot. Thanks!
I wrote you an email to the address in your profile but got a failure notice:
Sorry, we were unable to deliver your message to the following address.
<CTO@globalcyberalliance.org>:
550: 5.1.1 The email account that you tried to reach does not exist.
I have a new rule: if I have to watch a video to understand the 'value proposition' or even what something does, I will close the browser tab and keep looking.
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
Only New York and Paris were close. Their performance in Tokyo & Dallas were sub optimal. OpenDNS has a much better performance and closer to Google than quad9.
But I will still try it out and hope they keep supporting it.
Sending DNS queries in open does not protect from DNS hijacking which is ubiquitous in SE Asia for example. So you end up getting ‘free security solution’ that at the last mile is deliberately slowed down, registered and falsified.
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]
Re: "In some circumstances this may result in suboptimal routing between CDN origins and end users."
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."
$ 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 ms
Ironically, the page takes forever to load for me.
If 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.
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.
DNSBLs [0] are very popular. Pretty much anyone running a mail server that accepts connectiona from the public Internet use them -- you have to! I manage several mail servers and I use many different DNSBLs, including one of my own.
The best anti-spam advice I could give WRT your Exchange box (I've managed those too) is to put another box in front of it to handle the spam filtering (Postfix + SpamAssassin + friends in my case, but you have many options), though IIRC even Exchange can directly use these blacklists nowadays.
fm malaysia:
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=17ms TTL=54
Reply from 8.8.8.8: bytes=32 time=12ms TTL=54
Reply from 8.8.8.8: bytes=32 time=32ms TTL=54
Reply from 8.8.8.8: bytes=32 time=11ms TTL=54
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
I hope one of those planned locations will be somewhere in Eastern Europe. At the moment I measure a 44ms ping, which is just 1ms slower than 8.8.8.8, and 2ms faster than OpenDNS for this location.
if it's anycast, it shouldn't matter. if the first IP is down, chances are the second one would be down as well, unless they announce the IPs seperately or something.
Hey, you support Ed25519! Only some of the time -- I'd bet your PowerDNS resolvers support it but your Unbound ones don't -- but you might be the first public recursive DNS provider to support Ed25519 at all.
(Recent versions of Unbound do support it, but you might be running an older version or missing the right dependency.)
I know this has been mentioned already, to much lament... but if companies like google and ibm were really serious about hosting a DNS service to promote privacy and securit they should host a dnscrypt interface to it.
I'm sure people in the dnscrypt community would rather trust privately hosted servers but I really don't see the difference in risk.
We currently support DNS over TLS, and are looking at other options in the space. So if folks want dnscrypt I can take that feedback back to the team and see what we can do for you guys. From my perspective the calculation on private encrypted dns server over something like our service comes down to your threat model. We are trying our best to be as transparent as we can on what we do, how we do it etc so we can earn trust. That being said, trusting any thing you dont 100% control and 100% monitor every little thing on starts to erode absolute security/privacy/control. The one thing that sets us aside from a private server is the infrastructure we use, it is a growing anycast cloud spread across the globe, that with usage (helllooo hot cache's!) should provide better performance then a single locale/remote recursive server (or chain of servers).
I'm pleasantly surprised that you support DNS over TLS but I barely know how to use that. Dnsmasq doesn't support it yet for example and that's the forwarder I use at home.
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.
It seems like a cool idea, but I'm worried about the practical implementation, and that it is just another service to monitor (like Safe Browsing) where you could get blocked incorrectly.
is this hosted on Softlayer/Bluemix? if so hit me up if you need help getting more servers in different locations or have any network or load balancer performance related questions (I am a net. eng. for Bluemix infrastructure)
We dont run rpz on the resolver nodes, hopefully when we clear the backlog of things we want to fix/tweak/finish we can get around to dropping some docs on the cool stuff we built/did, and why. #todolist
"When a Quad9 user clicks on a website link or types an address into a web browser, Quad9 checks the site against IBM X-Force's threat intelligence database of more than 40 billion analysed web pages and images. The service also taps feeds from 18 further threat intelligence partners, including Abuse.ch, the Anti-Phishing Working Group, Bambenek Consulting, F-Secure, mnemonic, 360Netlab, Hybrid Analysis GmbH, Proofpoint, RiskIQ and ThreatSTOP."
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.
This just sounds like an advertisement for a partial virus checker software, most virus checkers now have browser plugins that do something like this. Why this gets 120 upvotes here is not obvious to me.
