(Debian maintainer for gdnsd here)

Since this bug was filed, gdnsd acquired autopkgtests, that among other things test that the package works in a clean container. In Debian, it does, and 3.5.2-1 has migrated to bullseye and will be part of that release. In Ubuntu, it does not because of this bug, which has blocked the migration of 3.x versions to hirsute. I was asking in #ubuntu-release earlier today about how to handle this, suggesting to either remove the package from Ubuntu, or force-badtest this; a lot of ideas were mentioned, but I don't think we came into any conclusion. 

It is worth noting that this is not a new issue; 2.4.2-1 (in hirsute) is already affected and fails to install by default on Ubuntu systems. autopkgtests that were added in 3.5.2-1 just reveal this underlying issue. (Thanks to Colin Watson for actually testing this on a hirsute LXC).

There is a lot to unpack here:

* This behavior is triggered by Ubuntu shipping with a resolver (systemd-resolved, AIUI) listening on 127.0.0.53:53 on the default install. (This is not the case in Debian, so this issue is Ubuntu-specific). I suspect this is one of a class of issues of differing default installs breaking unrelated packages, but more pronounced in this case because a) this package has autopkgtests that test that it actually works :) b) the conflict is with a very common default install (all Ubuntu systems, AIUI). I haven't checked other (authoritative) DNS servers, but I did mention on IRC a random example of how "apt install tinysshd" would fail on an Ubuntu install that has openssh-server installed, which from what I gathered is the case by default in Ubuntu cloud images (cloud images being a much more limited example, though).

* An authoritative server listening on localhost is not a very helpful default configuration as it's unlikely to be used that way. Standard practice in Debian systems has been that "apt install xyz" results in a package that's useful out of the box, and for daemons, we've interpreted that as "listens by default to the network with a semi-working config", and have for years applying that to the archive. If one installs nginx or apache2, they expect it to listen on :::80. Moreover, no real attempts have been made at the distribution level of dealing with port conflicts in the same way we've dealt with filesystem conflicts; if one installs apache2 after they've installed nginx, apache2.service will fail. Some packages do have code to handle this (e.g. in the example above, Dropbear disables itself if it finds OpenSSH on the system) but it's not something standardized at the distribution level. So I hope this explains a bit why I've made the decision in the first place for the gdnsd package to start by default and listen by :::53 in Debian systems (also the upstream default by the way).

* As a side-note: a particular complexity with DNS servers is that traditionally port 53 has been shared by resolvers and authoritative servers, with daemons like bind9 supporting both. This has changed in the modern Internet, with admins expected to run separate configs for each purpose, and new generation servers having even separate daemons/codebases for each purpose (pdns/pdns-recursor, knot/knot-resolver, nsd/unbound etc.). Unfortunately, at the protocol and port assignment level (IETF/IANA), port 53 remains shared between those two different purposes. This plays into this bug by gdnsd having to use the same port as resolved while providing entirely different, non-overlapping set of functionality.

* Interface enumeration and hotplug tracking etc. as was suggested above is a tall order for upstreams and something that can be the source of its own problems either in the upstream code, or at the system level (e.g. bind9 shipping if-up.d and ip-up.d snippets to restart bind9 when interfaces in the system change). It is also not something that we require or recommend for any other daemon anyway. Notably, this used to be supported by gdnsd, and removed in 2.2.0 with https://github.com/gdnsd/gdnsd/commit/00213f7307500cc40f03bbaf37d57f2ba5714399 for (what upstream thought and I concur) were good reasons.

* All that said, while the underlying situation is non-ideal, at the end of the day, it is what it is and largely out of my control. While I'm still not entirely convinced this is the way to go, to avoid these complexities I've been exploring shipping the package with a default configuration that listens just to localhost, despite that being somewhat unusual in Debian. However, even that is complicated: given that the package was not shipping a config file before, shipping a config now with "listen => localhost" would basically break all existing deployments that haven't added a config (but have added zonefiles), so not something I would do lightly, and definitely not while in a Debian freeze. I've been in touch with upstream on handling this in a more coordinated manner, and they've committed https://github.com/gdnsd/gdnsd/commit/6958918936d528d3daa6366036fbf44a02cbb234, which adds a future deprecation warning for a non-listen config, and is part of 3.5.2-1. Including this version in hirsute would help towards the goal of addressing this in the future in a more graceful way :)

All in all: this is a bit of a complicated bug and there isn't a very easy or short-term fix. I would recommend force-badtesting to let a new version migrate to hirsute. In future (likely post-Debian freeze) uploads I intend to disable the tests under Ubuntu in the short-term, and possibly migrate to a localhost-by-default configuration in the 4.x series of releases. Other ideas/suggestions/workarounds/etc. welcome!