jeboehm
Deploy Unboud (recommended for Rspamd)
Is your feature request related to a problem? Please describe. It's recommended in Rspamd documenation to deploy Unbound: Therefore, it is strongly advised to employ your own recursive resolver when using Rspamd or any other email-related technology. Our recommended choice is to set up Unbound or, for more advanced setups, the Knot Resolver. You can find basic setup information for Unbound here.
Describe the solution you'd like Unbound
Additional context Confirmed in ISPmail guide.
Just to add one more thought to this topic: It could make sense to install and configure Unbound on host directly, and not in Docker container. This would follow the recommendation I read about fail2ban. After reading this it should be possible to deploy Unbound in Docker.
This feels like it might be better as a documentation change rather than another container. DNS is infrastructure stuff shared by many services, as such many sites are likely to have dns resolvers running already.
On my (small) server I have a resolver already running for hosting domains and resolving local queries. Running another dns server just because it's built in to docker-mailserver would be a waste of resources for sites like mine.
It would be much better (in my opinion, at least) to have an envar to point at a specific resolver if the site chooses to add a specific one for the mailserver, and have it fall back to the system-defined resolver by default. Documentation can include instructions on how to add unbound (say) to the docker compose if it's required.
Part of the power of docker-mailserver is that it provides fantastic integration between the components of a mailserver that are complicated to set up. The mailserver's needs for a resolver are not at all complicated, but many sites will have complicated requirements for their resolver(s), so it's a poor fit for the base mailserver deployment to try to provide it by default, imo.
I agree and disagree.
The requirement, if one would call it this, is not for the mail server, means sending and receiving mails, but for Rspamd. I stated this in the header of this issue already.
While agreeing with @agittins I was able to see the problem myself. It's about these messages in the log, right?
rspamd_monitored_dns_cb: DNS reply returned 'no error' for dbl.spamhaus.org while 'no records with this name' was expected when querying for 'jnVmfOz9d.dbl.spamhaus.org'(likely DNS spoofing or BL internal issues)
I don't want to add the unbound service to the project, because I think it's too complex, too.
But in the 'next' image versions, it's possible to specify the dns resolvers used by rspamd. You can use the environment variable DNS_RESOLVERS=xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy for that.
I had to use my provider's dns resolvers to make the log messages disappear.
Does this help you?
Actually I managed to deploy Unbound with Docker; it's configured as a recursive server.
Therefore I would prefer to set environment variable DNS_RESOLVERS=xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy optionally, means if this variable is unset any other DNS resolver is used.
That's great you've got your resolver set up.
What @jeboehm has said is that in the next release you will be able to specify as you mentioned.
@jeboehm does the new envar work if it's not specified? It looks like it gets defaulted to DE Vodafone's from the Dockerfile, am I reading that correctly? I might be getting confused with the template syntax also.
FWIW, as far as I know one can configure docker compose to assign any DNS server you choose, per service, in the config file with dns: xx.xx.xx.xx in the service's definition. https://docs.docker.com/compose/compose-file/05-services/#dns
Would this be a more "dockerish" way to handle it? (Unless of course one needs the fine-grained control of timeouts etc, but I'd expect rspamd's defaults should be good there, or the file could be overridden on an as-needed basis for sites with more particular requirements).
@agittins I think you're right with the more dockers way of configuring the dns servers at container level. But when I was testing this, I've still experienced errors with DNS BLs blacklisting public providers - and I still don't know why.
Because of that I've decided to provide the environment variable. It still can be set to 127.0.0.1 and any other dns configuration container level.