I understand this category is for discussions, not support requests, and not for app requests.
on
This form is written in English but feel free to write in French if you’re more comfortable!
on
Discuss
Hi there,
Following is more of a question for the Yunohost devs but I didn’t find a more suitable place to ask it. And maybe the community have the answer after all.
The VPS of a local association I work for/with is a Yunohost instance with email services set up but that we didn’t really use until recently. This email service is associated with our own domain attached to the Yunohost instance. A pretty classic set up I guess.
We were going to generalize the use of emails among our members when I discovered we were already hit with the SpamHaus “open resolver” issue that seems to plague some users here.
After some researches in the forum, I applied one of the proposed workaround that consists in commenting some IPv6 DNS servers owned by SpamHaus in a dnsmasq configuration subdir. It worked, the emails we receive were no more rejected…but it didn’t feel right. So I digged a bit more and discovered that the Yunohost instance ACTUALLY use open resolvers. Which are set up in the dnsmasq configuration. And I realized the SpamHaus IPs are set up like a hack to hide the fact that the Yunohost instance use open resolvers.
I’m aware that it is no news for the Yunohost devs but from my point of view it’s a quite odd DNS architecture. I’m quite new to the Yunohost environment and thus lacks any historical discussion about the how/why the DNS architecture is this way. So pardon my potentially naive question.
So here is my question : why use open resolvers at all ? I know dnsmasq cannot do recursive requests and requires at least one DNS forwarder IP, hence the use of open resolvers (I guess)…but why not setup by default a local recursive resolver (with Unbound or Bind), listening on an arbitrary port (like 127.0.0.1 udp/8053 for instance) and set it up as the sole DNS forwarder in dnsmasq configuration.
I could find a few posts/tutorials on the forum mentioning that but without any reply. So it seems like this solution was never really discussed/considered.
The advantages is that the Yunohost would not rely on any open resolver, hence solving the SpamHaus issue for good. I don’t see any drawbacks… unless there is a reason to use open resolvers that is different than just feeding dnsmasq with forwarders.
You should probably post the actual error message you got.
If your yunohost actually uses a shared open resolver for spamhouse that’s not what the configuration seems currently intending.
I think the /etc/dnsmasq.d/spamhaus configures the spamhouse’s own name servers directly.
It should contain the published ones, see: dig zen.spamhaus.org NS and resolve their IPs to compare.
The spamhaus trick in dnsmasq has been setup when the issues appears. It was a good quick workaround. (However, I am not aware for the ipv6 issue)
Having a local resolver could be a good idea for a lot of setup.
However, there aren’t only advantages if we think that in terms of privacy. Indeed, make some local resolution means the ynh instance requests directly the tld nameserver. So for example if you want to resolve arn-fai.net cause your received an email from it, the .net knows that your ip try to resolve arn-fai.net…
So, it’s possible some people prefers to trust some selected open resolvers than all tlds.
But, for others, it’s not a problem.
Note: this discussion is also related to the support of DoH or DoT open resolvers.
I think we miss a ticket on this topic, i didn’t found it in our issues tracker
I hope this answer was helpful. Please keep in mind that most of YunoHost’s development is done by volunteers, including this answer. Some of them earn less than the minimum wage in their country. If you can afford it, please consider donating to the 2026 fundraising campaign to help us keep this project going without putting anyone at risk.
All the IPv6 in my /etc/dnsmasq.d/spamhaus file are a subset of the answers of a dig AAAA against a/b/c/d/e SpamHaus servers. So this seems fine to me. The IPv6 address configured on our Yunohost instance is listed in a SpamHaus blacklist (well, the entire /64 actually, as per industry standard according to SpamHaus). I don’t know since when but it’s totally reasonable to believe it has been in this state since before the Yunohost devs pushed the workaround a year ago. So I’ve good hopes that delisting our /64 will fix our issue.
My message was more about suggesting an alternative to the current DNS architecture than looking for help to fix the issue (although if the issue surface again I may request such help !)
Well, I guess we could go a long way on the privacy advantages/drawbacks of these solutions (and some people at IETF have put a lot of effort at just doing this analysis) but from my opinion, as long as the DNS requests are not encrypted, there is no way to provide any kind of privacy (open resolver with plain DNS requests vs. local recursive DNS to the TLD with plain DNS requests). An entity having the resources to monitor the unencrypted DNS requests ON the most used TLD servers would have the resources to monitor these requests at a lot of other locations on the public network, like around open resolvers.
DoH or DoT would be a far better solution on the privacy stance (no way to monitor between the client and the remote resolver), but there would still be one issue remaining : how much trust would you allow to put in the open resolver not monitoring your requests ?
I’m not disputing the privacy angle though. From my understanding, privacy is one of the main reasons Yunohost exists and I entirely adhere to this principle. I have been in the group of those “who care” for a very long time I also understand that the dnsmasq configuration was felt like a good solution at the time the issues with SpamHaus were spreading. I also think that such change (moving from a selected list of open resolvers to a local recursive resolver) will break some setups heavily firewalled.
I can open such ticket in the Yunohost tracker if you want. Is it supposed to be done here ?
(although if the issue surface again I may request such help !)