coredns role: systemd unit 'failed', port 53 not listening

[yakari007]

Summary

Deployed a VM with the coredns service role attached (default/empty
config - no port/forwarders override submitted), on the Ubuntu 24.x
"with PlusClouds Service" image. After SSH login succeeded, systemctl is-active coredns reported failed for the full 300s verification
window, and port 53 refused TCP connections outright (Connection refused, not a timeout - the port isn't bound at all).

Repro

POST /leo/iaas/virtual-machines/create-wizard with
service_roles: {"coredns": {"config": {}}} against the Ubuntu 24.x "with
PlusClouds Service" image, then after boot:

systemctl is-active coredns   # -> failed
exec 3<>/dev/tcp/127.0.0.1/53   # -> Connection refused

The VM was deployed and torn down automatically as part of the test run,
so the live VM/journalctl -u coredns output is gone - filed from the
test's captured output, not a live inspection. Note bind9 (a similar
caching/forwarding DNS resolver role, also tested in the same run) passed
cleanly, so this doesn't look like a host-level port-53 conflict or
general DNS-role problem - looks specific to coredns.

Found via leo4.tester's iaas-service-roles automated test scenario.

[yakari007]

Investigated but did not find a reproducible code-level bug, so no change made yet.

Downloaded the actual v1.14.6 release asset (coredns_1.14.6_linux_amd64.tgz), confirmed it contains exactly the single coredns binary the role assumes, rendered the Corefile with the role's exact defaults, and ran the real binary against it (tested on an alternate port to avoid colliding with this machine's own resolver; it bound and served cleanly, no crash). The one thing I couldn't verify without a disposable VM is whether AmbientCapabilities=CAP_NET_BIND_SERVICE in the systemd unit actually grants the non-root coredns user permission to bind :53 in your test image — that's the standard/documented systemd pattern for this and should work, but I don't have root on a throwaway VM to confirm empirically. If this reproduces again, journalctl -u coredns from a live VM (specifically checking for a permission-denied bind error) would confirm or rule that out immediately.