Can't get Cloudflare to work

[d1rk]

Same here. I tried all steps from troubleshooting unbound (as described here: https://docs.cloudron.io/troubleshooting/#unbound).

I found the following line in the box.log:

box:services statusUnbound: unbound is up, but failed to resolve ipv4.api.cloudron.io . Error: queryA ETIMEOUT ipv4.api.cloudron.io at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/promises:294:17) { errno: undefined, code: 'ETIMEOUT', syscall: 'queryA', hostname: 'ipv4.api.cloudron.io' } undefined

Ping works, although:

$ ping ipv4.api.cloudron.io
PING ipv4.api.cloudron.io (165.227.67.76) 56(84) bytes of data.
64 bytes from prod.cloudron.io (165.227.67.76): icmp_seq=1 ttl=49 time=87.0 ms
64 bytes from prod.cloudron.io (165.227.67.76): icmp_seq=2 ttl=49 time=85.5 ms

[james]

Hello @d1rk
Can you please try to restart the unbound service and try again?
For this you can go into your Cloudron Dashboard under services and restart the unbound service.

[d1rk]

Hi @James - Thanks for your reply. Greatly appreciated.

I already did, as well as restarting the server. Both did not help, unfortunately.

[james]

Hello @d1rk
Can you please ssh into your Cloudron server and try the following command:

dig ipv4.api.cloudron.io @127.0.0.150

[joseph]

If it matters (for the outbound firewall configuration) : ping is ICMP traffic , DNS is UDP port 53 .

[d1rk]

Thanks for the two of you @James @Joseph to help me with that.

$ dig ipv4.api.cloudron.io @127.0.0.150
;; communications error to 127.0.0.150#53: timed out
;; communications error to 127.0.0.150#53: timed out
;; communications error to 127.0.0.150#53: timed out

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> ipv4.api.cloudron.io @127.0.0.150
;; global options: +cmd
;; no servers could be reached

For the record: my firewall is outbound open:

[james]

Hello @d1rk
Thanks.
Could you please now run the following command and share the output?

lsof -i :53

[d1rk]

@James Now I could do it. The result is this:

COMMAND      PID            USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd-r    669 systemd-resolve   13u  IPv4   17046      0t0  UDP localhost:domain
systemd-r    669 systemd-resolve   14u  IPv4   17047      0t0  TCP localhost:domain (LISTEN)
unbound    20480         unbound    3u  IPv4  164940      0t0  UDP localhost:domain
unbound    20480         unbound    4u  IPv4  164941      0t0  TCP localhost:domain (LISTEN)
unbound    20480         unbound    5u  IPv4  164942      0t0  UDP xum:domain
unbound    20480         unbound    6u  IPv4  164943      0t0  TCP xum:domain (LISTEN)
unbound    20480         unbound   13u  IPv4 8207316      0t0  UDP Ubuntu-2204-jammy-amd64-base:64328->j.root-servers.net:domain
node      632203      yellowtent   24u  IPv4 8210389      0t0  UDP localhost.localdomain:57067->localhost:domain

Not sure, how to read that, tbh. Does that help?

[james]

Hello @d1rk
Yes this helps me to narrow it down.
If the command dig ipv4.api.cloudron.io @127.0.0.150 still returns the same output as before please post the output of the following commands:

dig +trace +nodnssec ipv4.api.cloudron.io @127.0.0.150

systemctl status unbound.service

cat /etc/unbound/unbound.conf

cat /etc/unbound/unbound.conf.d/cloudron-network.conf

[d1rk]

It does still return a timeout. So here are the outputs of said commands (and one more):

$ dig +trace +nodnssec ipv4.api.cloudron.io @127.0.0.150
;; communications error to 127.0.0.150#53: timed out

$ systemctl status unbound.service
● unbound.service - Unbound DNS Resolver
     Loaded: loaded (/etc/systemd/system/unbound.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-11-25 09:32:52 UTC; 2 days ago
    Process: 20475 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key (code=exited, status=0/SUCCESS)
   Main PID: 20480 (unbound)
      Tasks: 1 (limit: 76755)
     Memory: 7.2M
        CPU: 5.503s
     CGroup: /system.slice/unbound.service
             └─20480 /usr/sbin/unbound -d

Nov 25 09:32:50 xum systemd[1]: Starting Unbound DNS Resolver...
Nov 25 09:32:52 xum unbound[20480]: [20480:0] notice: init module 0: subnet
Nov 25 09:32:52 xum unbound[20480]: [20480:0] notice: init module 1: validator
Nov 25 09:32:52 xum unbound[20480]: [20480:0] notice: init module 2: iterator
Nov 25 09:32:52 xum unbound[20480]: [20480:0] info: start of service (unbound 1.13.1).
Nov 25 09:32:52 xum systemd[1]: Started Unbound DNS Resolver.

$ cat /etc/unbound/unbound.conf
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

$ cat /etc/unbound/unbound.conf.d/cloudron-network.conf
# Unbound is used primarily for RBL queries (host 2.0.0.127.zen.spamhaus.org)
# We cannot use dnsmasq because it is not a recursive resolver and defaults to the value in the interfaces file (which is Google DNS!)

server:
        port: 53
        interface: 127.0.0.150
        interface: 172.18.0.1
        ip-freebind: yes
        access-control: 127.0.0.1 allow
        access-control: 172.18.0.1/16 allow
        cache-max-negative-ttl: 30
        cache-max-ttl: 300

        # Prefer IPv4 outbound queries. Spamhaus often rejects queries from IPv6 addresses
        # without this, unbound does not start on IPv6 only servers
        do-ip6: no
        # this setting only works with ubuntu 24 and unbound >= 1.19.2
        # prefer-ip4: yes

        # enable below for logging to journalctl -u unbound
        # verbosity: 5
        # log-queries: yes

# https://github.com/NLnetLabs/unbound/issues/806
remote-control:
    control-enable: no

$ ls -al /etc/unbound/unbound.conf.d/
total 16
drwxr-xr-x 2 root root 4096 Nov 25 09:28 .
drwxr-xr-x 3 root root 4096 Nov  6 06:18 ..
-rw-r--r-- 1 root root  949 Nov 25 09:28 cloudron-network.conf
-rw-r--r-- 1 root root  190 Sep  7  2022 root-auto-trust-anchor-file.conf

[james]

Hello @d1rk
From your post before of lsof -i :53
There is this process:

node      632203      yellowtent   24u  IPv4 8210389      0t0  UDP localhost.localdomain:57067->localhost:domain

If you run lsof -i :53 again, is there still a node process?
If so please run the following command with the PID of that node process and post the output:

lsof -p 632203