host's fqdn not resolving

[Stuart McGraw]

On 8/21/22 03:10, Chris Green wrote:
> On Sat, Aug 20, 2022 at 05:41:12PM -0600, Stuart McGraw wrote:
> [snip description of problem]
>>
>> Surely with systemd-resolved, avahi, mdns, nsswitch,conf, /etc/hosts
>> and probably a half dozen other pieces involved, there must be some
>> magical configuration change that can achieve this?
>>
>> I have tried (really just stabs in the dark) setting:
>>    /etc/systemd/resolved.conf: Domains=home
>> and:
>>   /etc/avahi/avahi-daemon.conf: domain-name=home
>> but neither had the desired effect.
>>
> The default set-up using systemd, avahi and so on is a *mess*.  It's
> possibly OK until you have a large[ish] LAN with a lot of systems on it.
> 
> I simply disable systemd-resolved, remove avahi and run dnsmasq on one
> of my systems, everything then works as expected and you don't have to
> use (unnecessary) .local or .home suffixes on names.  You can simply
> use the name of each system to refer to it, or the FQDN if you have
> a domain name for the LAN.

That's pretty much what I do with the machines on my local network that
have a long lifetime.  But for ephemeral VMs (and sometimes hardware)
that get an arbitrary ip address via dhcp, I don't want to have to update
the dns server machine's database or mess around with dynamic updates.
I also have lots of admin scripts that I want to run on these ephemeral
machines that have names of the form "$HOST.home" in them that would be
a pain to change.

So it seems to me the straightest way forward would be to configure an
ephemeral machine to treat it's own hostname "xxx" and "xxx.home" the
same, without any reliance on the network dns server.  (Well, I guess
it would not be precisely the same as "xxx" would return 127.0.1.1 and
"xxx.home" would return the dhcp ip address; or maybe both one or the
other, not sure; but a dns lookup not finding "xxx.home" breaks things.)