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

16 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
  • voidzero
    • Edited

    The correct way, as some of you specified, is to run your own non-forwarding nameserver. It's safe to do so. Make it listen on 127.0.0.1 and ::1 on port 53 (and not on the wildcard address `*` / `0.0.0.0`) to prevent others from using you as an open resolver. If you are using powerdns as well to function as an authoritative nameserver, you might *not* want to let that listen on 127.0.0.1 and ::1 - let that listen only on your public IP(s).

     

    0
  • Kent Brockman

    voidzero so you recommend setting resolv.conf to use nameserver n.n.n.n where that is the public IP of the web server?

    cPRex what about cpanel-unbound and what is it for if we cannot use 127.0.0.1 within resolv.conf according to this? Then what exactly does the following?

    whmapi1 --output=jsonpretty \ set_up_dns_resolver_workarounds

    "This function creates an Unbound (libunbound) DNS resolver configuration."
    But I didn't notice any modification on resolv.conf nor even an unbound.conf file created. So what now?

    Then the best we could do is disable remote BL checking on SpamAssassing because they will block the request due to using open DNS resolvers?

    -1
  • cPRex Jurassic Moderator

    I wouldn't be using the public IP of the webserver here, as that isn't the intention of that file.

    cpanel-unbound is just a package that uses the Linux Unbound system.  It uses a series of touch files in /var/cpanel/dns_flags for servers with DNS configuration issues, but isn't something normal users should be running into.

    But yes, SpamAssassin and other tools will *always* have issues if you're using an open resolver, so it's best to use the ones provided by your host.

    1
  • voidzero

    @Kent no I do not recommend that, and I never said that either.

    1
  • Suhesh K S

    We’re encountering the same behavior on one of our customer servers using DC-provided resolvers.

    From our testing, direct dig queries against the DC resolver return valid responses from Spamhaus, URIBL, and DNSWL without any issues. However, during actual mail flow, SpamAssassin logs clearly show dns_block_rule hits, indicating that DNSBL queries are being rate-limited and temporarily blocked.

    This aligns with what @milo695 mentioned — since DC resolvers are shared across multiple tenants, the aggregated query volume likely exceeds the acceptable thresholds enforced by DNSBL providers.

    From our analysis, this does not appear to be a reachability issue but rather a query rate limiting scenario under load.

    Our proposed approach is to:

    • Deploy Unbound as a local recursive resolver on 127.0.0.1
    • Configure SpamAssassin only to use this local resolver for DNSBL lookups
    • Keep the system-wide DNS configuration unchanged (continuing with DC resolvers for other services)

    This should isolate DNSBL traffic, avoid shared resolver limits, and maintain stability for the rest of the system.

    @cPRex — could you confirm if this approach is aligned with best practices, or if you would recommend any additional tuning (e.g., cache parameters or selective rule adjustments) for high-volume environments?

     

    -1
  • voidzero
    • Edited

    Suhesh K S Oh great, we can communicate with AI here now. Please note that the answer was already posted. If you think you should use your local system only for DNSBL lookups and use the DC resolver for the rest of your system's DNS queries, well, you could just try that out and see what results you get. 

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post