I was using /bin/hostname to retrieve the domain(s) and/or FQDN(s) of my machines for decades without a hassle.
How the story began:
Now ubuntu discontinued the old debian-based installer with 20.04. So I had to convert my preseeded installs to the new subiquity-based installer. Unfortunaltely, this installer is still missing functionality which was available with the old d-i based installer. In addition, there are new bugs in the new installer (specifically curtin).
Thus, to track down those bugs, I had to install snapcraft, which in turn requires LXD.
This broke “hostname --all-fqdns” since LXD creates lxdbr0 bridge and /bin/hostname uses reverse-lookups on all interfaces to find the dns domains.
Before installing LXD, “hostname --all-fqdns” (correctly) reported “h730.real.do.main” for this host.
After installing LXD, “hostname --all-fqdns” reports "h730.real.do.main h730 h730 ".
That is, in addition to the (correct) FQDN, two more “FQDNs” are reported, which completely miss any domain part and therefore are no FQDNs at all.
Over there at https://github.com/canonical/lxd/issues/12445 I was told this is an issue with my local setup.
I disagree with this. Before installing LXD, /bin/hostname worked perfectly in this local setup. Installing a package should not break standard tools like /bin/hostname.
When LXD fiddles with network setup, then LXD-developers should coordinate with developers of network utilities to avoid breakage of those utilities. In this case, /bin/hostname should probably ignore the bridge that is created by LXD.