Cannot access RPi server (node js) from a browser using hostname

Question

I set hostname of my Raspberry Pi 3 to "myhost", avahi is running ok (systemctl confirmed, to run with myhost.local).

From my Ubuntu WSL on Windows 10 I can ssh to the RPi with ssh pi@myhost and that works, but ssh [email protected] does not. Similarly, from Windows cmd, nslookup myhost gives correct IP, but nslookup myhost.local says Non-existent domain. Why? Every tutorial on the net says to ssh with ".local".

In any case, I started a simple web server in node.js:

const http = require('http');

const hostname = '192.168.1.25';   
const port = 3000;

const server = http.createServer((req, res) =>   {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello World');
});

server.listen(port, hostname, () =>    {
    console.log(`Server running at http://${hostname}:${port}/`);
});

And when I open Firefox and type http://192.168.1.25:3000/ - it works, I see "Hello World". But if I type http://myhost:3000 or http://myhost.local:3000/ - it doesn't work (no server found).

However, from Ubuntu console on the same Windows, both wget 192.168.1.25:3000 and wget http://myhost:3000 - work.

Windows resolves the domain correctly, i.e. nslookup myhost gives the correct IP, so why Firefox (or Chrome) cannot connect??

Answer 1

There are mainly three services used for name resolution in a network, in particular together with MS Window$:

1. DNS (Domain Name Service) the main name service all over the world, supported by any internet provider. It resolve hierarchical organized names like raspberrypi.stackexchange.com.
2. mDNS (multicast DNS) an auto configuring name resolution service, but only usable on one local network with same ip address range (broadcast domain). mDNS cannot pass router. It resolve names within the reserved DNS domain .local, e.g. raspberrypi.local.
3. LLMNR (Link-Local Multicast Name Resolution) a service made by Microsoft and supported by Vista, Windows Server 2008, Windows 7, Windows 8, Windows 10 and systemd-networkd. It is also only usable on a broadcast domain. It resolve the simple hostname, e.g. raspberrypi.

It is difficult to examine with your description what services in what combination is running on what device. But to shine a light on this, I have made some tests so you may be able to understand how your name resolution (should) work(s).

I have a Laptop as testing device, configured with systemd-networkd, because that supports all services. The tested Raspberry Pi 4B is setup with the default Raspberry Pi OS (32-bit) Lite 2020-08-20, updated with sudo apt update && sudo apt full-upgrade && sudo reboot at 2020-09-26. Both are connected wired to my local network with router and switches.

Test for DNS

Setting on the Laptop. You get only an address resolution for google.com, not for raspberrypi.local and raspberrypi.

laptop ~$ cat /etc/systemd/network/04-wired.network
[Match]
Name=ens1

[Network]
LLMNR=no
MulticastDNS=no
DHCP=ipv4

[DHCP]
UseDNS=yes

laptop ~$ resolvectl status ens1
Link 2 (ens1)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 84.200.69.80
         DNS Servers: 84.200.69.80
                      84.200.70.40

laptop ~$ resolvectl query google.com
google.com: 216.58.206.14                      -- link: ens1
            2a00:1450:4001:81f::200e           -- link: ens1

-- Information acquired via protocol DNS in 10.4583s.
-- Data is authenticated: no
laptop ~$ resolvectl query raspberrypi.local
raspberrypi.local: resolve call failed: No appropriate name servers or networks for name found
laptop ~$ resolvectl query raspberrypi
raspberrypi: resolve call failed: No appropriate name servers or networks for name found

Test for mDNS

Setting on the Laptop. You only get an address resolution for raspberrypi.local, not for google.com and raspberrypi.

laptop ~$ cat /etc/systemd/network/04-wired.network
[Match]
Name=ens1

[Network]
LLMNR=no
MulticastDNS=yes
DHCP=ipv4

[DHCP]
UseDNS=no

laptop ~$ resolvectl status ens1
Link 2 (ens1)
      Current Scopes: mDNS/IPv4
DefaultRoute setting: no
       LLMNR setting: no
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

laptop ~$ resolvectl query google.com
google.com: resolve call failed: No appropriate name servers or networks for name found
laptop ~$ resolvectl query raspberrypi.local
raspberrypi.local: 192.168.50.60               -- link: ens1

-- Information acquired via protocol mDNS/IPv4 in 59.9ms.
-- Data is authenticated: no
laptop ~$ resolvectl query raspberrypi
raspberrypi: resolve call failed: No appropriate name servers or networks for name found

Test for LLMNR

Setting on the Laptop. You do not get any address resolution if using the default Raspberry Pi OS image. You get a response for raspberrypi if configured for LLMNR.

laptop ~$ cat /etc/systemd/network/04-wired.network
[Match]
Name=ens1

[Network]
LLMNR=yes
MulticastDNS=no
DHCP=ipv4

[DHCP]
UseDNS=no

laptop ~$ resolvectl status ens1
Link 2 (ens1)
      Current Scopes: LLMNR/IPv4
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

laptop ~$ resolvectl query google.com
google.com: resolve call failed: No appropriate name servers or networks for name found
laptop ~$ resolvectl query raspberrypi.local
raspberrypi.local: resolve call failed: No appropriate name servers or networks for name found
laptop ~$ resolvectl query raspberrypi
raspberrypi: resolve call failed: 'raspberrypi' not found

As expected, the default Raspberry Pi OS image does not support LLMNR out of the box. I don't know why your RasPi is responding to a single myhost. Do you use a default Raspberry Pi OS on it? To verify it, I have reconfigured my RasPi to systemd-networkd and enabled LLMNR on it. The Result is:

laptop ~$ resolvectl query raspberrypi
raspberrypi: 192.168.50.60                     -- link: ens1

-- Information acquired via protocol LLMNR/IPv4 in 110.0ms.
-- Data is authenticated: no

Of course you can combine all services but it doesn't make troubleshooting easier.