Slow dns response for jellyseerr container

Help Community Help
1

yes i have Traefik, but its behind pi-hole and not relevant to the traffic in question, so i don't think its relevant.

Expected Behaviour:

Jellyseerr should be loading titles almost instantly, this is not the case
adding "
dns:
- 9.9.9.9
- 8.8.8.8
- 1.1.1.1" to the relevant docker container solved the issue.

i have had issues in the past that we never figured out why, problems with Foundry inconsistently having issues with fetching from github, similarly solved by bypassing pi-hole.

Hardware:
AMD Ryzen 9 7940HS w/ 64gb ram and a 2060 6gb graphic card used by two containers.
Host OS: Proxmox, its hosting Truenas (who gets its own ethernet port and the graphics card)
Truenas then hosts docker with got 2 networks "MAIN" with is what most of my apps use and pihole+unbound gets its own, thats running bridge with "driver: bridge".
here's the pihole compose file. 1.8 KB file on MEGA

Router info.
Model: Asus RT-AX57
IPV6: Disabled
DNS pointed at: my pi-hole

noteworthy settings.
blocking: DISABLED
Rate limiting: 0,0
interface potential dangerous setting: all origin
upstream dns server: 8.8.8.8

Versions:
truenas: ElectricEel-24.10.3-MASTER-20250128-060555
docker engine version: Docker version 27.1.1, build 6312585

Actual Behaviour:

when jellyseerr goes through pi-hole loading each title can take upwards of 10 seconds to load, the influence of this slowdown is not apparent evenly across my network, user computers for browsing,gaming,etc do not notice this behavior directly.

Noteworthy detail.
i have in the past come here for an issue with Foundry container having inconsistant issues with fetching content from github, that conversation can be found here.

User comment.
to be specific, i know that removing pi-hole from my network will fix all issues entirely, but i want to use pi-hole, would be a shame if it had to come to that.

Can the container reach pi-hole using nc -v ip port?
Yes, port open.

User PC Latency to Pi-hole?
about 44ns at highest while in the webui using f12 network and refresh.

Debug Token:

https://tricorder.pi-hole.net/bt606q4r/

2

That link doesn't open for me ('The site failed to load', 'The file "lang/some-long-name.json" could not be loaded.').

Please share your docker compose as a post.

3

link works fine on my end, ah well!

networks:
  dns_net:
    driver: bridge
    ipam:
        config:
        - subnet: 172.23.0.0/16
services:
  pihole:
    container_name: pihole
    hostname: pihole
    image: pihole/pihole:latest # remember to change this if you're using rpi
    networks:
      dns_net:
        ipv4_address: 172.23.0.7
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "85:80/tcp"
      - "15443:443/tcp"
    environment:
      TZ: 'Europe/Copenhagen'
      WEBPASSWORD: 'MYPASSWORD'
      PIHOLE_DNS_: '172.23.0.8#5053'
      # Set a password to access the web interface. Not setting one will result in a random password being assigned
      FTLCONF_webserver_api_password: 'MYPASSWORD'
      # If using Docker's default `bridge` network setting the dns listening mode should be set to 'all'
      FTLCONF_dns_listeningMode: 'all'
    volumes:
      - '/mnt/NVME Pool-1/nvme-main/docker/pihole/etc-pihole/:/etc/pihole/'
      - '/mnt/NVME Pool-1/nvme-main/docker/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    cap_add:
      # See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
      # Required if you are using Pi-hole as your DHCP server, else not needed
      - NET_ADMIN
      # Required if you are using Pi-hole as your NTP client to be able to set the host's system time
      - SYS_TIME
      # Optional, if Pi-hole should get some more processing time
      - SYS_NICE
    restart: unless-stopped
  unbound:
    container_name: unbound
    image: mvance/unbound:latest # remember to change this if you're using rpi
    networks:
      dns_net:
        ipv4_address: 172.23.0.8
    volumes:
      - /mnt/NVME Pool-1/nvme-main/docker/unbound:/opt/unbound/etc/unbound
    ports:
      - "5053:53/tcp"
      - "5053:53/udp"
    healthcheck:
      test: ["NONE"]
    restart: unless-stopped
4

You've put your Pi-hole and unbound container's on the same 172.23.0.0/16 network, configuring Pi-hole to talk to unbound via Docker's internal IP here.

As unbound's Docker container is listening on port 53, Pi-hole should talk to 172.23.0.8#53 (or to your <docker-host-ip>#5053) instead of 172.23.0.8#5053 - there is nothing listening on that port, so I'd doubt that you are able to get any public DNS resolution with that configuration.

On a side note, if you'd intend to run your unbound as a recursive resolver, mvance/unbound probably isn't the right choice, as that's not configuring unbound as a recursive resolver, but as a DoT forwarder.

How do you configure your jellyseer container's DNS server?

5

good point on the 172.23.0.8#53
my original intend was simply to have a network wide blocker, currently disabled because i was having issues with it, not that disabling blocking helped.
i'll have a look at possibly changing some things as suggested in notes of that github, but that's a project for later(if i figure it out), i was happy enough with its caching functionality.

i believe i included everything relevant when it comes to jellyseerr.

Jellyseerr is on a different docker network called Main, it gets its networking detail from my router who tells it to get its dns from 192.168.0.103(same host its currently on),
however currently im running a bypass for dns to avoid 5-10 second delays that it otherwise would experience, so
dns:

  • 9.9.9.9
  • 8.8.8.8
  • 1.1.1.1
    this bypass in compose file specifically for jellyseerr entirely bypasses the 5-10 second delay.
    and while that's a neat and simple fix, it points at there being a problem.
6

Just a note:

The variable PIHOLE_DNS_ was replaced by FTLCONF_dns_upstreams.

Please check our documentation, specially the Upgrading from v5.x section.

7

i made the change from PIHOLE_DNS to FTLCONF_dns_upstreams
i also experimented a bit with what you stated earlier about port 5053 and 53.
using nc -v from pi-hole i can reach port 5053 but not 53 on 172.23.0.8 on host, 193.168.0.103 5053 is visible as well.
an interesting thing happens when i set FTLCONF_dns_upstreams to 192.168.0.103#5053, i get no reply received on all dns requests in pi-hole, curious. anyways seems pi-hole will only talk to unbound on 172.23.0.8#5053
using nc -v from my client computer to 192.168.0.103 5053 also comes up short, hmmm...
final change is FTLCONF_dns_upstreams: 'unbound#5053' did some reading on your documentation, might as well use unbound instead of ip.

anyways, jellyseerr still suffers delays, also tried FTLCONF_dns_upstreams: '1.1.1.1;8.8.8.8;9.9.9.9' in an attempt to see if unbound was somehow responsible, no change.

Edit: i noticed unbound was throwing network errors for healthcheck
a quick lookup Healthcheck name resolver · Issue #175 · MatthewVance/unbound-docker · GitHub suggests using

healthcheck:
      test: ["CMD", "drill", "@127.0.0.11", "cloudflare.com"]
      interval: 60s
      timeout: 10s

but i have no idea if this amounts to turning the warning off or if it actually did anything, anyways it stopped giving off unhealthy status.

8

That's somewhat strange. It may mean there's something off with your configuration.

Recreating your configuration on my system, using your docker compose (with the exception of your volumes sections) , I get the following results when digging from inside the Pi-hole container:

root@a3697754deff:/# dig +short discourse.pi-hole.net -p 53 @172.23.0.8
157.180.42.82

root@a3697754deff:/# dig +short discourse.pi-hole.net -p 5053 @172.23.0.8
;; connection timed out; no servers could be reached

root@a3697754deff:/# dig +short discourse.pi-hole.net -p 5053 @192.168.1.56
;; reply from unexpected source: 172.23.0.1#5053, expected 192.168.1.56#5053

;; reply from unexpected source: 172.23.0.1#5053, expected 192.168.1.56#5053

;; reply from unexpected source: 172.23.0.1#5053, expected 192.168.1.56#5053

;; connection timed out; no servers could be reached

The only upstream that works is 172.23.0.8 on port 53.
This would also match the expected results, as the ports section of your unbound container reads:

This instructs docker to bind port 53 to the container's ipv4_address: 172.23.0.8 and port 5053 to its host (which is 192.168.0.103 in your case, and 192.168.1.56 in mine).
So there is nothing listening on 172.23.0.8:5053.

Your observation of 172.23.0.8:5053 working from your Pi-hole container, despite your explicit configuration of 172.23.0.8:53, would suggest that container isolation is broken in your setup.

Docker handles container isolation by an elaborated set of iptables/nftables rules.

I wonder whether those may have been compromised somehow in your setup?

9

i ran your command example with the exception of changing the 192.168.1.56 to unbound.
also from pi-hole.

pihole:/# dig +short discourse.pi-hole.net -p 5053 @172.23.0.8
157.180.42.82
pihole:/# dig +short discourse.pi-hole.net -p 53 @172.23.0.8
;; communications error to 172.23.0.8#53: connection refused
;; communications error to 172.23.0.8#53: connection refused
;; communications error to 172.23.0.8#53: connection refused
;; no servers could be reached
pihole:/#

not entirely sure what might cause this sort of behavior...
i cant speak for if its somehow caused by some strange truenas behavior, but i can at least share my docker network definitions so far while i scratch my head at what it might be...

pi-hole network for pi-hole and unbound.

networks:
  dns_net:
    driver: bridge
    ipam:
        config:
        - subnet: 172.23.0.0/16

Main network, that mostly everything follows, inside that network is also wireguard, with containers behind it using network_mode: container:wireguard

---
networks:
  main:
    name: main
    ipam:
        driver: default
        config:
          - subnet: 172.24.2.0/24

not sure what kind of other oddities i possibly could have thats related to networking...
truenas got its own physical network port so probably nothing there, and in front of it is a normal commercial router.

anyway im gonna think this over, but im not sure exactly were to look, that is if i would even spot the mistake.

10

As mentioned, I didn't use your volume definitions. In particular, mapping /opt/unbound/etc/unbound did prevent my unbound container from starting, as it was missing a set of expected configuration files.
In turn, that would imply that you did supply them, suggesting that you run a custom configuration for your unbound.

How does your unbound configuration look like?
Did you perhaps configure your unbound inside the container to listen on port 5053?

If so, your port declaration would map your host's port 5053 to an unoccupied container's port 53, and your unbound container would only be accessible by your Pi-hole.

While that would explain your observation, I fail to see yet how that would contribute to response slow downs of your jellyseer container.

11

if i recall correctly the way its setup was how i was recommended doing it with a guide or something way back, and i have not touched those configs since then.
here's a copy of the config file in question.

here's some settings that might be noteworthy?

    # Listen to for queries from clients and answer from this network interface
    # and port.
    interface: 0.0.0.0@5053
    port: 53

this also looks potentially important with a docker network.

    ###########################################################################
    # SECURITY SETTINGS
    ###########################################################################
    # Only give access to recursion clients from LAN IPs
    access-control: 127.0.0.1/32 allow
    access-control: 192.168.0.0/16 allow
    access-control: 172.16.0.0/12 allow
    access-control: 10.0.0.0/8 allow
    # access-control: fc00::/7 allow
    # access-control: ::1/128 allow