# Could not resolve host: github.com

**URL:** <https://meta.discourse.org/t/could-not-resolve-host-github-com/372891>\
**Category:** Product Support\
**Created:** [July 4, 2025, 7:55am UTC](https://meta.discourse.org/t/could-not-resolve-host-github-com/372891 "2025-07-04T07:55:32Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![MichaIng](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaing/32/251089_2.png) [@MichaIng](https://meta.discourse.org/u/MichaIng)\
**Post date:** [September 25, 2025, 5:22pm UTC](https://meta.discourse.org/t/could-not-resolve-host-github-com/372891/3 "2025-09-25T17:22:54Z")

</div>

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:

```plaintext
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:

```plaintext
ignoreip = 127.0.0.1/8 172.16.0.0/12

```

To avoid loopback and Docker IPs being banned.

---

_[View the full topic](https://meta.discourse.org/t/could-not-resolve-host-github-com/372891)._