Hacker News new | ask | show | jobs
by gmac 3138 days ago
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...

3 comments

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

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.

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.

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

google spamhaus ddos?

and dnssec is fundamentally flawed

> nobody can log and aggregate the queries you run

So who do you forward your queries to? :)

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

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