0.0.0.0 works sometimes, it depends entirely on the networking library.
The problem is the return path. Some libraries send UDP responses from the wrong IP when you bind 0.0.0.0. Which is silly. They use the first IP they can discover from the system for all UDP responses.
UDP only works if you reply from the fly-global-services IP. So if it works for you, it will continue to work. But it’s actually somewhat rare that libraries do the right thing.
Looks like DNSMASQ/PiHole works correctly , without fly-global-services. Nice.
On the other hand, a socat echo server (udp port 54, just as an example) doesn’t work out-of-the-box:
# Doesn't work.
# Incoming packets are from 172.19.65.179, which happens to be the 2nd address assigned to eth0
# Socat naively responds from 172.19.65.178, which is incorrect (and the 1st address of eth0).
socat -v UDP-LISTEN:54,fork,bind=0.0.0.0 exec:'/bin/cat'
socat -v UDP-LISTEN:54,fork,bind=fly-global-services exec:'/bin/cat'
socat - UDP:app-name.fly.dev:54
Anyhow, maybe the fact that the issue is on the return path and some libs handle it correctly is worth documenting.
Right now this also comes with a bump in kernel version (from 5.12.2 to 5.15.93, but I might as well make it 5.15.98 since that’s the latest 5.15). Previous compilations of 5.15 have been deployed to a few servers as a test, but not many.