Skip to main content

Unbound on a production WHM/cPanel server

milo695

Hi guys, is it safe to install Unbound as a local recursive caching resolver on a production WHM/cPanel server (AlmaLinux 9.5, port 53 open)?

What I have is:

  • AlmaLinux 9.5.0

  • WHM/cPanel (latest version)

  • DNS role: authoritative for user domains (using PowerDNS)

  • Port 53: open on all IPs (via Hetzner's hardware firewall)

  • Email: outbound handled via SMTP2GO (no local DNS lookups needed for mail)

  • /etc/resolv.conf: uses external resolvers only (no localhost yet)

  • Using Hetzner's resolver in WHM (IPv4 and IPv6)

So, the questions are:

  • Is it safe to install Unbound for local caching, as long as it’s bound only to 127.0.0.1 and ::1?

  • Will WHM/cPanel or PowerDNS conflict with it?

  • Any caveats when enabling Unbound on a system using PowerDNS for zone transfers?

Thanks

Comments

10 comments

Date Votes
  • cPRex Jurassic Moderator

    Hey hey!  I don't have any official comments one way or another as this isn't something we test.  I'd recommend performing that work on a test machine so you can see if there are any negative interactions with the server before deploying this to production.

    0
  • milo695

    Roger that Rex,
    But then how do others solve this?

    If Unbound isn't officially supported/tested, how do most WHM/cPanel admins handle DNSBLs blocking SpamAssassin due to resolver limits?

    Any recommended or common method you’ve seen in production? I really have to solve this somehow...

    0
  • cPRex Jurassic Moderator

    Can you let me know what specific block or problem you're running into?

    0
  • milo695

    Sure, the issue is that SpamAssassin is getting blocked by DNSBLs like Spamhaus and URIBL (e.g., RCVD_IN_ZEN_BLOCKED_OPENDNS, URIBL_BLOCKED) because my server uses shared/public resolvers.

    Here:

    Apr 24 11:39:58 myhostname.com spamd[919826]: check: dns_block_rule RCVD_IN_ZEN_BLOCKED_OPENDNS hit, creating /root/.spamassassin/dnsblock_zen.spamhaus.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dn>
    Apr 24 11:39:58 myhostname.com spamd[919826]: check: dns_block_rule URIBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_multi.uribl.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restric>
    0
  • cPRex Jurassic Moderator

    Thanks for the clarification there.  You mentioned earlier that you're using Hetzner's resolvers which wouldn't be public, and our recommendation is to avoid public/shared resolvers whenever possible.

    Are the Hetzner resolvers causing you an issue in some way, or you just want to get off of those?

    0
  • milo695

    Welcome.

    Right, but that’s the contradiction as Hetzner’s resolvers are shared, and that’s exactly why I’m hitting DNSBL blocks in SpamAssassin.

    You recommend avoiding shared/public resolvers, but there’s no officially supported private/local alternative like Unbound or I'm missing somethin?

    So what's the actual supported way to avoid these DNSBL blocks if shared resolvers are off the table and Unbound isn't tested?

    0
  • cPRex Jurassic Moderator

    I'm not aware of a supported way to workaround that, as that wouldn't be an issue that is specific to cPanel - any host using SpamAssassin with or without cPanel software would run into this problem.

    Are you using something other than the following IP addresses for your Hetzner resolvers?

    185.12.64.1
185.12.64.2
    0
  • milo695

    Indeed, I'm aware that any host would have the same issue.

    I'm using 185.12.64.2, 2a01:4ff:ff00::add:1, and 185.12.64.1 as a tertiary resolver.

    0
  • cPRex Jurassic Moderator

    Unfortunately I don't have any other recommendations from my end about this.  However, I also don't see those IP addresses as a public nameserver as I can't run "dig google.com @185.12.64.2" from my local workstation or server, so it seems those are not totally public.

    A public resolver is one that would respond to all requests, such as the Google resolvers of 8.8.8.8 and 8.8.4.4, which work well with that test:

    [root@host ~]# dig +short cpanel.net @185.12.64.2
    ;; connection timed out; no servers could be reached

    [root@host ~]# dig +short cpanel.net @8.8.8.8
    208.74.121.151
    208.74.123.84

    The ultimate answer for this situation if you're running into issues will be contact Hetzner to see what they say about those resolvers.

    0
  • Peter Needham

    So I have run into exactly the same dead Resolver h3ll end.

    Resolver's end up using a public resolver that get booted by spamhaus and most RBL's

    It looks like using unbound is the only way to resolve this OR register and use spamhaus own resolver servers (after registration).

    I am leery at installing unbound no my new server but I do want to use RBL's to help my customers get less spam.

    cPanel installed unbound for the local services but it doesnt support  DNS/RBL etc

    This is the plan if I decide to be bold.

    • Install system-wide Unbound for Exim, CSF, SpamAssassin, dig, etc.

    • Configure it to listen on 127.0.0.1:53

    • Make your whole system (not just cPanel) use it

    • Leaves cPanel’s internal Unbound untouched at /usr/local/cpanel/...

      Did you get yours going this or some other way MILO ?

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post