CK’s Technology News

IBM’s Quad9 – A closer look

DNS together with FTP and some other protocols are the ones which I consider as dangerous, cause they were never be designed to secure anything especially not attacks against MITM or spoofing in general. IBM promise us with his new service and over 200 servers around the world to protect us against security threats – let’s take a closer look at it.

Quad9 Matrix
Quad9 Server Matrix – Picture Source: Quad9.net

The Quad9 DNS service, at 9.9.9.9, not only turns URIs into IP addresses, but also checks them against IBM X-Force’s threat intelligence database.

$ dig @9.9.9.9 google.com A

;; ANSWER SECTION:

google.com. 11 IN A 216.58.213.78

;; Query time: 6 msec

;; SERVER: 9.9.9.9#53(9.9.9.9)

6 milliseconds? Wow that’s very good (for me) because the traffic goes trough several switches, router and firewalls. This is almost as fast as Google’s 8.8.8.8 which is 2 ms faster in my region – it could be an alternative, right? Let’s do some more checks against the known ones aka Google & OpenDNS.

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

IBM seems not optimal in all areas but it’s something I could live with. According to the Internet Map IBM owns the 9.0.0.0/8 since 1988 and this could be a good sign because you never heard something bad about it, no leaks or something.

We checked the nerd stuff and now?

Well, besides from the speed there some things which are also quite important like how well is the protection/implementation and is there e.g. support for IPv6? Is there DNSSEC support? And how about EDNS? – The answers coming right now!

  • IPv6 is supported via 2620:fe::fe (or as alternative) 2620:fe::10.
  • What is the difference between server 1 (9.9.9.9) and server 2 (9.9.9.10)? – The first one does support features like DNSSEC, their blocklist and No EDNS Client-Subnet. The second server has no blocklist, no DNSSEC but EDNS.
  • In general you should use the first one because the mentioned security features, the second one is more in case you’re behind e.g. a corp. firewall.

What is wrong with Google’s and OpenDNS services?

  • Short answer? Nothing. It’s matter of trust that’s all.
  • Long answer: The big players might can monitor and control the entire internet by inspecting the traffic, which allows them to use it for marketing reasons or to sell such statistics to others.
  • However there also reasons against Google and it could be a bad idea when their servers aren’t close located to your own ISP and the last reason could be the speed, but it’s also depending on the server and your own location. OpenDNS only has servers in major cities. So if you live in Boston your using OpenDNS servers from NYC and all your Akamai downloads (slowly) from there.

What information does Google log when I use the Google Public DNS service?

  • Google Public DNS complies with Google’s main privacy policy, which you can view at our Privacy Center. With Google Public DNS, we collect IP address (only temporarily) and ISP and location information (in permanent logs) for the purpose of making our service faster, better and more secure – or in other words, the same thing every DNS does. Another downside or is a good thing? There could be no ads,  which sounds like a good thing right? Yes, as long you not on the other side which live from marketing and advertisements like almost every online shop on earth.

But what about NXDOMAINS hijacking?

  • There are fake news that the big players are manipulating/hijacking the NXDomains and sending wrong information back, this can be easily debunked. I’m not sure what their source was, but when you run a DNS benchmark yourself (as mentioned) on them the NXDOMAINS come back unhijacked.

Final words

  • Whenever you trust your own ISP, go with their own solution cause speed and trust are the both most important things.
  • If you have a major concern, run a benchmark (use the DNS Benchmark tool or via terminal) and look for yourself. The features which are offered by the provider is also one important factor but there also not failsafe, so don’t make it depending on that there is or isn’t DNSSEC. You can always try to contact them and ask to add support for it – it’s worth a try. Use the nearest server close to your own location.
  • If you router support it directly, change it on your router, so all connected devices getting the same DNS-Server.
  • The myth that Google or OpenDNS can’t be trusted is wrong, there is nothing wrong with them, as said it’s more about trust. technically there all on a high level. Quad9 simply offers some more gimmicks.
  • You might run into a risk that (because you changed your DNS-Server) get problems with some pages, this could due to their blocklist, in this case you need to contact them and ask to unblock it. This can happen because nothing is failsafe. Annoying but well, it can happen.
  • Alternatives could be DNSCrypt and DNS Privacy Project.

 

Source and Research

CHEF-KOCH

, ,