Hetzner server and upstream DNS: Spamhaus ignoring DQS key

Hi all,
I’ve had Hestia on a Hetzner VM for a while, but I’ve been having some issues with Spamhaus.
I did follow all instructions to get and use a DQS server, and for a while it worked. I left the server alone for a few weeks and now it’s broken again.

It’s worth noting that Hetzner’s Ubuntu images are configured by default as to use Hetzner’s own upstream DNS caching resolver, but (as shown below) I’ve taken all the steps I can to make sure that I’m using my own bind as a local caching nameserver.

/etc/exim4/dnsbl.conf

bl.spamcop.net
[myownkey].zen.dq.spamhaus.net

/etc/spamassassin/local.cf

# ...
dns_server 127.0.0.1
# ...

/etc/systemd/resolved.conf

[Resolve]
DNS=127.0.0.1

(I commented everything else out, including FallbackDNS)

/etc/netplan/50-cloud-init.yaml

network:
# ...
    ethernets:
        eth0:
            addresses:
# ...
            dhcp4: true
            dhcp4-overrides:
                use-dns: false
            match:
# ...
            nameservers:
                addresses:
                - 127.0.0.1

(I removed everything else about dns)

/etc/resolv.conf:

nameserver 127.0.0.53
options edns0 trust-ad
search .

There are also no forwarders in any config files in /etc/bind, or any references to external servers.

Bind (and systemd-resolve?) are listening on port 53:

root@luna:~# lsof -Pn -c0 -i:53
COMMAND    PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r  677 systemd-resolve   14u  IPv4   7984      0t0  UDP 127.0.0.53:53 
systemd-r  677 systemd-resolve   15u  IPv4   7985      0t0  TCP 127.0.0.53:53 (LISTEN)
systemd-r  677 systemd-resolve   16u  IPv4   7986      0t0  UDP 127.0.0.54:53 
systemd-r  677 systemd-resolve   17u  IPv4   7987      0t0  TCP 127.0.0.54:53 (LISTEN)
named      768            bind   28u  IPv4  11077      0t0  UDP 127.0.0.1:53 
named      768            bind   29u  IPv4  11078      0t0  UDP 127.0.0.1:53 
named      768            bind   30u  IPv4  11079      0t0  TCP 127.0.0.1:53 (LISTEN)
named      768            bind   32u  IPv4  11080      0t0  TCP 127.0.0.1:53 (LISTEN)
named      768            bind   34u  IPv4  11081      0t0  UDP 157.90....:53 
named      768            bind   35u  IPv4  11082      0t0  UDP 157.90....53 
named      768            bind   36u  IPv4  11083      0t0  TCP 157.90....:53 (LISTEN)
named      768            bind   37u  IPv4  11084      0t0  TCP 157.90....:53 (LISTEN)
named      768            bind   38u  IPv6  11085      0t0  UDP [::1]:53 
named      768            bind   39u  IPv6  11086      0t0  UDP [::1]:53 
named      768            bind   40u  IPv6  11087      0t0  TCP [::1]:53 (LISTEN)
named      768            bind   41u  IPv6  11088      0t0  TCP [::1]:53 (LISTEN)
named      768            bind   42u  IPv6  11089      0t0  UDP [2a01:4f8:...]:53 
named      768            bind   43u  IPv6  11090      0t0  UDP [2a01:4f8:...]:53 
named      768            bind   44u  IPv6  11091      0t0  TCP [2a01:4f8:...]:53 (LISTEN)
named      768            bind   45u  IPv6  11092      0t0  TCP [2a01:4f8:...]:53 (LISTEN)
named      768            bind   46u  IPv6  11093      0t0  UDP [fe80::9400:2ff:fec5:936a]:53 
named      768            bind   47u  IPv6  11094      0t0  UDP [fe80::9400:2ff:fec5:936a]:53 
named      768            bind   48u  IPv6  11095      0t0  TCP [fe80::9400:2ff:fec5:936a]:53 (LISTEN)
named      768            bind   49u  IPv6  11096      0t0  TCP [fe80::9400:2ff:fec5:936a]:53 (LISTEN)
spamd\x20 1875            root   10u  IPv4  53070      0t0  UDP 127.0.0.1:33737->127.0.0.1:53 

and systemd seems to confirm:

root@luna:~# resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1 127.0.0.1

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1

So it really looks like it should be all done locally, but for some reason it doesn’t:

Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

2.0.0.127.zen.spamhaus.org has address 127.255.255.254

and using @sahsanu’s tool from Unable to receive mail / Openresolver confirms that:

root@luna:~# curl -sSL https://7j.gg/chksph2 | bash -s --
Test 01: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 02: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8.../
Test 03: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 04: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 05: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 06: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 07: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 08: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 09: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../
Test 10: Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:.../

Result is bad, Spamhaus is blocking/ignoring your current DNS Resolver 127.0.0.53{}

I even tried using my Hestia server’s DNS from my home connection, and it does not let me use it (so it’s not an open DNS server):

octavarium:~ jollino$ dig @luna.example.com google.com

; <<>> DiG 9.10.6 <<>> @luna.example.com google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 46134
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 12 ("..")
;; QUESTION SECTION:
;google.com.			IN	A

;; Query time: 44 msec
;; SERVER: 157.90.158.55#53(157.90.158.55)
;; WHEN: Sun Aug 03 17:53:22 CEST 2025
;; MSG SIZE  rcvd: 45

I’ve officially run out of ideas, and I’m missing the days when /etc/resolv.conf was the single place to set DNS resolution stuff.

I’m confused because using DQS should allow using an open resolver anyway, but I’ve set my server so it doesn’t even use one. Yet… it’s borked. Any advice would be most welcome. Not that I strictly need Spamhaus (I haven’t tried others but I’m sure I can work something out), I’d really just like to understand what exactly is preventing this from working in the first place.

Thanks in advance!

Hi @jollino

What errors do you see?

That should show nameserver 127.0.0.1. Did you reboot your server or apply the changes made to /etc/netplan/50-cloud-init.yaml?

netplan apply
systemctl restart systemd-resolved

Just keep in mind that my script uses zen.spamhaus.org, it doesn’t use the DQS subdomain [DQSKey].zen.dq.spamhaus.net

You could also force the system to resolve using IPv4. Edit /etc/gai.conf and uncomment this line.

#precedence ::ffff:0:0/96  100

First of all, thanks for your reply!

Most emails — but not all of them! — have this:

0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to
zen.spamhaus.org was blocked due to usage of an
open resolver. See
https://www.spamhaus.org/returnc/pub/
[62.149.156.61 listed in zen.spamhaus.org]

The oddest thing is that it does indeed sometimes work, as the DQS dashboard shows:

I did apply the changes when I first made them, and rebooted just earlier (which incidentally triggered the apache2 bug that your script at Nginx + apache + ssl = 421 misdirected request - #5 by sahsanu solved (thanks for that!).
Apparently 127.0.0.53 is a systemd quirk and indeed my /etc/resolv.conf is just a symlink to /run/systemd/resolve/stub-resolv.conf

I had missed that, thanks. The problem remains though: for some reason, my attempts at querying 2.0.0.127.zen.spamhaus.org, despite going through 127.0.0.1, return 127.255.255.254 (which means “you’re using an open dns!”), and mine is not even an open dns!

I’m going to give that a go, I admit I had no idea about that file. I stopped using Linux as my main driver before it became a thing. :slight_smile:

I just tested again and once again SpamAssassin seems to query the standard zen server (and via some open resolver too). Even weirder, there’s also a complaint about using dbl, which is NOT in my dnsbl.conf file.

In fact, I commented out the DQS subdomain too so that it only contained the spamcop one, restarted spamd, and sent myself an email… and got this:

Aug 03 20:56:49 luna.example.com spamd[6659]: spamd: checking message <[email protected]> for debian-spamd:120
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns1.dreamhost.com/A'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns3.dreamhost.com/A'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns3.dreamhost.com/AAAA'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns1.dreamhost.com/AAAA'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns2.dreamhost.com/A'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns2.dreamhost.com/AAAA'
Aug 03 20:56:49 luna.example.com named[768]: success resolving '41.218.85.209.list.dnswl.org/A' after disabling qname minimization due to 'ncache nxdomain'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns2.dreamhost.com/A'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns1.dreamhost.com/A'
Aug 03 20:56:49 luna.example.com named[768]: loop detected resolving 'ns3.dreamhost.com/A'
Aug 03 20:56:49 luna.example.com named[768]: success resolving '41.218.85.209.wl.mailspike.net/A' after disabling qname minimization due to 'ncache nxdomain'
Aug 03 20:56:49 luna.example.com named[768]: success resolving '41.218.85.209.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache nxdomain'
Aug 03 20:56:50 luna.example.com named[768]: REFUSED unexpected RCODE resolving 'bl.score.senderscore.com/NS/IN': 50.17.210.219#53
Aug 03 20:56:50 luna.example.com named[768]: REFUSED unexpected RCODE resolving 'bl.score.senderscore.com/NS/IN': 3.222.213.252#53
Aug 03 20:56:50 luna.example.com named[768]: REFUSED unexpected RCODE resolving 'bl.score.senderscore.com/NS/IN': 34.198.135.31#53
Aug 03 20:56:50 luna.example.com named[768]: REFUSED unexpected RCODE resolving 'bl.score.senderscore.com/NS/IN': 18.210.38.0#53
Aug 03 20:56:50 luna.example.com named[768]: success resolving '41.218.85.209.bl.score.senderscore.com/A' after disabling qname minimization due to 'failure'
Aug 03 20:56:50 luna.example.com spamd[6659]: 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 "dns_query_restriction deny zen.spamhaus.org" to disable queries)
Aug 03 20:56:50 luna.example.com spamd[6659]: spamd: clean message (3.1/5.0) for debian-spamd:120 in 0.9 seconds, 3102 bytes.
Aug 03 20:56:50 luna.example.com spamd[6659]: spamd: result: .  3 - DMARC_NONE,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_ZEN_BLOCKED_OPENDNS,SPF_HELO_NONE,SPF_PASS,TVD_SPACE_RATIO,URIBL_DBL_BLOCKED_OPENDNS scantime=0.9,size=3102,user=debian-spamd,uid=120,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=41572,mid=<[email protected]>,autolearn=no autolearn_force=no

And while I do have a .spamassassin directory in /root, it’s empty. I’m even more confused at this point, and someone else had a similar problem but there’s no answer.

(As a side note, it looks like restarting spamassassin from the web panel fails and just says “Error: ERROR: Restart of spamassassin failed.”; I’ve been using service spamd restart)

You’re welcome :wink:

If you are not using forwarders in Bind, then it seems that Spamhaus believes your IP is being used by a public/open DNS resolver, or it is blocking it for some other reason (for example, you might be making the request over IPv6 and Spamhaus is blocking IPv6 queries from your hosting provider…).

You could force Bind to use only IPv4. To do that, edit the /etc/bind/named.conf.options file and within the options block, add the following lines:

        listen-on-v6 { none; };
        listen-on port 53 { 127.0.0.1/32; };

Restart Bind and try again:

systemctl restart named

/etc/exim4/dnsbl.conf only affects Exim. SpamAssassin knows nothing about that configuration file, so it doesn’t use it. By default, SpamAssassin uses zen.spamhaus.org. If you want SpamAssassin to use your DQS key, follow these steps:

Note: replace abcdefghijklmnop0123456789 with your actual DQS Key.

cd /usr/local/src/
git clone https://github.com/spamhaus/spamassassin-dqs
cd spamassassin-dqs/4.0.0+/
sed -i -e 's/your_DQS_key/abcdefghijklmnop0123456789/g' sh.cf
cp sh.cf /etc/spamassassin/
cp sh_scores.cf /etc/spamassassin/

To check that there are no erros:

spamassassin --lint

If all is ok (no output), restart the service:

systemctl restart spamd

Now SpamAssassin will use the DQS Key to query Spamhaus.

Could you please show the output of these commands?

systemctl restart spamd
systemctl status spamd --no-pager -l
spamassassin --lint

This makes a lot of sense, no idea why I thought they would be intertwined, and explains why I do get hits in the dashboard and why some spam is (or was) not delivered at all until a while ago. I’m genuinely not sure what changed because it was all working until mid-May, and I did all of the DNS work precisely to fix this on the 19th (I took notes). Apparently it worked for a few days, and then it started acting up again.

I was able to disable systemd-resolver’s usage of 127.0.0.53 by adding DNSStubListener=no to /etc/systemd/resolved.conf, but that didn’t fix the issue with the default Zen endpoint. I suppose that they decided that anything coming from within Hetzner is from an open resolver. Others probably do the same as well, since I had to block Validity’s checks for the same reason by setting RCVD_IN_VALIDITY_CERTIFIED and RCVD_IN_VALIDITY_SAFE to 0.0 in my /etc/spamassassin/local.cf.

I just copied the scores from the repository you suggested, and will keep an eye on it, so far, from my own tests, it seems to be fine. Thanks! I suppose that those new rules supersede those in /usr/share/spamassassin?

root@luna:~# systemctl restart spamd
root@luna:~# systemctl status spamd --no-pager -l
● spamd.service - Perl-based spam filter using text analysis
     Loaded: loaded (/usr/lib/systemd/system/spamd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-08-04 08:25:20 CEST; 2s ago
   Main PID: 4690 (spamd)
      Tasks: 3 (limit: 4434)
     Memory: 133.6M (peak: 133.8M)
        CPU: 1.488s
     CGroup: /system.slice/spamd.service
             ├─4690 /usr/bin/perl "-T -w" /usr/sbin/spamd --pidfile=/run/spamd.pid --create-prefs --max-children 5 --helper-home-dir
             ├─4695 "spamd child"
             └─4696 "spamd child"

Aug 04 08:25:20 luna.example.com systemd[1]: Started spamd.service - Perl-based spam filter using text analysis.
Aug 04 08:25:21 luna.example.com spamd[4690]: zoom: able to use 388/388 'body_0' compiled rules (100%)
Aug 04 08:25:21 luna.example.com spamd[4690]: spamd: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 4.0.0)
Aug 04 08:25:21 luna.example.com spamd[4690]: spamd: server pid: 4690
Aug 04 08:25:21 luna.example.com spamd[4690]: spamd: server successfully spawned child process, pid 4695
Aug 04 08:25:21 luna.example.com spamd[4690]: spamd: server successfully spawned child process, pid 4696
Aug 04 08:25:21 luna.example.com spamd[4690]: prefork: child states: IS
Aug 04 08:25:21 luna.example.com spamd[4690]: prefork: child states: II
root@luna:~# spamassassin --lint
root@luna:~# 

It seems to be fine, but the web version complains:

This appears to mention it (it works!), but it does seem related to my upgrade of Ubuntu 22 to 24. Maybe it should be mentioned on the system upgrade page?

On a related note (sorry for all the pestering) it looks like hestia is not included in my apt sources anymore, since I’m stuck on 1.9.3 and I get zero packages to upgrade via apt. Trying v-update-sys-hestia-all just complains:

root@luna:~# v-update-sys-hestia-all
W: Unable to read /etc/apt/-/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list.d/hestia.list - RealFileExists (2: No such file or directory)
W: Unable to read /etc/apt/-/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list.d/hestia.list - RealFileExists (2: No such file or directory)
W: Unable to read /etc/apt/-/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list.d/hestia.list - RealFileExists (2: No such file or directory)

I’ve copied hestia.list.distUpgrade to hestia.list and changed the codename from jammy to noble, did the same with nginx.list (not mariadb since it’s “fixed” at 11.4), it upgraded and it seems to work. I only got a few nginx warnings (“nginx: [warn] “ssl_stapling” ignored, no OCSP responder URL in the certificate …pem”) but it seems to be fine.

Indeed it looks like a bug, I’ll take a look later, for now:

v-change-sys-config-value ANTISPAM_SYSTEM spamd

Yes, those scores supersedes the ones in /usr/share/spamassassin/ but did you only copied sh_scores.cf? You should also modify sh.cf with your DQS Key and copy it also to /etc/spamassassin/

If you upgraded from 22.04 to 24.04, usually the upgrade modifies the apt sources to disable them, so you will need to modify them to use noble instead of jammy and enable them again.

Show the output of this command:

find /etc/apt/sources.list.d/ -type f -print0 | while IFS= read -r -d '' file; do echo "===== Checking $file =====";cat "$file";echo "==================="; echo;done

After you can upgrade to Hestia 1.9.4 (you can do it in version 1.9.3 but you should do it again after the upgrade to 1.9.4):

curl -fsSLm15 https://7j.gg/remstap | sudo bash -s --

I went the old-school way and edited the .conf file directly. :smiley: (I also updated my post a few times to avoid adding more, so it may have changed while you were replying; sorry!)

Yes, I copied both and it seems to work for now; I’ll test in the coming days, before moving my main domain to this server so I can finally shut down my DreamHost account. I’ve been holding off precisely because I’m terrified of losing email.

Yep, that’s what I figured out and tweaked by hand (again, sorry for probably editing my message while you were already answering!)

Your script returns this:

===== Checking /etc/apt/sources.list.d/ondrej-ubuntu-php-noble.sources =====
Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/
Suites: noble
Components: main
Signed-By: -----BEGIN PGP PUBLIC KEY BLOCK-----
 .
 mQINBGYo0vEBEAC0Semxy5I2b8exRUxJfTKkHR4f5uyS0dTd9vYgMI5T3gsa7ypH
 HtE+GiZC+T9m/F9h66+XJMxhuNsKRs7T2In5NSeso9H/ytlSTayUaBtCFfRp6y6b
 6ozuRBfqYJGxhjAnIzvNF/Wpp2BvfQm3OrQ7uJJrt5IvzLDC4jPxl/Xs3sTT+Hbk
 bkKKprZ3xmy2enuwBaNWR/CUtAz3hbkzL1kGbhX9m3QidFJagVVdDw3aNEwo8ush
 djWfF+BajNvpDFYJKBGQbCeagB753Baa5yIN62x+THLnLiKTMDS1e7U0ZDiV9671
 noTbtN5TeZeyfsEmeZ8X60x11JIP3yYHYZT70/DyTYX3WC9yQFyIgVOfRlGklMKI
 k3TLMmtq8w5Hz1vovwzV7PzaQnmY+uNP2ZbAP4fJ3iFAj0L+u0i1nOFgTy0Lq058
 O/FjRrQxuceDDCF+9ThspXMw3Puvz8giuBDCdEda84uC7XWMdqgz/maLfFQjAmyP
 Ixi1EMxMlHYyZajpR1cdCfrAIQlnQjHSWmyeCFgXPPfRA71aCcJ7oSrDjogW6Ahd
 HRkQRKf1FF9BFzycgSQotfR+7CKfPQh1kghufM9W/spARzA709nGZjXJzgEJLQd3
 CDB6dIIxT/0YI36h3Qgfmiiw4twO24MMEqEEPIELz2WJKeWGkdQdcekpxQARAQAB
 tB9MYXVuY2hwYWQgUFBBIGZvciBPbmTFmWVqIFN1csO9iQJOBBMBCgA4FiEEuNx+
 U5RmVu+85MHdcdrqq0rUyrYFAmYo0vECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgEC
 F4AACgkQcdrqq0rUyrYOPQ/+IArA4s1J3op/w7cXek0ieFHWHFDrxPYS+78/LF/J
 LoYZw0nIU5Ovr+LzehFMIQU6esgPXwbeCVgwLwat57augAkAYWT0UzH5dE6RKAGr
 C2vsHWVfPhQn6UndfzwXc0mTLGQni25aQaZ6k60Dbm/vblejrTQrtAUWoMO3Z1cr
 NDGJ3Z9DCxtr2o9gRYUI6HwLHJtobTIeI5xsr5x+GvXiIAVCPa3ZEuRL6jMQfqfS
 C43mpuiS1kGgsnQLs2DbN7EFCfiJoNX1QzZu25zg+IS9PXbCJnheZWnH0rwUSb/N
 hZPcSefGlNlhr824OfT30v79hQnw59XbsfV270O9jPbD4kttN+OiszbU66zsuiOh
 BO46XCckQPqDkBMw56GPFuVrQgGb1thXvn67URJgPyJhwauBWKPNAJ9Ojuo+yVq/
 hdR1VNWThXQbZgaGSWrbjt6FdYtQb9VX88uu5gFDmr180HogHNUDUcqNLLdnjfFs
 4DyJlusQ5I/a7cQ7nlkNgxAmHszwO/mGLBuGljDUYkwZDW9nqP1Q5Q2jMtrhgXvR
 2SOtufvecUbB7+eoRSaOnu7CNMATG6LocFEMzhKUde1uZTfWSqnYEcdqoFJMi46y
 qaNxhiNLsQ5OBMbgSp2zCbQxRBdITMVvBR5YjCetUIGEs6T1yQ5wh5Xpoi34ShHn
 v38=
 =kFlZ
 -----END PGP PUBLIC KEY BLOCK-----
===================

===== Checking /etc/apt/sources.list.d/ondrej-ubuntu-php-jammy.list.distUpgrade =====
deb https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ noble main
# deb-src https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main
===================

===== Checking /etc/apt/sources.list.d/third-party.sources =====
Types: deb
URIs: https://mirror.hetzner.com/ubuntu-ports/packages
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: https://mirror.hetzner.com/ubuntu-ports/security
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
===================

===== Checking /etc/apt/sources.list.d/hestia.list.distUpgrade =====
deb [arch=arm64 signed-by=/usr/share/keyrings/hestia-keyring.gpg] https://apt.hestiacp.com/ jammy main
===================

===== Checking /etc/apt/sources.list.d/apache2.list.distUpgrade =====
deb http://ppa.launchpad.net/ondrej/apache2/ubuntu noble main
===================

===== Checking /etc/apt/sources.list.d/nginx.list =====
deb [arch=arm64 signed-by=/usr/share/keyrings/nginx-keyring.gpg] https://nginx.org/packages/mainline/ubuntu/ noble nginx
===================

===== Checking /etc/apt/sources.list.d/mariadb.list.distUpgrade =====
deb [arch=arm64 signed-by=/usr/share/keyrings/mariadb-keyring.gpg] https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/ubuntu jammy main
===================

===== Checking /etc/apt/sources.list.d/nginx.list.distUpgrade =====
deb [arch=arm64 signed-by=/usr/share/keyrings/nginx-keyring.gpg] https://nginx.org/packages/mainline/ubuntu/ jammy nginx
===================

===== Checking /etc/apt/sources.list.d/hestia.list =====
deb [arch=arm64 signed-by=/usr/share/keyrings/hestia-keyring.gpg] https://apt.hestiacp.com/ noble main
===================

===== Checking /etc/apt/sources.list.d/ondrej-ubuntu-apache2-noble.sources =====
Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/apache2/ubuntu/
Suites: noble
Components: main
Signed-By: 
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 .
 mQINBGYo0vEBEAC0Semxy5I2b8exRUxJfTKkHR4f5uyS0dTd9vYgMI5T3gsa7ypH
 HtE+GiZC+T9m/F9h66+XJMxhuNsKRs7T2In5NSeso9H/ytlSTayUaBtCFfRp6y6b
 6ozuRBfqYJGxhjAnIzvNF/Wpp2BvfQm3OrQ7uJJrt5IvzLDC4jPxl/Xs3sTT+Hbk
 bkKKprZ3xmy2enuwBaNWR/CUtAz3hbkzL1kGbhX9m3QidFJagVVdDw3aNEwo8ush
 djWfF+BajNvpDFYJKBGQbCeagB753Baa5yIN62x+THLnLiKTMDS1e7U0ZDiV9671
 noTbtN5TeZeyfsEmeZ8X60x11JIP3yYHYZT70/DyTYX3WC9yQFyIgVOfRlGklMKI
 k3TLMmtq8w5Hz1vovwzV7PzaQnmY+uNP2ZbAP4fJ3iFAj0L+u0i1nOFgTy0Lq058
 O/FjRrQxuceDDCF+9ThspXMw3Puvz8giuBDCdEda84uC7XWMdqgz/maLfFQjAmyP
 Ixi1EMxMlHYyZajpR1cdCfrAIQlnQjHSWmyeCFgXPPfRA71aCcJ7oSrDjogW6Ahd
 HRkQRKf1FF9BFzycgSQotfR+7CKfPQh1kghufM9W/spARzA709nGZjXJzgEJLQd3
 CDB6dIIxT/0YI36h3Qgfmiiw4twO24MMEqEEPIELz2WJKeWGkdQdcekpxQARAQAB
 tB9MYXVuY2hwYWQgUFBBIGZvciBPbmTFmWVqIFN1csO9iQJOBBMBCgA4FiEEuNx+
 U5RmVu+85MHdcdrqq0rUyrYFAmYo0vECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgEC
 F4AACgkQcdrqq0rUyrYOPQ/+IArA4s1J3op/w7cXek0ieFHWHFDrxPYS+78/LF/J
 LoYZw0nIU5Ovr+LzehFMIQU6esgPXwbeCVgwLwat57augAkAYWT0UzH5dE6RKAGr
 C2vsHWVfPhQn6UndfzwXc0mTLGQni25aQaZ6k60Dbm/vblejrTQrtAUWoMO3Z1cr
 NDGJ3Z9DCxtr2o9gRYUI6HwLHJtobTIeI5xsr5x+GvXiIAVCPa3ZEuRL6jMQfqfS
 C43mpuiS1kGgsnQLs2DbN7EFCfiJoNX1QzZu25zg+IS9PXbCJnheZWnH0rwUSb/N
 hZPcSefGlNlhr824OfT30v79hQnw59XbsfV270O9jPbD4kttN+OiszbU66zsuiOh
 BO46XCckQPqDkBMw56GPFuVrQgGb1thXvn67URJgPyJhwauBWKPNAJ9Ojuo+yVq/
 hdR1VNWThXQbZgaGSWrbjt6FdYtQb9VX88uu5gFDmr180HogHNUDUcqNLLdnjfFs
 4DyJlusQ5I/a7cQ7nlkNgxAmHszwO/mGLBuGljDUYkwZDW9nqP1Q5Q2jMtrhgXvR
 2SOtufvecUbB7+eoRSaOnu7CNMATG6LocFEMzhKUde1uZTfWSqnYEcdqoFJMi46y
 qaNxhiNLsQ5OBMbgSp2zCbQxRBdITMVvBR5YjCetUIGEs6T1yQ5wh5Xpoi34ShHn
 v38=
 =kFlZ
 -----END PGP PUBLIC KEY BLOCK-----
===================

This includes the hestia.list and nginx.list that I had already fixed manually. The mariadb one complained: E: The repository 'https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/ubuntu noble Release' does not have a Release file. but everything else (including apache, which was upgraded yesterday and caused the 421 error, which I fixed through your script in the other thread) is fine.

I ran your script and it’s done its job, and it all seems to work.

Thank you so much for your help, @sahsanu! I really appreciate it, and I’m sure others will also find this thread useful if they manage to go through all of it. :slight_smile:

It’s fixed to 11.4 but it receives updates 11.4.x so you must have this repo configured.

Looks like the mariadb repo has some issues now, al least for noble, try again later.

You’re welcome :wink:

Sorted it via Download MariaDB Server - MariaDB.org if anyone else is having the same issue!

1 Like

Repository dlm.mariadb.com works fine again.