DNS lookups for spam blockers going to wrong DNS server.

[Mastadamus]

Can anyone tell me why all these DNS requests to these DNS servers are getting sent from my Cloudron server? Its not sending them to my DNS server but attempting to send them outside the network on port 53 to IP's presumably associated with the spam blocker list orgs? Why isn't it sending the DNS requests to my DNS server and instead sending them outside my network? They are getting blocked by my router but wouldn't be if they were getting sent to my DNS server I believe.

[Mastadamus]

I'm guessing I need to add my Adguard DNS server as a "internal dns server" thats a forwarder since that's the primary DNS my router passes out via dhcp?

[girish]

@mastadamus I don't quite understand the problem (I also don't know what this screenshot is of and how Adguard DNS is tied into all this). Is it that you are using the Adguard DNS (the SaaService) and are wondering how to make Cloudron use it?

[Mastadamus]

@girish

This is a screenshot of blocked dns requests by my router.

I use adguard dns that is installed on a separate device as my main dns server for lan. It's ip address is handed out via dhcp to all my devices.

For some reason, cloudron is attempting to sending dns traffic out my gateway to other upstream dns servers instead of sending it to my adguard dns server.
It's getting blocked by my firewall because of dns filtering policy. It looks like most of the dns lookup are in relation to email block lists.
I read that unbound is dns for cloudron app so don't I just need to tell unbound to forward requests to my actual lan dns server?

[A Former User]

@mastadamus Odd... So on your devices you can confirm when you switch from DHCP to manual it has your Adguard IP for the primary DNS server?

[Mastadamus]

@atrilahiji yes and every other DNS lookup from the cloudron server gets sent to the right place these are the only ones that don't. They attempt to go right out the gateway via port 53 to some other dns server.

[girish]

@mastadamus Right, so Cloudron has it's own recursive resolver called unbound and all the DNS requests from the apps go through unbound. The main reason for this is that email servers require to do what is called DNSBL lookups (the zen.spamhaus.org requests that you see) and these lookups will not work if the request comes from Google DNS and other DNS servers. They only work if it comes from your own DNS server. This is because they just blacklisted all the popular DNS servers whole sale, I guess due to spam/load.

unbound can be configured to forward all requests to another internal DNS server - https://docs.cloudron.io/networking/#internal-dns-server . This is quite technical, so if it doesn't really matter, I would leave things as-is but hopefully this explains why DNS requests from Cloudron do not go via your router's DNS or your internal DNS server.

[Mastadamus]

@girish I'm not sure if it matters or not tbh. Will the spamlists work if these lookups get blocked? because to the best of my ability to tell, all these spam list related lookups are being blocked by my firewall. Im not getting any spam in my inbox though so im happy on the no spam front.

[girish]

@mastadamus right, the spamlists won't work if those lookups get blocked. Currently, if the lookups fail, the mail server will simply go ahead and try to detect spam via spamassassin. It's just one of the metrics for spam detection. I guess it's fine if it's working OK for you without it .