Ridiculous amount of DNS queries towards www.invaluement.com

[immanuelfodor]

Prior to placing the issue, please check following: (fill out each checkbox with an X once done)

• I understand that not following or deleting the below instructions will result in immediate closure and/or deletion of my issue.
• I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
• I have understood that answers are voluntary and community-driven, and not commercial support.
• I have verified that my issue has not been already answered in the past. I also checked previous issues.

Summary

According to DNS logs, www.invaluement.com is queried by Mailcow in every 5-7 seconds. This is something new, it must have appeared in the previous few weeks, I can't remember it being there before. Tried to update to the latest git commit, but it doesn't solve the issue, Mailcow is still going berserk. This is also suspicious a bit, what is Mailcow doing at this domain so much?

This makes it the top 1 queried domain for the last 24h hours, more than all other DNS activity in my network by multiple factors.

Logs

No error log within Mailcow.

Reproduction

Updated to the latest Mailcow as of now, it's querying the domain like crazy. I don't want the DNS to be cached, the cause of querying so much should be eliminated. 5-7s connection to an external domain is wrong on multiple levels.

System information

Question	Answer
OS	Ubuntu 18.04 LTS
Is Apparmor, SELinux or similar active?	No
Virtualization technlogy (KVM, VMware, Xen, etc - LXC and OpenVZ are not supported	KVM
Server/VM specifications (Memory, CPU Cores)	6G, 2 cores
Docker Version (docker version)	19.03.13
Docker-Compose Version (docker-compose version)	1.27.4
Reverse proxy (custom solution)	Nginx

• Output of git diff origin/master, any other changes to the code? If so, please post them. - IPv6 disabled, custom SOGo theme, PiHole IP as DNS instead of the internal Unbound in the compose file
• All third-party firewalls and custom iptables rules are unsupported. Please check the Docker docs about how to use Docker with your own ruleset. Nevertheless, iptabels output can help us to help you: iptables -L -vn, ip6tables -L -vn, iptables -L -vn -t nat and ip6tables -L -vn -t nat. - Not related
• DNS problems? Please run docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254 (set the IP accordingly, if you changed the internal mailcow network) and post the output. - Not related

[andryyy]

You should check your Postfix logs for something hammering your server. Enable Rspamd debug_modules for rbl perhaps, too.

Suspicious? Please explain.

[immanuelfodor]

Everything seems normal in Postfix, and added debug logging to Rspamd as follows:

$ cat ~/mailcow/data/conf/rspamd/override.d/logging.custom.inc

# @see: https://rspamd.com/doc/configuration/logging.html
# @see: https://forums.zimbra.org/viewtopic.php?t=62443
# @see: https://github.com/mailcow/mailcow-dockerized/issues/3877
debug_modules = ["dns", "rbl"]

$ docker-compose restart rspamd-mailcow
$ docker-compose logs -f rspamd-mailcow

Still, nothing is on the output after the normal restart logs but the DNS is queried as before. Should I look somewhere else for the relevant logs?

Suspicious: like many software "phones back home", I try to avoid this behavior as much as possible.

[andryyy]

It is data/conf/rspamd/local.d/multimap.conf and the sendgrid anti-spam map. It checks if the map is alive. If you don't use a cache (TTLs exist for a reason), you will notice a useless hammering on DNS. I don't see a reason to support this. mailcow comes with a caching recursor that sticks to the domains TTL.

I don't care about your data at all (edit: this sounds wrong... I care about the safety, but I don't care about making money from it :-)). Every single component is open source, please check the code before making assumptions.

Please also consider a donation to https://www.invaluement.com/donation for using their map. If you don't linke it, remove it from the multimap.

[immanuelfodor]

Okay, thanks, I understand it's not a data syphon 😃

What would I lose if I comment these lines out? For example, would I get more spam from Sendgrid, or something like that? 5a627dc

And if I'd use Mailcow's Unbound which would cache the DNS better, would Mailcow still try to download the map in every 5-7s? Why does it need it so frequently? It must be querying the DNS as it wants to grab the file, right?

[Adorfer]

Note: This is a bug tracker, not the support forum. (e.g. discussion about different antispam techniques is out of scope here. Especially since it has not connection to this issue here which i understand as "if you disable/not use the mailcow DNS-recursor, then mailcow does not use the mailcow dns recursor")

[immanuelfodor]

Rspamd accessing an external Internet resource in every 5-7s seems fairly bogus to me, not to mention the possible load on the destination site originating from all other Mailcow instances if it's not only mine (DoS).

Maybe nobody has observed this behavior before because all the DNS queries are hidden in Mailcow's Unbound cache. And it is definitely not just DNS but there are packets flowing to their IP, so the file is definitely accessed in every 5-7 seconds.

This is not a support question, this seems to be an issue with Mailcow (Rspamd). Please give a clear explanation why this is not a bug, why this file needs to be grabbed 15.000+ times a day.

$ dig www.invaluement.com

; <<>> DiG 9.16.8 <<>> www.invaluement.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62192
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.invaluement.com.           IN      A

;; ANSWER SECTION:
www.invaluement.com.    837     IN      A       104.22.14.144
www.invaluement.com.    837     IN      A       104.22.15.144
www.invaluement.com.    837     IN      A       172.67.14.207

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: v nov 29 12:37:52 CET 2020
;; MSG SIZE  rcvd: 96


$ dig www.invaluement.com NS

; <<>> DiG 9.16.8 <<>> www.invaluement.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10426
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;www.invaluement.com.           IN      NS

;; AUTHORITY SECTION:
invaluement.com.        3599    IN      SOA     gabe.ns.cloudflare.com. dns.cloudflare.com. 2035720829 10000 2400 604800 3600

;; Query time: 53 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: v nov 29 12:41:13 CET 2020
;; MSG SIZE  rcvd: 107

[andryyy]

Disable all anti spam resources, if you chose not to trust them. :)
Or increase the interval for map health checks. Use a DNS cache, that's what it was made for! :)

If you need assistance check the community or open a ticket with us.

[andryyy]

To add to it: it is "ridiculous" to complain about a spam filter accessing foreign IPs. For obvious reasons. :)

Furthermore the domain owners ASK you to cache to not hammer their name servers. Keep that in mind, please.

Please be friendly, not toxic. We don't need this here. Moo.