3 ms·

> My recommendation for DNS - on servers - would be to install unbound locally and use that And now your developers are running around and cursing you because

> My recommendation for DNS - on servers - would be to install unbound locally and use that And now your developers are running around and cursing you because nothing works anymore. Because Docker silently retargets the interna Docker resolver to 8.8.8.8 if it sees 127.0.0.1 as a resolver address on the host. Because people who wrote Docker have no fucking clue how the system works. NB: see https://news.ycombinator.com/item?id=47441785 https://news.ycombinator.com/item?id=47441785 to solve the Docker issue with a local resolver. > It's not great for clients since it doesn't deal well with frequently changing network connectivity This is is something Linux specific I guess, I run Unbound locally on my Windows laptops for years and never had a problem which would require the Unbound restart. > which implies flushing all cached data It doesn't really matters in 2026. Just look in your cache and note the default TTLs for like 90% of records.

zaphirplane 6mo ago
Some docker issues archaeology says that there was tension between docker team and redhat / systemd
- burnt-resistor 6mo ago
  That's probably why podman exists.
  - ChocolateGod 6mo ago
    It is why Podman exists.
- justsomehnguy 6mo ago
  Yes? RH wanted to control the stack and Docker was the thing what sidelined RH to a mere distro provider. And don't forget about RH dips into OpenStack at that time.
eqvinox 6mo ago
Running on 127.0.0.53 isn't a systemd-resolved exclusive magic trick, you can just configure unbound to do the same thing.
- justsomehnguy 6mo ago
  Not 127/8
  - eqvinox 6mo ago
    ?
    - justsomehnguy 5mo ago
      You need to configure your resolver to anything but 127.0.0.0/8 to not to trigger Docker automatic "help". Most of the time local resolver is bound to 127.0.0.1 just because it shouldn't be available from the network and because this is how it's always done. The problem is what Docker actually silently break things because it's devs are too good to bother, the same thing you note about systemd devs. Hell, it was easier to just provide internal Docker resolver on a some network Docker uses internally by default for the NAT shenanigans - but Docker devs 'knew better' and instead made it to point to a 3rd-party absolutely not related service which brokes local resolution on the containers.
      - eqvinox 5mo ago
        Want to know a really cursed dirty little magic trick? (as root:) ip route add table local local 8.8.8.8/32 dev lo echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind cat <<EOF >/etc/unbound/unbound.conf.d/steal-8.8.8.8.conf server: interface: 8.8.8.8 EOF service unbound restart (before anyone asks: you don't just go add 8.8.8.8/32 as an address on lo because then that's a valid source address the system might use to send traffic out. Not having it as an actual address is the point of this trickery. Also this will work with most DNS caches, doesn't need to be unbound.) And to be clear: I said "cursed dirty" and I mean "cursed dirty".

zaphirplane 6mo ago

Some docker issues archaeology says that there was tension between docker team and redhat / systemd

burnt-resistor 6mo ago
That's probably why podman exists.
- ChocolateGod 6mo ago
  It is why Podman exists.
justsomehnguy 6mo ago
Yes? RH wanted to control the stack and Docker was the thing what sidelined RH to a mere distro provider. And don't forget about RH dips into OpenStack at that time.

eqvinox 6mo ago

Running on 127.0.0.53 isn't a systemd-resolved exclusive magic trick, you can just configure unbound to do the same thing.

justsomehnguy 6mo ago
Not 127/8
- eqvinox 6mo ago
  ?
  - justsomehnguy 5mo ago
    You need to configure your resolver to anything but 127.0.0.0/8 to not to trigger Docker automatic "help". Most of the time local resolver is bound to 127.0.0.1 just because it shouldn't be available from the network and because this is how it's always done. The problem is what Docker actually silently break things because it's devs are too good to bother, the same thing you note about systemd devs. Hell, it was easier to just provide internal Docker resolver on a some network Docker uses internally by default for the NAT shenanigans - but Docker devs 'knew better' and instead made it to point to a 3rd-party absolutely not related service which brokes local resolution on the containers.
    - eqvinox 5mo ago
      Want to know a really cursed dirty little magic trick? (as root:) ip route add table local local 8.8.8.8/32 dev lo echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind cat <<EOF >/etc/unbound/unbound.conf.d/steal-8.8.8.8.conf server: interface: 8.8.8.8 EOF service unbound restart (before anyone asks: you don't just go add 8.8.8.8/32 as an address on lo because then that's a valid source address the system might use to send traffic out. Not having it as an actual address is the point of this trickery. Also this will work with most DNS caches, doesn't need to be unbound.) And to be clear: I said "cursed dirty" and I mean "cursed dirty".