3 ms·

My favourite part in Docker is what if you have 127.0.0.1 configured as your resolver (eg you are running Unbound) then Docker helpfully configure containers to

My favourite part in Docker is what if you have 127.0.0.1 configured as your resolver (eg you are running Unbound) then Docker helpfully configure containers to use 1.1.1.1 instead. Thanks, my ass, and give back my time trying to diagnose [a container with no diagnostic tools, because it's a lightweight container] why it can't connect to someservice.on.my.lan.

judge2020 3y ago
Wouldn't 127.0.0.1 be the loopback for the container itself? So you'd need to set the DNS to the gateway IP or dynamically by resolving `host.docker.internal` (assuming `--add-host=host.docker.internal:host-gateway`)
- justsomehnguy 3y ago
  Yes. > So you'd need to set the DNS to the gateway IP This is the least friction way. Run your own resolver there to resolve names for containers, forward to the host's loopback for everything else. > or dynamically by resolving `host.docker.internal` Resolving. Name. Of the DNS server. Right?
  - judge2020 3y ago
    I mean dynamically as in a startup script that resolves that hostname, then updates the resolver to the IP it returns.
    - justsomehnguy 3y ago
      Ah. This would require adding a script to the image itself, for each image. No go.
    - watermelon0 3y ago
      Doesn't even have to be dynamic, Docker engine knows the IP of the host, so it can just directly configure `/etc/resolv.conf` with it.
      - marginalia_nu 3y ago
        Might not bind on the external interface though.
- fuzzy2 3y ago
  No, that won't work if the resolver is listening on 127.0.0.1, which will most likely be the case. Docker also has special handling for systemd-resolved: if resolv.conf points at 127.0.0.53, it will use the managed resolv.conf located in /run.
kccqzy 3y ago
Nobody should ever mess with a system's resolver settings. I've recently had to debug a bug with a container (probably not Docker itself) unable to reach the internet. It turns out the machine is behind a NAT64 and has IPv6 addresses only, yet something in the container helpfully reconfigures the resolver to be 8.8.8.8 which of course is unreachable.
- Bluecobra 3y ago
  Ubuntu on WSL is really bad about this and you have to end up using chattr to make /etc/resolv.conf immutable to prevent it from fiddling around with it. Really makes you appreciate Slackware/FreeBSD.
- patrakov 3y ago
  Running anything on NAT64 without 464XLAT is a broken setup.
  - deleted 3y ago
    [deleted]
  - raffraffraff 3y ago
    I have to admit with some embarrassment that I've never deployed an ipv6-only infrastructure, so I've never had to figure this stuff out. 25+ years doing Linux/infra and it's still arcane and avoidable. I don't even know what 464XLAT is, and have to look it up. > 464XLAT allows private IPv4 clients to connect to an IPv4 host over an IPv6 network. It only supports client-server, not peer-to-peer communication or inbound connections. ...A brief description for anyone else who didn't know.

judge2020 3y ago

Wouldn't 127.0.0.1 be the loopback for the container itself? So you'd need to set the DNS to the gateway IP or dynamically by resolving `host.docker.internal` (assuming `--add-host=host.docker.internal:host-gateway`)

justsomehnguy 3y ago
Yes. > So you'd need to set the DNS to the gateway IP This is the least friction way. Run your own resolver there to resolve names for containers, forward to the host's loopback for everything else. > or dynamically by resolving `host.docker.internal` Resolving. Name. Of the DNS server. Right?
- judge2020 3y ago
  I mean dynamically as in a startup script that resolves that hostname, then updates the resolver to the IP it returns.
  - justsomehnguy 3y ago
    Ah. This would require adding a script to the image itself, for each image. No go.
  - watermelon0 3y ago
    Doesn't even have to be dynamic, Docker engine knows the IP of the host, so it can just directly configure `/etc/resolv.conf` with it.
    - marginalia_nu 3y ago
      Might not bind on the external interface though.
fuzzy2 3y ago
No, that won't work if the resolver is listening on 127.0.0.1, which will most likely be the case. Docker also has special handling for systemd-resolved: if resolv.conf points at 127.0.0.53, it will use the managed resolv.conf located in /run.

kccqzy 3y ago

Nobody should ever mess with a system's resolver settings. I've recently had to debug a bug with a container (probably not Docker itself) unable to reach the internet. It turns out the machine is behind a NAT64 and has IPv6 addresses only, yet something in the container helpfully reconfigures the resolver to be 8.8.8.8 which of course is unreachable.

Bluecobra 3y ago
Ubuntu on WSL is really bad about this and you have to end up using chattr to make /etc/resolv.conf immutable to prevent it from fiddling around with it. Really makes you appreciate Slackware/FreeBSD.
patrakov 3y ago
Running anything on NAT64 without 464XLAT is a broken setup.
- deleted 3y ago
  [deleted]
- raffraffraff 3y ago
  I have to admit with some embarrassment that I've never deployed an ipv6-only infrastructure, so I've never had to figure this stuff out. 25+ years doing Linux/infra and it's still arcane and avoidable. I don't even know what 464XLAT is, and have to look it up. > 464XLAT allows private IPv4 clients to connect to an IPv4 host over an IPv6 network. It only supports client-server, not peer-to-peer communication or inbound connections. ...A brief description for anyone else who didn't know.