Bug: New DNS not resolving #2442
Comments
|
@qdm12 is more or less the only maintainer of this project and works on it in his free time.
|
|
If you comment out |
Update: So this worked, but removing Update 2: Still receiving timeout / no route DOT errors when I set up a basic gluetun + linuxserver/firefox container setup. Guess that means it's a VPN / Debian 12 error/conflict. If I have time I'll troubleshoot those variables. Enabling/disabling UFW in Debian had no effect. |
|
funny, i switched my wireguard custom config from torguard to protonvpn today, and also noticed the same DoT messages. I do have port forwarding on to let it figure itself out with protonvpn NAT, lets qbittorrent connect with UPnP/NAT I assume since torrents resolve hostnames (when they didnt before) and i get a solid connected green with good upload/download activity. |
|
To be fair, it's fine if it happens from time to time. Unbound would simply not log these out. If your resolution would mostly not work that would be problematic, but it seems fine. Anyway, resolvers (OS, browser etc.) usually retry on a dns error. I was thinking about logging these errors at the debug level, but in the end I didn't notice it happening much on my end within 24h so left it to warnings. Maybe it's worth having them at the debug level 🤔 |
|
So I had to disable Pi-Holes DNSSEC validation, that was the error I made. After a few minutes DNS started resolving, even with the timeout / no route to host errors appearing in the Gluetun log |
|
I'm likewise having this issue and would appreciate any guidance. Although my case is a bit different, as I'm running Gluetun as a sidecar container in K8s. What is especially odd is that I'm able to Edit: I've been able to workaround it by rolling back to the |
I am also having this issue and the rollback also works for me. compose.yaml
services:
gluetun:
cap_add:
- NET_ADMIN
container_name: gluetun
devices:
- /dev/net/tun:/dev/net/tun
environment:
- SERVER_COUNTRIES=👀
- VPN_SERVICE_PROVIDER=surfshark
- VPN_TYPE=wireguard
- WIREGUARD_ADDRESSES=👀
- WIREGUARD_PRIVATE_KEY=👀
- HEALTH_TARGET_ADDRESS=127.0.0.1:9999
image: ghcr.io/qdm12/gluetun:v3.39
labels:
- traefik.enable=true
- traefik.http.routers.qbittorrent.entryPoints=webSecure
- traefik.http.routers.qbittorrent.rule=Host(`qbittorrent.👀`)
- traefik.http.services.qbittorrent.loadBalancer.server.port=8080
- traefik.http.routers.qbittorrent.service=qbittorrent
networks:
- gluetun
restart: unless-stopped
volumes:
- ./gluetun:/gluetun |
|
encountered this issue as well this week. Was trying various different VPNS (proton, PIA, Surfshark). Then messing with However, reverting back to 3.39.1 version of gluetun container solved all issues. |
|
Is this fixed yet? been a sec and this makes the program worthless. |
I know it doesn't solve the issue, but you can set the |
I just disabled AdGuard Home DNSSEC, restarted Gluetun and it's working perfectly now (so far) |
|
Revisited today due to the latest v3.4. Disabled specifying |
|
Closed issues are NOT monitored, so commenting here is likely to be not seen. This is an automated comment setup because @qdm12 is the sole maintainer of this project |
and others
Is this urgent?
Yes
Host OS
Debian 12
CPU arch
x86_64
VPN service provider
AirVPN
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2024-08-25T07:04:32.409Z (commit 01fa993)
What's the problem 🤔
The new DNS system doesn't seem to be resolving.
Bizarrely my P2P client could make some connections. My shadowsocks client that uses Gluetuns DNS however couldn't resolve any addresses. Reverting to v3.39 resolves issue (Unbound).
Running
Share your logs (at least 10 lines)
Share your configuration
The text was updated successfully, but these errors were encountered: