Is the container using the hosts /etc/resolv.conf by default? If there is a local resolver like nameserver 127.0.0.1, I guess that one might not be available from within the container. Unbound is configured to allow queries from all reserved IP ranges, including 172.16.0.0/12 used by Docker containers, so that is not the issue.
Though as we run into the same issue on rebuild, and indeed set up our own Unbound in the meantime, also after removing the the line so that /etc/resolv.conf contains again only nameserver 1.1.1.1 like before, the rebuild still fails at the same point. So maybe it is even cached somewhere? 
From the host, github.com can be resolved without issues.
EDIT: Nope, the /etc/resolv.conf is not the issue now. I added some debug output:
I, [2025-09-25T17:32:38.092043 #1] INFO -- : > cd /var/www/discourse && cat /etc/resolv.conf
I, [2025-09-25T17:32:38.093195 #1] INFO -- : # Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 1.1.1.1
# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: []
I, [2025-09-25T17:32:38.093221 #1] INFO -- : > cd /var/www/discourse && getent hosts github.com
I, [2025-09-25T17:32:58.111177 #1] INFO -- :
I, [2025-09-25T17:32:58.111456 #1] INFO -- : Terminating async processes
EDIT: apt update as well hangs forever, a test curl fails as well, both as test added to the Discourse templates to check whether network is online. nameserver 9.9.9.9 does not work either, so looks like the container has no network access, but no idea why.
… EDIT2: Okay, in our case Fail2Ban banned the container IP due to an invalid user account email address it was trying to sent emails to, triggering the Fail2Ban Postfix filter 
.
Hence, checking Fail2Ban can be one debug step if container has not network.
EDIT3: In Fail2Ban’s jail config:
ignoreip = 127.0.0.1/8 172.16.0.0/12
To avoid loopback and Docker IPs being banned.