Tiny Tiny RSS - suddenly can‘t resolve hosts

[necrevistonnezr]

Suddenly, the Tiny Tiny RSS instance can‘t resolve hosts anymore…
For all feeds, I entries like:

Mar 26 09:21:19 PHP Notice: Update process for feed 126 (Thunderbird release note, owner UID: 2) failed with exit code: 100 (; 6 Could not resolve host: rsshub.app). in /app/code/classes/logger.php on line 52
Mar 26 09:21:19 [07:21:19/8] Base feed: http://feeds.feedburner.com/djtechtools
Mar 26 09:21:20 [07:21:19/8] => DJ TechTools (ID: 154, U: kdj [2]), last updated: 2023-03-26 06:41:19
Mar 26 09:21:20 - - - [26/Mar/2023:07:21:20 +0000] "GET / HTTP/1.1" 200 513 "-" "Mozilla (CloudronHealth)"
Mar 26 09:21:21 [07:21:21/122] Lock: update_daemon-feed-154.lock
Mar 26 09:21:21 [07:21:21/8] <= 1.3039 (sec) exit code: 100
Mar 26 09:21:21 [07:21:21/8] !! Last error: ; 6 Could not resolve host: feeds.feedburner.com
Mar 26 09:21:21 PHP Notice: Update process for feed 154 (DJ TechTools, owner UID: 2) failed with exit code: 100 (; 6 Could not resolve host: feeds.feedburner.com). in /app/code/classes/logger.php on line 52
Mar 26 09:21:21 [07:21:21/8] Base feed: https://forum.cloudron.io/category/1.rss
Mar 26 09:21:21 [07:21:21/8] => Cloudron Announcements (ID: 49, U: kdj [2]), last updated: 2023-03-26 06:41:20
Mar 26 09:21:21 [07:21:21/125] Lock: update_daemon-feed-49.lock
Mar 26 09:21:21 [07:21:21/8] <= 0.5532 (sec) exit code: 100

All other apps are fine, and the same hosts resolve when I ssh into the Cloudron instance….?

[girish]

@necrevistonnezr how about in the web terminal ?

[necrevistonnezr]

@girish I get

root@72914322-2a56-4682-873d-644f7aa948cb:/app/code# curl www.google.com
curl: (6) Could not resolve host: www.google.com

EDIT: Weird, it seems, NONE of the apps can resolve google.com - but the system can when SSHed in?

[girish]

@necrevistonnezr On the system, you should try host www.google.com 127.0.0.1 . The containers use unbound. The host will use depending on /etc/resolv.conf . Can you check if Services -> Unbound is up? This is most likely the issue.

[necrevistonnezr]

@girish said in Tiny Tiny RSS - suddenly can‘t resolve hosts:

@necrevistonnezr On the system, you should try host www.google.com 127.0.0.1 .

Result:

host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host google.com not found: 2(SERVFAIL)

The containers use unbound. The host will use depending on /etc/resolv.conf .

cat /etc/resolv.conf
timeout 1
nameserver 1.1.1.1
nameserver 10.135.98.1
nameserver fd00:6968:6564:3b1::1

Can you check if Services -> Unbound is up? This is most likely the issue.

Unbound is "green" but the log is full orf errors like this:

Mar 26 17:01:25 my.DOMAIN.com unbound[1311]: [1311:0] info: generate keytag query _ta-4f66. NULL IN
Mar 26 17:01:25 my.DOMAIN.com unbound[1311]: [1311:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN
Mar 26 17:01:25 my.DOMAIN.com unbound[1311]: [1311:0] info: generate keytag query _ta-4f66. NULL IN
Mar 26 17:01:25 my.DOMAIN.com unbound[1311]: [1311:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN

Unbound is configured as recommended:

cat /etc/unbound/unbound.conf.d/forward-everything.conf
forward-zone:
    name: "."
    forward-addr: 1.1.1.1
    forward-addr: 8.8.8.8

I already tried (from the Troubleshooting doc):

unbound-anchor -a /var/lib/unbound/root.key
systemctl restart unbound

[girish]

@necrevistonnezr not 100% sure but I found https://www.mail-archive.com/unbound-users@lists.nlnetlabs.nl/msg01158.html which suggests that maybe the forwarders (1.1.1.1 and 8.8.8.8) are maybe filtering out DNS SEC related stuff. Can you see if disabling DNSSEC helps - https://docs.cloudron.io/troubleshooting/#dns ?

[necrevistonnezr]

@girish Disabling DNSSEC did the trick! Thanks!
Any idea why this would suddenly happen? Do I need to leave it disabled - and is that a problem?

[girish]

@necrevistonnezr It's not ideal. But something in the network (can also be your ISP) is blocking DNSSEC. DNSSEC is a way to verify the DNS responses and that someone in the middle did not put in their own IP address instead. Practically, it's hard to tell what the implications are since DNSSEC itself is not a hard requirement in application software. Stats here - https://rick.eng.br/dnssecstat/

I know, vague answer

[necrevistonnezr]

@girish This error is suddenly back, even with disabling DNSSEC. I cannot access any apps or mail.

Apr 27 07:50:44 my.domain.net systemd[1]: Starting Unbound DNS Resolver...
Apr 27 07:50:44 my.domain.net unbound[14619]: [14619:0] notice: init module 0: subnet
Apr 27 07:50:44 my. domain.net unbound[14619]: [14619:0] notice: init module 1: validator
Apr 27 07:50:44 my.domain.net unbound[14619]: [14619:0] notice: init module 2: iterator
Apr 27 07:50:44 my.domain.net unbound[14619]: [14619:0] error: duplicate forward zone . ignored.
Apr 27 07:50:44 my.domain.net unbound[14619]: [14619:0] info: start of service (unbound 1.13.1).
Apr 27 07:50:44 my.ckfl.net systemd[1]: Started Unbound DNS Resolver.
Apr 27 07:50:50 my.domain.net unbound[14619]: [14619:0] info: generate keytag query _ta-4f66. NULL IN
Apr 27 07:50:50 my.domain.net unbound[14619]: [14619:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN
Apr 27 07:50:50 my.domain.net unbound[14619]: [14619:0] info: generate keytag query _ta-4f66. NULL IN
Apr 27 07:50:50 my.domain.net unbound[14619]: [14619:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN
Apr 27 07:50:50 my.domain.net unbound[14619]: [14619:0] info: generate keytag query _ta-4f66. NULL IN
Apr 27 07:50:50 my.domain.net unbound[14619]: [14619:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN

Are those files correct?

[nebulon]

@necrevistonnezr seems like there are a few custom config files added. cloudron-network.conf and root-auto-trust-anchor-file.conf are the only default ones on Cloudron (depending on ubuntu version and thus unbound version. also qname-minimisation.conf)

Try to move the others away and for good measure regenerate the anchor maybe unbound-anchor -a /var/lib/unbound/root.key

[necrevistonnezr]

Thanks! Removing all old conf files and regenerating the anchor works for now and survived a reboot, i.e. it works now even without disabling DNSSEC.