Hi. I note that a blog posting just went up, disrecommending the use of Quad9 on the grounds that it’s commercial, which is not the case. It’s a not-for-profit public-benefit organization, supported entirely by donations. Also, you’ve got a list of recursive resolvers which similarly mischaracterizes Quad9, suggesting that it does not support DNSSEC (which is not the case, to the best of my knowledge, Quad9 was actually the first global-scale public recursive resolver to do universal DNSSEC validation, in 2016) or that it tampers with answers (there is an optional, user-selectable, malware blocking service).
If these are just mistakes or misimpressions, perhaps they can be corrected?
If there’s some underlying animosity, perhaps it could be discussed and resolved?
From My limited Understanding.
Quad 9 Filters your results.
There by breaking DNSSEC.
Per their own web site.
By breaking DNSSEC IPfire will not like it.
Until there is a way for DNSSEC to accept an Blocker/filtered response.
Quad 9 is breaking DNSSEC.
All trust to them Quad 9.
So I am sorry that is the case.
Yes, I’m chairman of Quad9’s board, and PCH, of which I’m the executive director, is one of the larger donors supporting Quad9. I can speak on Quad9’s behalf. Which is why I wanted to find out if there was a problem or misunderstanding that I could help resolve.
This debate has been had a couple of times in our community because people like using Quad9 and the other Quads. However, they are sometimes causing technical problems and they are not uncontroversial.
The technical problems simple are filtering some resource records which simply will break DNSSEC. You might argue that people should not land on those filtered websites anyways and this does the job. However, there is no reason that I can trust you doing “the right thing™”. A man in the middle could hijack your responses, too.
So for purists, Quad9 breaks DNSSEC.
Regarding the organisation that is running it: People have different beliefs. DNS traffic is very sensitive traffic. Quad9 in this instance will basically get a full browser history. That in the wrong hands can be dangerous or simply not wanted by some people. It simply is privacy.
So you will have people who will trust the organisation behind it and you will have people who don’t.
Being backed by various large corporations that do not have a good track record in dealing with people’s data properly.
The blog article states this:
For privacy reasons, it is best to stay away from big resolvers run by profit-oriented companies, such as Google, Cloudflare, Quad9 and others. They do not sell cookies, and they do not provide service for free.
I think that holds true. IBM is a large profit-oriented company and so is PCH. We all have to have our salary paid for. And the article then raises that those services are not being provided because people love to do so. I am sure it is okay to assume that there is some (monetary) benefit in there for them.
Quad9 optionally filters malware from results, at the user’s choice.
That does not break DNSSEC. In the event that there was DNSSEC-signed name, that was also phishing or participating in malware C&C, that was also requested by a user, who was also using the malware-blocking version of the service, then the user would receive EDIT: an NXDOMAIN response. This is different than the SERVFAIL that they would have received if the authoritative server for that domain were down, or if the DNSSEC signature had failed to validate. Until draft-ietf-dnsop-extended-error-16 becomes a standard, we don’t have a more finely-granular way to express those differences.
So there is no sense in which Quad9 is breaking DNSSEC. We have been leading proponents of DNSSEC for more than twenty years, at this point, and pretty much cram it down other people’s throats whenever the opportunity presents itself.
In the event that you encounter any actual problem with the service, I’d encourage you to report it to support@quad9.net. It’s a community project; it only gets better when we all work together to make it so.
If ietf.org was now on the “malware blacklist” this response would be filtered. I am not aware what you are sending. NXDOMAIN or SERVFAIL? Users have reported that they are seeing errors where the DNS resolver inside IPFire cannot validate some domains.
That is the reason why Quad9 is on the list of non-recommended DNS providers.
I am aware that there is 9.9.9.10 which actually has filtering features. That is a totally different story.
So just to help me understand, is there indeed no filtering enable for 9.9.9.9 whatsoever or are you filtering some “bad” domains? And if so, how do you filter them?
I would also like to point out that we are not trying to discredit any of your work. Quite the opposite. DNS needs some love and people who improve it.
Right, and that’s inarguably false. Quad9 is a not-for-profit, public-benefit organization. There is no sense in which it can be construed to be “profit-oriented.”
That’s true, and irrelevant, since you’re not discussing IBM.
And that’s inarguably false, as PCH is also a not-for-profit, public-benefit organization. But again, that’s irrelevant, since PCH is not what’s under discussion here.
Since that assumption is false, why would it be okay to assume it?
I read this as in “there are profit-oriented companies behind it”. At least IBM is in this case, although it is one step removed. That makes no difference to me and, I assume so, to Peter.
If there was no benefit for you in it, why did you launch it?
Sorry, you’re right, NXDOMAIN rather than SERVFAIL for a blocked response, I think, is what we’re doing. People have given us arguments in favor of each, and I haven’t had time to stay in the loop on that argument. I’ve edited the post to reflect that, and I’ll try to verify it as soon as I can. I’ve got a workshop to teach right now, but will try to get back to this thread and reply to the rest after that.
This NXDOMAIN is a problem! Because a NXDOMAIN answer has to be signed from the next higher domain. It will not accepted without this signature by unbound and it renders it unstable and trying again and make it slow and noisy in the logs because it logs every singature check fail.
9.9.9.9 is breaking the DNSSec by blocking domains with unsigned NXDOMAIN and
9.9.9.10 has no blacklist but not validate DNSSec (at the time of the tests.)
so the wiki is correct.
You’re moving the goalposts. You said “monetary benefit.” No, it’s at substantial monetary cost. But because it’s public-benefit, and I am a member of the public, I am also a beneficiary, as is everyone else who uses it, and everyone else who uses another recursive resolver that has now been forced to deploy DNSSEC and encryption, in order to cross the minimum-standard bar that we set.
Again, my apologies, I’m the infrastructure guy, not one of the DNS guys. Here’s an answer relayed from them:
We don’t answer the NXDOMAIN with the authority bit set. So we don’t claim it is a DNSSEC-signed answer. The correct response will be to eventually answer with either NXDOMAIN with extended error of “blocked by policy” OR SERVFAIL with the same extended error. The debate on which is more appropriate is still unclear.
But, again, the point is that there’s no 100% correct alternative to be implemented until draft-ietf-dnsop-extended-error becomes real. In the mean time, if you really can’t live with the current compromise, you can be a purist, live with malware, and use the non-blocking service rather than the blocking service.
Bill, of course they make a difference to me and I was telling you my interpretation of how I read Peter’s post.
You might disagree and you might think that I am wrong, but that does not mean that I am actually wrong. It still remains my interpretation. And I would be happy to be proven wrong, but you do not have anything else but a claim - and so does Peter.
I would like to thank you to help everyone to understand how you see things behind it. I am sure that there is enough information out there now that everyone can decide whether they want to use this service or not - for whatever reason.
Technically that is what I was outlining before. There is no better alternative to it. But still, the big problem that needs to be solved is how the client can trust that this response was not spoofed by an attacker. That won’t be possible without a signature.
And as Arne mentioned, we believe that unbound struggles with these responses, which might simply be a bug in unbound. Until that is resolved, Quad9 makes your DNS slow.
I’d like to thank Bill for reaching out and being able to not only participate in the forum, but also have a technical deep dive discussion here. Rare that we have someone that can do both of these things well. I’m also disappointed at the responses toward Quad9/Bill.
I’m not sure this is the case? I think Quad9 is slow with IPFire. I run pfSense, OPNsense, and IPFire. IPFire out of the box is the only distro that I have to aggressively tune to get decent DNS performance. I say this not out of animosity, but to try to suggest that you look in to the optimizations and defaults shipping with IPFire.
The blog post on DNS also has an interesting conundrum with DNSSEC. That is, if we are forwarding to a DNSSEC provider, including Quad9, having Unbound do additional DNSSEC validation is wasted and slows down the process. pfSense and OPNsense have the ability to disable DNSSEC, and this comes in handy when using Unbound in forwarding mode with a DNSSEC and DoT provider, such as Quad9. Something else to think about before making these blanket statements that Quad9 makes DNS slow. In my experience, Quad9 is quite fast…when used with a properly tuned unbound that isn’t rigidly forced to use presets that aren’t optimal. For reference, my post on some optimization I have to use with IPFire to get decent performance: Unbound - custom configuration - #13 by anon84413319
One more item I have noticed, and perhaps Bill can elaborate on this. Quad9 does seem more aggressive at closing DoT connections. For instance, when I run openssl s_client -connect '9.9.9.9:853' the connection will close after about 10 seconds. If I do the same thing with CloudFlare, it stays open for over a minute.
Finally, when I’ve installed IPFire fresh out of the box, it seems to run Unbound on a single thread vs spawning a thread for each processor core. I suspect that this single threaded nature and the aggressive connection closing may be at odds with each other. Perhaps something the IPFire devs can also validate more to see if this theory is correct?
The blog post on DNS also has an interesting conundrum with DNSSEC. That is, if we are forwarding to a DNSSEC provider, including Quad9, having Unbound do additional DNSSEC validation is wasted and slows down the process. pfSense and OPNsense have the ability to disable DNSSEC, and this comes in handy when using Unbound in forwarding mode with a DNSSEC and DoT provider, such as Quad9.
I absolutely disagree. Since you cannot rely on your DNS provider (let’s put it that way) for validating DNSSEC, turning the validation off renders the security you gain from DNSSEC void.
In my experience, Quad9 is quite fast…when used with a properly tuned unbound that isn’t rigidly forced to use presets that aren’t optimal. For reference, my post on some optimization I have to use with IPFire to get decent performance: Unbound - custom configuration
Could we please keep this split so we can talk about possible Unbound configuration optimisations there, while we focus on Quad9 here?
Finally, when I’ve installed IPFire fresh out of the box, it seems to run Unbound on a single thread vs spawning a thread for each processor core. I suspect that this single threaded nature and the aggressive connection closing may be at odds with each other. Perhaps something the IPFire devs can also validate more to see if this theory is correct?
first, thanks for reaching out and sorry for my late reply on this.
How is that not sophistry?
From my point of view, it is not. Given the sensitivity of DNS traffic, a construct of non-profit organisations ran by or linked to profit-oriented companies looks suspicious. As far as I understand, it is quite easy to become a non-profit organisation in the US (by self declaratory), where elsewhere in the world there are more hurdles to skip in order to become a non-profit.
As far as I am concerned, nobody in this world is doing things for free and altruistic purposes. Especially not if “doing a thing” involves lots of expenses (I assume running Quad9 is not inexpensive), people are not going to reward it and one happen to have access to pretty sensitive data. Sorry, but to me, that does not check out.
If truth and falsehood make no difference to you, why bother to say anything at all?
Of course they make a difference. There is no other way to answer this question (why bother asking it, anyway?). It’s just a thought-terminating cliché.
One more point regarding DNSSEC: Since Quad9 breaks it (for purists, if you like) on 9.9.9.9 et al., and you will have to scroll down a lot on the FAQ page to read about a non-filtering version at 9.9.9.10, I guess it is safe to say Quad9 is breaking DNSSEC.