Cloudron Forum

@nebulon , I'm quite confused as well - I realize it's a basic thing that, would it be broken, would affect everyone at all.

Default unbound works on 127.0.0.1 indeed and so far I ended up with point-finger with firewall - it seems UDP requires 53 port to be open on the inbound firewall rules to be working - something you have on your iptables rules as well.

For your reference - it's much easier to troubleshoot unbound with systemctl stop unbound && unbound -dd -vvvv as it start writing everything on the console, so we stop the guess work.
Other common troubleshooting steps are ss -tulnp | grep 53 to see if there is anyone listening.

@girish , thank you - for the time being I ended up disabling firewall completely to process with installation process.
I believe I unexpectedly advanced with unbound server for the last 24 hours and will be looking to reconfigure it once the setup is done.

It seems like unbound is only used for SpamHause and during setup. If the setup issue will resorted, only SpamHause issue will remain.

@jdaviescoates it is not cloud provider related.

To demonstrate that created an instance on Hetzner - installed unbound and nothing else - at all - and it doesn't work.

Screenshot from 2025-03-26 12-56-09.png

@Gengar I even tried with various Ubuntu versions: 22.04 & 24.04

@nebulon, the things is that it's your config... Like you've seen - I've made unbound working on vanilla Ubuntu. But the very same config fails on Ubuntu with Cloudron setup on it...

I can setup a dedicated server so that you can check it on your own - with or without just cloudron-setup, injecting your support ssh keys, if you keen to see on your own?

@joseph , nop - it doesn't... that's what I keep saying for a few hours now - vanilla cloudron & vanilla ubuntu - I didn't touch a thing - and yeah, that's a config I've seen, with the only exception that prefer-ip4 option is in separate file (for the reasons I didn't find a confirmation for).

I've tried to migrated working config from ubuntu machine without cloudron to the machine with cloudron and it fails

btw #2: here is the command to quickly verify unbound configuration unbound -d -vvvvv -c my.conf - as per unbound docs.

btw, I wonder why didn't you add qname-minimisation?

The following config file works on a fresh installed Ubuntu, but not on Cloudron:

server:
    # can be uncommented if you do not need user privilege protection
    # username: ""

    # can be uncommented if you do not need file access protection
    # chroot: ""

    # location of the trust anchor file that enables DNSSEC. note that
    # the location of this file can be elsewhere
    # auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
    # auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # send minimal amount of information to upstream servers to enhance privacy
    qname-minimisation: yes

    # specify the interface to answer queries from by ip-address.
    interface: 127.0.0.150
    # interface: ::0

    # addresses from the IP range that are allowed to connect to the resolver
    access-control: 0.0.0.0/0 allow
    # access-control: 2001:DB8/64 allow

@joseph , a very fresh machine with no firewall, whatsover fails the very same way; not sure what I can bring to the cloud provider, as 1.1.1.1 works and all of the other services I have there works just fine!

Another reason that it doesn't seem to be related to the cloud provider, is that with the config file you offered - I'm getting the very same error from unbound!

This particular issue is due to the system's configuration which prevents correct spam resolution. Might be the root cause is one, but we can't be sure on that.

Those are two different issues actually.

@joseph, as described in the issue earlier, referenced in my original thread earler, I'm installing latest cloudron instance (the one that is fetched with your original script from the site) and I'm receiving error 'queryNs ETIMEOUT mydomain.com'.

I'd like to reiterate that I've provided all of the information required at the thread earlier: https://forum.cloudron.io/topic/12145/setup-error-queryns-etimeout/20 - would you mind re-checking it please?

I've tried to ask for the support via e-mail, but have been asked to post the problem here for the sake of SEO friendliness.

Ok, so here is the problem: vanilla Ubuntu 24.04 or 22.04, can't install vanilla Cloudron, as unbound is failing to resolve any domains at all (and it's only needed to do SpamHause like checks, but that also can't be resolved for quite some time now)

I've provided all of the information at the forum thread: https://forum.cloudron.io/topic/12145/setup-error-queryns-etimeout/20

I would appreciate any technical assistance from Cloudron team, as I'm trying to work-around DNS issues for a few weeks now and now I'm completely stale, as I can't even install new instance.

Shall anyone - from e-mail support or here or via pager help me - that would be fantastic.
And I'm on a Pro plan.

That is quite embarrassing... I am blocked at the setup process of fresh cloudron on a fresh ubuntu for a few hours...

And that is all due to # Unbound is used primarily for RBL queries (host 2.0.0.127.zen.spamhaus.org) - which is not quite true / right anymore as well?

[4776:0] error: udp connect failed: Network is unreachable for 2001:500:2::c port 53 (len 28)
guess that's a reasonable error for the case when IPv6 is disabled?

do-ip6: no in config doesn't help thought...

@joseph I can't uninstall cloudron, but plain host apple.com works perfectly fine!

Got the same problem on vanilla Ubuntu 24.04, reinstall didn't help.
status give all green, host command fails though:

# host -t NS apple.com 127.0.0.150
;; communications error to 127.0.0.150#53: timed out
Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases:

Host apple.com not found: 2(SERVFAIL)

@jdaviescoates thank you! I will keep that as a final resort!

@girish , I would much appreciate any additional information to work-out those false positive alerts as they shall be handled - as I highlighted earlier, Ubuntu update doesn't seem to be relevant...

@msbt got you, thanks!
I don't believe Cloudron's auth is easily replaceable for the build-in apps and it's unlikely that it will be replaced one day - that means a lot of testing on top of the existing infrastructure.

@nebulon Ok, what is required to make sure you accept it?
Would not like to have that as a fork.