[BUG] Cannot resolve unqualified name "salt"

Description
When systemd-resolved is used to resolve names on a system, it does not resolve unqualified hosts (hosts without a domain name) into FQDNs using the machine's domain. For example, if a minion's FQDN is minion.mydomain.com, systemd-resolved will fail to resolve salt as salt.mydomain.com on that machine.

Setup

• on-prem machine
• VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

Running in a OVH US VPS on Debian 11 amd64. Saltstack 3005.1 from the Saltstack repos. On this machine I disabled cloud-init, changed the FQDN, and installed salt. Nothing else was changed from the Debian 11 install given by OVH.

Steps to Reproduce the behavior

1. Setup machine that resolves using systemd-resolved, set full FQDN
2. Install Salt minion 3005.1 on machine
3. Start salt-minion

4. Nov 15 21:32:16 some-minion salt-minion[2991]: [ERROR   ] DNS lookup or connection check of 'salt' failed.
   Nov 15 21:32:16 some-minion salt-minion[2991]: [ERROR   ] Master hostname: 'salt' not found or not responsive. Retrying in 30 seconds
   

Expected behavior
Because the resolver cannot be trusted to attempt to resolve with the machine's domain, minions should try resolving both salt and salt.machinedomain.com at startup.

Screenshots
N/A

Versions Report

Salt Version:
          Salt: 3005.1
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 4.0.5
     gitpython: 3.1.14
        Jinja2: 2.11.3
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.0
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: 3.9.7
        pygit2: Not Installed
        Python: 3.9.2 (default, Feb 28 2021, 17:03:44)
  python-gnupg: Not Installed
        PyYAML: 5.3.1
         PyZMQ: 20.0.0
         smmap: 4.0.0
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.4
 
System Versions:
          dist: debian 11 bullseye
        locale: utf-8
       machine: x86_64
       release: 5.10.0-19-cloud-amd64
        system: Linux
       version: Debian GNU/Linux 11 bullseye

Additional context
Related: https://github.com/systemd/systemd/issues/2514

See above link, it is apparently the correct functionality for the resolver not to resolve unqualified names.

Start at the salt-minion startup path that performs the master hostname lookup, using the reported systemd-resolved behavior on Debian 11 as the reproduction case. Confirm how unqualified names are resolved and verify that startup attempts both the configured name and the machine-domain form; the issue is done when the minion connects in this environment without the reported lookup failure.