Drone dns resolving not using local mdns any more

Drone Support
1

I have an ubuntu 22.04 test box here xeon.local with gitea/drone/drone-runner on it as containers. Been working fine for a while, but just today authentication back through gitea failed.

Starting from the Welcome screen, clicking Continue redirects to the gitea container on port 3000. That works, and I log in as usual. But the return to Drone results in

Post "http://xeon.local:3000/login/oauth/access_token": dial tcp: lookup xeon.local on 8.8.8.8:53: no such host

image
Nothing has changed (that I know of). resolvers are untouched
/etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad
search .

/etc/systemd/resolved.conf

#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

all commented out as usual.

2

Just did a completely clean fresh install of gitea/drone/drone-runner

Same thing. Clicking Continue redirects to gitea fine. Able to log in there, click the Authorize button. Back to Drone and fail …

3

OK, weird. The test xeon.local system only has the standard docker network defined, as expected

test@xeon:/stuff/gitea$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
85ba1ea7339d   bridge    bridge    local
886decce60a5   host      host      local
2da874a32994   none      null      local

I created a dedicated network gitea and restart the gitea/drone/drone-runner containers attached to that network with --network gitea

NOW name resolution works.

4

And as a test, removed the --network gitea from the startup of the containers, and lo, name resolution fails.

So when attached to the bridge network, name resolution no longer works. When attached to the gitea network, it’s all good.