Is the docker DNS performance issue documented anywhere? It definitely needs to be prominent because docker DNS is a federation killer, hardly exaggerating
Is the docker DNS performance issue documented anywhere? It definitely needs to be prominent because docker DNS is a federation killer, hardly exaggerating
I wasn't fully aware there was a DNS performance with Docker, so I don't think it's documented. I haven't been having any major issues with my homeserver, although it does run on Podman - not sure how different the DNS setup is there.
I wasn't fully aware there was a DNS performance with Docker, so I don't think it's documented. I haven't been having any major issues with my homeserver, although it does run on Podman - not sure how different the DNS setup is there.
Not sure if it's all green in podland, but docker's DNS causing federation performance issues is a well known phenomenon even outside of matrix. IIRC it was recommended somewhere to pass through /etc/resolv.conf as a bind mount to bypass it but I can't remember where that is
Not sure if it's all green in podland, but docker's DNS causing federation performance issues is a well known phenomenon even outside of matrix. IIRC it was recommended somewhere to pass through /etc/resolv.conf as a bind mount to bypass it but I can't remember where that is
can confirm, recommended quite a number of people deploy an unbound somewhere nearby to solve their docker-dns issues which were preventing federation due to inability to keep up with the dns requests.
can confirm, recommended quite a number of people deploy an unbound somewhere nearby to solve their docker-dns issues which were preventing federation due to inability to keep up with the dns requests.
Perhaps we should have an entire section for DNS performance because it's something that massively hinders the user experience and a lot of people don't set it up properly
Perhaps we should have an entire section for DNS performance because it's something that massively hinders the user experience and a lot of people don't set it up properly
Containers use the same DNS servers as the host by default, but you can override this with --dns.
By default, containers inherit the DNS settings as defined in the /etc/resolv.conf configuration file. Containers that attach to the default bridge network receive a copy of this file. Containers that attach to a custom network use Docker's embedded DNS server. The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.
You can configure DNS resolution on a per-container basis, using flags for the docker run or docker create command used to start the container. The following table describes the available docker run flags related to DNS configuration.
It's possible this only affects people using Docker's embedded resolver by using a non-default network?
Agreeing on the DNS performance section.
According to docker's docs:
> Containers use the same DNS servers as the host by default, but you can override this with --dns.
>
> By default, containers inherit the DNS settings as defined in the /etc/resolv.conf configuration file. Containers that attach to the default bridge network receive a copy of this file. Containers that attach to a custom network use Docker's embedded DNS server. The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.
>
> You can configure DNS resolution on a per-container basis, using flags for the docker run or docker create command used to start the container. The following table describes the available docker run flags related to DNS configuration.
It's possible this only affects people using Docker's embedded resolver by using a non-default network?
Agreeing on the DNS performance section.
Afaik, docker intercepts the DNS requests, or at least it does in compose, to resolve other container names on the docker network. This is where the performance issue comes from, and why manually binding /etc/resolv.conf bypasses the issue
Afaik, docker intercepts the DNS requests, or at least it does in compose, to resolve other container names on the docker network. This is where the performance issue comes from, and why manually binding /etc/resolv.conf bypasses the issue
Jade
changed title from docs: Tone down the docker warning to docs: Add Matrix links, Docker changes2025-04-21 15:27:14 +00:00
Note for later: It's likely that the example Compose files actually trigger Docker's DNS issues, and we should fix them or remove them.
I still think that having a dedicated page/big section to mentioning general DNS performance issues and workarounds would go further than this, but sounds good in the meantime
@Jade wrote in https://forgejo.ellis.link/continuwuation/continuwuity/pulls/782#issuecomment-15402:
> Note for later: It's likely that the example Compose files actually trigger Docker's DNS issues, and we should fix them or remove them.
I still think that having a dedicated page/big section to mentioning general DNS performance issues and workarounds would go further than this, but sounds good in the meantime
Join our [Matrix room](https://matrix.to/#/%23continuwuity:continuwuity.org) and [space](https://matrix.to/#/%23space:continuwuity.org) to chat with us about the project!
(percent-encoded sigils sometimes freak out the site, for some reason)
`https://matrix.to/#/%23continuwuity:continuwuity.org` -> `https://matrix.to/#/#continuwuity:continuwuity.org`
`https://matrix.to/#/%23space:continuwuity.org` -> `https://matrix.to/#/#space:continuwuity.org`
(percent-encoded sigils sometimes freak out the site, for some reason)
Is the docker DNS performance issue documented anywhere? It definitely needs to be prominent because docker DNS is a federation killer, hardly exaggerating
I wasn't fully aware there was a DNS performance with Docker, so I don't think it's documented. I haven't been having any major issues with my homeserver, although it does run on Podman - not sure how different the DNS setup is there.
Not sure if it's all green in podland, but docker's DNS causing federation performance issues is a well known phenomenon even outside of matrix. IIRC it was recommended somewhere to pass through /etc/resolv.conf as a bind mount to bypass it but I can't remember where that is
can confirm, recommended quite a number of people deploy an unbound somewhere nearby to solve their docker-dns issues which were preventing federation due to inability to keep up with the dns requests.
Perhaps we should have an entire section for DNS performance because it's something that massively hinders the user experience and a lot of people don't set it up properly
According to docker's docs:
It's possible this only affects people using Docker's embedded resolver by using a non-default network?
Agreeing on the DNS performance section.
Afaik, docker intercepts the DNS requests, or at least it does in compose, to resolve other container names on the docker network. This is where the performance issue comes from, and why manually binding /etc/resolv.conf bypasses the issue
docs: Tone down the docker warningto docs: Add Matrix links, Docker changesI've pushed some new changes, including an explanation of the docker issues as far as I understand them.
Note for later: It's likely that the example Compose files actually trigger Docker's DNS issues, and we should fix them or remove them.
@Jade wrote in #782 (comment):
I still think that having a dedicated page/big section to mentioning general DNS performance issues and workarounds would go further than this, but sounds good in the meantime
looks good, I just think the matrix.to links shouldn't be urlencoded
@ -107,3 +107,3 @@#### Contact<!-- TODO: contact details -->Join our [Matrix room](https://matrix.to/#/%23continuwuity:continuwuity.org) and [space](https://matrix.to/#/%23space:continuwuity.org) to chat with us about the project!https://matrix.to/#/%23continuwuity:continuwuity.org->https://matrix.to/#/#continuwuity:continuwuity.orghttps://matrix.to/#/%23space:continuwuity.org->https://matrix.to/#/#space:continuwuity.org(percent-encoded sigils sometimes freak out the site, for some reason)
500
Internal server error
Forgejo version: 13.0.0-dev-439-c6a2b7e0a6+gitea-1.22.0