IBM Quad9 – A free security solution using DNS to protect against cyber threats | Hacker News Reader

IBM Quad9 – A free security solution using DNS to protect against cyber threats

quad9.net

141 pointsbignet123 comments

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.

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.

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. :(

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).

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.

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.

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

https://goo.gl/c9xBT6

https://goo.gl/cUZMDE

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.

What does PCH mean?

Packet Clearing House, partner with IBM for said service.

https://www.pch.net/

Thanks!

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)

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.

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.

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

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.)

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

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

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.

> give it some time

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

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].

[1] https://developers.google.com/speed/public-dns/privacy

[2] https://www.quad9.net/#/faq#does-quad9-collect-and-store-per...

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 :)

It is surprisingly easy to set up a recursive resolver for oneself.

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.

> nobody can log and aggregate the queries you run

So who do you forward your queries to? :)

The root servers.

http://www.inetdaemon.com/img/dns-hierarchy.gif

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.

True, seems I read over the recursive part. In which case it is definitely not easy to set up.

But even for a recursive DNS server that is only used by a single client aggregation for popular dains is not impossible.

There are better and definitely easier ways to have anonymous DNS lookups

Caution: open recursive resolvers need protection from being used for DNS amplification attacks.

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.

google spamhaus ddos?

and dnssec is fundamentally flawed

> 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.

[1] https://blog.thousandeyes.com/ddos-attack-varying-impacts-dn...

Probably they still keep logs (maybe anonymized, but who really knows).

If you want a more private DNS look at OpenNIC [0].

[0] - https://www.opennic.org/

Your closest servers:
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...

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.

Isn't that SFO IP anycast?

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

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.

Maybe, maybe not.

    » dig google.pl @9.9.9.9 +short
    172.217.6.67

    --- 172.217.6.67 ping statistics ---
    246 packets transmitted, 234 received, 4% packet loss, time 3844ms
    rtt min/avg/max/mdev = 182.446/185.902/195.987/2.274 ms, pipe 13, ipg/ewma 15.689/185.811 ms

    » dig google.pl @8.8.8.8 +short
    172.217.22.67

    --- 172.217.22.67 ping statistics ---
    225 packets transmitted, 223 received, 0% packet loss, time 3676ms
    rtt min/avg/max/mdev = 21.581/25.026/33.694/2.158 ms, pipe 3, ipg/ewma 16.413/24.972 ms

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.

There is something very funny about that service being immediately unavailable right after launch.

I think I'll pass for now.

Someone at IBM still believes that no one gets fired from buying from IBM.

The DNS server works though. Only the website appears to be unavailable. EDIT: Even the website loaded eventually.

    » dig @9.9.9.9 news.ycombinator.com +short
    news.ycombinator.com.cdn.cloudflare.net.
    104.20.44.44
    104.20.43.44

Not great but not a complete failure either.

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.

[0]https://screenshots.firefox.com/LiNdj97Ck3qaLXze/www.quad9.n... [1]https://screenshots.firefox.com/YEsWa5TwhGYQDZFZ/www.quad9.n...

Why would you use Google/OpenDNS/whatever when you can use dnscrypt [1]?

[1] https://dnscrypt.org/

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)

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

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.

Here's the Turris documentation on how it handles DNS: https://www.turris.cz/doc/en/howto/dns

Yup the team is working on this, sorry about the hiccups. :(

That's funny the quad9.net website it down at the moment, I guess that answers if their DNS will be reliable.

The site is down, but the DNS server seems to be fine.

The DNS server is also super slow.

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!

Quad9 DNS is 10x (or worse!) slower then Google's for me (I'm in São Paulo, Brazil). Will this output help you troubleshoot DNS performance?

  $ dig +short @9.9.9.9 id.server TXT chaos
  res300.ams.rrdns.pch.net

Thanks for this, we will see what we can do to run this down.

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.

35ms for Google vs 230ms for Quad9 via LTE in Canberra, Australia. You really need an Australian PoP - I'd like to use the service!

"res300.ams.rrdns.pch.net"

res200.qpg.rrdns.pch.net

It's designed quite badly to be honest.

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.

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.

Video is not documentation.

Product presentations aren't even the worst offenders. The absolute worst are providers doing "webcasts" in lieu of writing actual user documentation.

Quick performance test comparing these 4 players:

* 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

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]

[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.

https://dnscrypt.pl/2017/04/02/finacials-in-q1-2017/

The website seems to be down for me.

Doesn't DDoS defense fall in the "internet threat protection" bucket? :p

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."

Different has an extraneous trailing "e".

Maybe the author's mother tongue is Portuguese (we spell "diferente"). This typo is probably the one I commit the most :)

I totally just got the name, Quad9 == 9.9.9.9, duh

Ugh... same here.

The response time depends on network peering from their anycast locations. I am seeing different response times based on test locations.

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 -- --

From Iran:

  # ./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 -- --

Tests are performed using dnsdiag tools: https://github.com/farrokhi/dnsdiag

        $ 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

It's also interesting that they have a public "insecure" DNS server on 9.9.9.10 with none of the additional threat protections - https://www.quad9.net/#/faq#is-there-a-service-that-quad9-of...

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.

The problem is all the hugs of death. :(

Website is being worked, dns infrastructure is solid and working well. Sorry for brief response, a bit busy ;)

I see. ;-)

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.

[0]: https://en.wikipedia.org/wiki/DNSBL

That's quite a vanity IP. Wonder if they already had it or bought the address block from someone.

IBM owns 9.0.0.0/8

Baller.

According to https://xkcd.com/195/ it is their address block.

IBM have 16.7M public IPs - the 9.0.0.0/8 block since 1988....

Does anyone have an example query that would be blocked? Trying to see what the reply looks like.

dieutribenhkhop.com (which resolves to 127.0.0.1) works on 8.8.8.8 but not 9.9.9.9, and quad9.net reports it as "blocked"

presumably 1) public domains resolving local is a threat, 2) that domain has bad reputation and previously hosted nasties

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.

It's like Herman Cain's tax plan, but one 9 better.

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?

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.

Following Google's pattern, the secondary server should be 9.9.(4.5).(4.5)

We do have another IP tied to the anycast cloud on a different /8.

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!)

Wow, 30k blocks per day? That's 0.25% of the entire address space every year. In 400 years they'll have blocked every IPv4 address!

Here's to another 400 years of stagnant IPv6 adoption!

Is there IPv6 support for Quad9?

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

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.)

(Example zone: ed25519.nl.)

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).

+1 for dnscrypt support

+1 for dnscrypt interface

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.

Edit: Unbound does this.

DNS-over-TLS with Quad9 how-to: https://medium.com/@alexander_band/privacy-using-dns-over-tl...

Their attention to detail inspires confidence: "It's like and immunization for your computer"

Also: "setup", used all over the front page, is not a verb, yet is used as one.

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.

Looks like a competitor to Comodo's free Secure DNS service.

https://www.comodo.com/secure-dns/

8.26.56.26

8.20.247.20

Interestingly, your link didn't work for me because comodo.com was blocked by Quad9 :)

Wut?

Sounds like a pretty good reason not to use Quad9 then.

Fm Malaysia, quad and google performed almost identical over last two days

pi-hole was also the first thing that came to my mind. They should setup a feature version on 9.9.9.13 with the same blacklists as a pi-hole :)

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)

Sooo they are running RPZ and calling it a product....?

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

I look forward to reading that as a fellow DNS Engineer that works at large scale and has a passion for security.

Fitting that the site looks like it's down.

"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.

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?

The lady from that video presentation sounds like she's using a fake British accent.

Doesn't work

I am assuming you are talking about the website?

We should be working on that front right now.

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.

Reply on news.ycombinator.com