0

I have a Windows network with the default networking (no active directory configured). I am able to reference other hosts, including a CEntos Stream 9 linux box, by host name.

I want to be able to reference Windows machines on the Centos Stream 9 system by name, since some of the WIndows machines I mount file systems from use DHCP, so I prefer names for numeric IPs that change. My mounts using the IP names work.

I cannot resolve any of the Windows machine from linux - nslookup and ping fail. It is checking the DNS server (and resolves non-local names without difficulty).

Seeking info on how to get the Centos Stream 9 box to resolve Windows names on networks not using AD.

Did a lot of looking - all solutions I found seemed to be for an active directory configuration which I am not running.

Improve this question

1 Answer 1

Reset to default
0

Ignoring Active Directory, there are four other mechanisms for "automatic" hostnames:

  1. The Windows machine provides its hostname as part of DHCP lease request, and your DHCP server registers it in your internal DNS.

  2. The CentOS machines use mDNS (through avahi-daemon or through systemd-resolved) to look up the hostname via UDP broadcast packets.

  3. The CentOS machines use Microsoft LLMNR (through systemd-resolved) to look up the hostname via UDP broadcast packets.

  4. The CentOS machines use NetBIOS Name Service (through Samba's nmbd) to look up the hostname via UDP broadcast packets.

Use Wireshark to find out what kind of response Windows is successfully receiving, then configure CentOS to do the same.

Option 1 is commonly implemented by home wifi routers. Out of the three broadcast-based protocols, mDNS is generally preferred, though it only works under the .local domain – which you must add manually most of the time (e.g. mount -t smb3 //winpc.local/media).

All of the non-DNS options involve adding a hosts lookup module to the CentOS /etc/nsswitch.conf (mdns_minimal, resolve, wins).

Improve this answer
3
  • Option 4 is becoming historical, as NetBIOS is strongly deprecated by Microsoft because of design-level security vulnerabilities that allowed the spread of the WannaCry ransomware in 2017. By default, up-to-date versions of Windows 10 and above will automatically disable NetBIOS if it hasn't been used in the first few weeks after installation. It can still be manually enabled, but there is a very strong recommendation from security researchers that you should not do that (unless you absolutely have to, and have secured your network in some other way). Commented Jan 31 at 7:23
  • @telcoM: Design-level? Commented Jan 31 at 7:39
  • Not an implementation-specific flaw, but one that is inherent in the protocol specification: fixing it would require changing the protocol in ways that would necessarily break compatibility with existing implementations. The effort required in fixing the old NetBIOS/SMBv1 protocol would basically be same as the effort required in throwing away the old protocol and getting a new one adopted. Also, NetBIOS/SMBv1 is unnecessarily complex because of accumulated enhancements and workarounds. Thus, the deprecation of NetBIOS and SMBv1 and the strong recommendation to use SMBv2 and above instead. Commented Jan 31 at 8:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.