This was not clear in your previous post. And I would say that you cannot assume that. I do not have any usage figures, but I doubt very much that TLS traffic is the majority - if even anything significant at all.
And I would argue that it still matters to do local validation. You assume that Quad9 (as well as any other DNS provider) is trustworthy and cannot be tempered with. We have already covered what people might or might not find trustworthy, but there is always a chance of infiltration or simply software malfunction. You are creating a single point that needs to be taken over and then many users will have compromised DNS.
Doing validation locally is way more expensive to break for an attacker if they want to compromise many users. Therefore this is no reason for me to disable local validation.
To be clear, Quad9’s position is that everyone should ideally be doing their own DNSSEC validation, and that the current situation of people having to trust recursive resolvers is an unfortunate consequence of OS vendors failing to sufficiently support it in system resolvers.
That said, doing it twice is wasteful, and if it creates performance problems, that’s an excellent reason not to do it.
That suggests the potential for a need for a supported combination of features which includes blocking but does not include DNSSEC validation; a combination we haven’t had any real demand for before.
Yes, that’s correct. A reasonable security posture shouldn’t depend on external DNSSEC validation. In the real world, for most people, a reasonable security posture isn’t achievable because it’s undermined by compromises made by OS and browser vendors.
Quad9’s position has always been that, when it’s not unreasonably difficult to do so, we give people the tools and control that they want, so that they can put together the solutions that work for them. Thus our support for DNScrypt (which isn’t an Internet standard) and DoH (which is an abomination that exists solely to track users as they move between NATs) even though DoT exists and is better.
So, you’re having a performance problem when you force people to double DNSSEC validate on malware-blocked domains… the easy answer is to let people choose not to do that, if they don’t want to. In a perfect world, all DNSSEC validation would be done on the end-node (which isn’t their firewall, either); in the world we actually live in, though, different people want to make different choices when they’re forced to compromise.
Find me one example of a significant non-profit that refuses donations from for-profit companies. And if you can find such an example, tell me how replicating it would benefit anyone.
No that is true. But if someone is in your local network and can intercept your traffic losing DNSSEC is probably not your biggest problem. On the Internet side it is a lot easier to temper with things and therefore I think that our users are gaining a lot from doing it on the edge of their own network.
What we are doing here for example is to be not dependent on one donor, but multiple. So not single party is contributing that much money that they want to exercise (maybe even indirectly) control with it.
I tried to frame it as clearly as I could in the previous post.
When we’re using Unbound in forwarding mode, I think it’s a bit of a circular argument to try to discuss DNSSEC. If we choose to forward queries to a specific provider, whoever it may be, we’re assuming some level of trust in that provider already even before we take DNSSEC in to account. If we can securely forward queries to that provider using DoT, and we know that provider also performs DNSSEC on our forwarded queries as they resolve them at the provider, this is about as “safe” an assumption as we’re going to get. The DNSSEC argument seems to get misconstrued with the root resolver/recursor mode argument, which I 100% agree with and DNSSEC is definitely needed there. This is where having more flexibility within IPFire (without having to dig in to a custom .conf file) would be appreciated as we start to bridge the gap from plaintext DNS to encrypted DNS.
I do think its a mistake to classify Quad9 in the same rank as non-DNSSEC providers that also modify bad URLs to paid sites when a user accidentally types in a wrong address. Level3/4.2.2.1 is a good example of this negative behavior and they strip DNSSEC as well. It makes perfect sense to leave this provider on the “not recommended” list.
Quad9 is a non-profit and arguably, provides a huge value by not returning known malware infected domains. And yet the lack of nuance in this group means that we are classifying Quad9 in the same rank as a known bad actor DNS like 4.2.2.1. As a result, this is likely to push people towards Google and CloudFlare if they want to use DNSSEC and DoT. These two providers clearly don’t have a non-profit model and don’t hold themselves publicly accountable in any meaningful way regarding user privacy. I also doubt we’ll have any technical input from anyone working at Google or CloudFlare regarding their service.
In my opinion, this is not a benefit to IPFire users and this community as a whole. The stubborn adherence to the view that “Quad9 breaks DNSSEC” makes no sense. In reality there is no actual standard in place for the malware filtering service that Quad9 provides, and they are simply using the most elegant solution currently available. Ironically, by classifying Quad9 in “not recommended”, we are funneling users toward solutions that will be even less likely to serve in their best interest and this is a disservice, in my opinion.
I’d also like to reiterate that I have a huge appreciation for the folks posting here. I think it is great to see this level of involvement from developers and directors alike! Discussions like these will only help us get to a better solution so once again, thank you everyone for taking the time to post and lets keep this going!
DNSSEC is actually about that I do not need to trust my resolver. It does not stop any third party (like my ISP) from eavesdropping on my DNS requests, but I can be certain to never get a forge response from my resolver if I validate the response. TLS does not guarantee that and it does not protect me against any cache poisoning attacks or from untrustworthy resolvers. I can authenticate that I am using the one that I wanted to use, but I have to trust that the resolver will always response with the “correct” reply.
So TLS and DNSSEC compliment each other and I would not want to use only one.
I cannot cite any research on this, but from my experience DNSSEC creates on considerable overhead on the firewall or the client. So there is no benefit from disabling it. I only see downsides.
The IPFire developers have had this discussion many many times and we have talked about this for hours and hours and users have requested a button to disable DNSSEC many many times. Nobody has been able to make a point that convinced me. The arguments brought forward mainly were “it doesn’t work” which was often MTU-related or bad upstream resolvers. Those are network problems that will cause other issues further down the line and so I do not consider DNS to run fine on a broken network.
I do not think that the list should be understood as such. This is simply a good and “not good” list. It evaluates if a resolver works technically. The reason does not really matter and we didn’t add them to the list.
Again, this is not what this list is doing. We do not “recommend” any of the other resolvers here to be used without further consideration. On top of the page is a short note that makes that clear and links a lengthy blog post that makes clear what potential risks are.
Other people will come to a different conclusion and of course can use those if they like. That all depends on who you are, where you are and who you trust and don’t trust. That is impossible to put into a single list.
You might call that stubborn, but Bill has confirmed this. There is no RFC for this and therefore we are in unchartered territory here. There might be a small consensus on what to do to filter the “really bad guys”, but that isn’t understood by our or any other validating resolver.
Even less likely? So Quad9 is not serving everybody’s best interests? How so?
I only speculated that Google is using the collected data to create user profiles. I have no proof, and I made that very clear, but I would be surprised if they would not use the data. I put that warning out there that this is possible and why wouldn’t this be possible for others, too?
I understand that you guys (and I am right to count @firewell as being affiliated with Quad9?) are working hard for your cause and I am sure that you have many IPFire users happily using 9.9.9.9 - or even better 9.9.9.10 - but I personally am still not going to use your service.
That is totally independent from how you are running it and if you are RFC-conform or not. We made the technical side of this crystal clear and it is in the right section as the page is designed now (if anyone wants to change the list then that is another story).
If anyone uses Google or CloudFlare over Quad9, then they have not read my post (i.e. done their homework). It mentions that there is a risk using mono-cultures - and having only three big resolvers with an n.n.n.n IP address format is not enough diversity for my taste.
I am all for fighting this and diversifying our risk although the world is going the opposite way: We have very few cloud providers, the vast majority of SSL certificates is coming from Let’s Encrypt, we have about one and a half smartphone operating systems.
Too many projects are being hosted on GitHub and every time they go down many software developers drink coffee for the rest of the day. Don’t think about downtimes only now. I am aware how an any cast network works. Think outside of the box: Compromised, faulty, setting a bad example in terms of RFC-conformity.
Open standards are there for everyone to implement and use. Isn’t that a better world?
I agree with you. While I personally find it a bit semantics, ultimately DNSSEC is the only way to be sure. I’ll just say one more time though, when we are in Forwarding mode, DNSSEC or not, we are already placing more trust in the forwarded resolver than if we otherwise used DNSSEC with UDP/53 to the root servers. It’s a balance of security and privacy. I personally trust my ISP (Google) less than I trust a non-google forwarder, so in my case it’s DoT all day long to anyone but Google. If I can get additional malware filtering in there and send queries to a company with a stated goal of not profiting on my data, all the better.
Not affiliated, I just use their service. In the same way I am not affiliated with IPFire but, I do use it and enjoy learning. I was initially a heavy user of CloudFlare DoT when all of this was first made available around April 2018. You’ll also find me in the old forum threads, in fact we had some discussions about DoT a few years ago: IPFire Community
When I see something that looks like a good technical solution, I like to talk about it!
I think we should update the Wiki to include better language. There’s clearly a section at the bottom that says “not recommended”. This will imply to quite a few people that the rest of the providers at the top of the page are, in some way, more viable and/or “safer choices” when in reality, many of those providers are for profit and will not be forthcoming about how they use their DNS metadata.
The general assertion, and one that I agree with by the way, is that a large company offering a “free” service should always be looked at with suspicion. Nothing is truly free and their intentions cannot be fully known. The difference is that we have Google and CloudFlare not being fully open about where the data goes. We have Quad9 who is non-profit, states what data they use and why, and how they use it for malware prevention. To me these are not comparable because if I’m going to use a forwarder, I will choose the one that is likely to be the most reliable (scales well) and is going to be transparent about their logging practices.
I’ve tried using other small DoT services and frankly, it’s a mess. They don’t scale well, the services sporadically fail and reappear, when they work they are slow. The whole thing runs like a highschool science project. I prefer Quad9 because it’s one of the first DNSSEC/DoT providers that has enough scalability to be reliable. I’m here to learn and find the best solution in this evolving space. If you’re aware of an RFC-Compliant service (since that is what you prefer) that has a stable infrastructure, provides worldwide peering with DNSSEC/DoT, and has clearly defined privacy goals, I will jump onboard and use it.
This confuses me. You are advocating for DNSSEC as mandatory (which I can agree with!) however, the 9.9.9.10 service does not provide it? I’m not sure how you are thinking 9.9.9.10 would be better?
Screenshot from Quad9’s FAQ:
I Love this. Egos Aside.
bullets. I love bullets
1 Quad9 DNSSEC to it’s self not to me!?
2 Is DNSSEC to much to ask from Quad9?
3 Is there any elegant way to filter the results? and not cause Ipfire to lag/fault.
4 Is this a bug in Ipfire?
5 Quad9 can you give us a fully qualified DNSSEC response?
6 Quad9 are you legally bound not to?Lord Knows my ISP router blocks port 853.?
Quad9 your service sounds as trustworthy as any.
At our last tests 9.9.9.10 is also DNSSec validating now. So the faq seems incorrect.
Not if the client after the filter validates DNSSec because every answer, also NXDOMAIN has to be signed by the next higher level to make altering the messages detectable. It is the main goal of DNSSec to make the DNS not changeable on the way by a man in the middle.
I think if IPFire is going to maintain a list, it should have as much information as possible to help users decide. What if it was 3 tiers with listed features?
Tier 1: (DNSSEC, DNS over TLS capable, no content filtering)
Tier 2: (DNSSEC, DNS over TLS capable, content filtered)
Tier 3: (no DNSSEC or DoT features)
Obviously based on our prior conversations above, I presume you would also want to classify anything in Tier2 with extra verbiage to explain that the filtering is not standardized and therefore, will not strictly adhere to DNSSEC. I think this would be a lot more clear and also mean that if there is someone like me that is okay with some filtering from a service like Quad9, at least it isn’t just on a blanket “not recommended” list and we can make a better informed decision on if we want to use it.
Regarding 9.9.9.10, unless Quad9 updates their wiki or confirms its an error, I don’t think it should be listed as DNSSEC capable due to their official stance on it not offering DNSSEC. @bwoodcock could hopefully get this clarified for us.
This discussion has been had here (List of DNS Servers) and I think what you proposed was proposed there before (at least very closely).
In the end we decided to keep it simple. There is no need to collect DNS servers that are not suitable for use with IPFire. And I think it does not matter at all for what technical reason a service is unusable for our needs.
That’s how the DNSSEC architecture works. DNSSEC validation is fairly resource-intensive, and no additional value is created by doing the same work twice, so the architecture assumes that any particular answer will be validated once. If you’re capable of performing the DNSSEC validation yourself, you should definitely do so, but then you shouldn’t also ask Quad9 for a DNSSEC-validated answer, you should ask for an unvalidated answer. If you’re not able to do the DNSSEC validation yourself (for instance, because you’re a thermostat stuck on the wall, running some crap IoT operating system produced five years ago and never updated) then you definitely want someone else to do the validation for you. Which is why Quad9 provides that service as an option.
Nope. Which is why we were the first recursive resolver to provide it, nearly five years ago now, and we shamed the others until they offered it as well.
That’s really not an efficient path forward. You just need to decide where you want to do your DNSSEC validation, and do it in that one place, consistently. Ideally, on your own host. If that’s not possible, Quad9, and now some other recursive resolvers, can do it for you. But you don’t want to do both, or try to switch back and forth.
Not why I joined the conversation, but it looks that way to me.
Put it this way… No other firewall has this problem, and nobody else using Unbound has this problem. It’s still not 100% clear to me what the problem is, but it’s pretty clearly to do with re-validating already-validated responses, when the response has been blocked by policy. Under the draft IETF standard, that would be an Error 15 - blocked by security policy. But that’s a draft standard, so it may be counterproductive to decide to behave this way until the standard is finalized.
We give a full, normal, standard-compliant response, which works properly with any normal configuration of Unbound. “Fully qualified,” in the context of DNS, typically just means that a label terminates with a dot on the right… i.e. it includes all parent domains in the label, all the way up to the root. Any query put to Quad9 is assumed to be fully-qualified, since there’s no assumed parent domain. That’s more of an enterprise forwarding-resolver sort of thing, like you’d find in a Windows domain controller or something.
There are very few laws that can be construed to govern the technical operations of a public recursive resolver. No, there are no laws dictating that or how we perform DNSSEC validation. Our general policy is to provide everything that users want, that we have the resources to do. Thus we provide both DNSSEC validated, and non-DNSSEC validated, responses, so people can use whatever suits them. No law governs any of that.
We hope you don’t trust anyone in the role that we’re performing, but as long as someone has to perform it, there should be folks doing it in the public interest, so that anybody who doesn’t want their data monetized will at least have an alternative.
Nonetheless: Quad9 has thousands of donors, none of them large enough to influence what we do. We have a board of directors and we have a community of users, and collectively, that’s how we decide what we do.
So, again, are you really suggesting that we should try to be detectives, and figure out which donations are coming from for-profit organization, which from non-profits and individuals, and that unless we detect and refuse any donations coming from for-profits, we are “suspicious?” And, again, you claim to do this yourself, or know of an example of someone who does this? Or is the entire world, including yourself, “suspicious?”
They provide different security services. DNSSEC provides integrity. DoT provides confidentiality. DANE, when it’s fully supported, will provide authenticity, though authenticity only matters if you trust your correspondent. If you’re trusting your correspondent to perform DNSSEC validation, rather than performing it yourself, then ideally you’d be using both DoT and DANE with the validating resolver. Not really possible yet, though, unfortunately.
I think the fundamental problem is that the “not recommended” category conflates malware with DNSSEC, for no reason. A recursive resolver directing users to phishing sites does not seem to me like a good reason to recommend its use. Failure to support DNSSEC, however, would seem to be a good reason to disrecommend.
On your website, you have a very big logo of some “donors” then. Those must give more than the average one.
Oh no. Absolutely not. That is totally up to you to decide who you accept donations from.
I exclude certain organizations or people from making donations to our project. There might be various reasons for that, but we simply to do not agree with anything that people do to make money.
I guess I have said everything I wanted to say about this. You have your means to do things. I do not care what they are and I do not want to change them. You are reading things into people’s replies and you are using that to defend yourself. I find it rather sad that you cannot take this information and try to learn from it and make your project better.
I have the feeling that some share the concerns that were pointed out in this discussion and others in our community. You taking that and twisting it the way you need is confirming at least my concerns.
The discussion has moved on to the technical side and away from Quad9 as an organisation. I am only interested in that.
You said:
That response from your tech team states that you are doing something that is not RFC-compliant.
You withhold the correct response which is validatable and send a spoofed one. Therefore it breaks DNSSEC and neutrality.
With the same reasons ISPs want to “filter” the Internet and break net neutrality. I “recommend” service providers that do not do that. I guess that is fair to do.
Or being non-compliant with any other relevant RFC.
