Wow, incredibly cursed DNS/NSS quirk I have ran into.

If a machines hostname is FQDN like test.com and you do a lookup without some local cache involved like systemd-resolved. NSS rules will turn a query for whatever into whatever.com:

# hostname
test.com

# cat /etc/resolv.conf 
nameserver 192.168.181.1

# getent ahosts google
2a00:1450:4009:820::200e STREAM google.com
2a00:1450:4009:820::200e DGRAM  
2a00:1450:4009:820::200e RAW    
216.58.204.78   STREAM 
216.58.204.78   DGRAM  
216.58.204.78   RAW    

# ping google    
PING google(zzz) 56 data bytes
64 bytes from ...1e100.net (2a00:...): icmp_seq=1 ttl=116 time=7.40 ms

I knew having your hostname as a FQDN was a bad idea, but this is a """interesing""" one, Reminds me of a previous run in with DNS Search Paths

@benjojo Part of the glibc res_init() code where it reads the `domain` and `search` parameters from /etc/resolv.conf - if the configured search list ends up empty, it populates it with an entry based on the system hostname (chopping off the first part); search for domain_from_hostname() in resolv/res_init.c

...which works well enough for most systems when they have FQDN hostnames *under* a domain, as opposed to just the bare domain.

So it's not a nsswitch feature as such; it's a feature of Glibc's libresolv which happens to be used by libnss_dns (and deliberately unimplemented by systemd-resolved's nsswitch module from what I remember).

https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_init.c;h=b838dc70642e19353892e2396387211d8fdb61fd;hb=HEAD#l301

(to be honest, although I don't like putting FQDNs in the system hostname in general, it befuddles me in particular when people have just the bare domain as their server name. it's like, "Address: London" in a way)