4 ms·
Running on 127.0.0.53 isn't a systemd-resolved exclusive magic trick, you can just configure unbound to do the same thing.
by eqvinox 5mo 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 5mo agoNot 127/8
- eqvinox 5mo ago?
- justsomehnguy 5mo agoYou 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 agoWant 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".
- justsomehnguy 5mo agoYikes. Container resolving is still broken though.
- eqvinox 5mo agoNot if your containers are L3 routed through the host ;) (Or did you mean resolving the names of the containers? That'd be handled through unbound-control local_data)