0

On a Ubuntu 16.04 computer on the local network I can ping any other computer on the network by using "ping hostname" or by using "ping hostname.local". However, on another computer I just installed Ubuntu 18.04 on, "ping hostname" yields "Name or service not known" yet "ping hostname.local" still works.

Both computers need to be configured with static IPs.

In this specific circumstance I need "ping hostname" to work. I do not know what is so special about the 16.04 machine that makes it able to resolve local hostnames without the .local.

Does anyone have any ideas?

Here is my netplan file on the device. It may shed some light on the situation.

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
  ethernets:
       enp3s0:
          dhcp4: no
          addresses: [192.168.1.19/24]
          gateway4: 192.168.1.1
          nameservers:
             addresses: [192.168.1.1, 8.8.8.8]

Below are results of systemd-resolve --status on the 18.04 machine

Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 3 (enp4s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no


Link 2 (enp3s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.1
                      8.8.8.8
          DNS Domain: ~.

I tried adding a local search domain but it did not help

Hostnames are not defined in the 16.04 /etc/hosts. It is resolving the hostnames through my router somehow. If I connect a brand new device to my network the 16.04 machine can access it immediately via its hostname and the 18.04 machine can access it through hostname.local

Any suggestions?

Blaine141
  • 3
  • So (the plot thickens), you have a router that is providing the DNS service, and, I assume, also the DHCP service. I shall assume that that router is located at 192.168.1.1. Then, what is the output of either dig @192.168.1.1 hostname or host hostname 192.168.1.1 or (read https://unix.stackexchange.com/questions/20784/how-can-i-resolve-a-hostname-to-an-ip-address-in-a-bash-script). And. if port 127.0.0.53 is active (systemd resolved): dig @127.0.0.53 hostname or similar. –  Jul 07 '20 at 04:22
  • Note that the domain set (probably in /etc/resolv) for the 18.04 computer is reported to be DNS Domain: ~. (Is that what you want?). –  Jul 07 '20 at 04:27
  • I'm not sure what the domain: ~. means. What I want is to be able to type "hostname" for any device on the network instead of "hostname.local". All of your name resolution things you suggested earlier worked fine but the 127.0.0.53 – Blaine141 Jul 07 '20 at 04:29
  • Related: https://unix.stackexchange.com/questions/442598/how-to-configure-systemd-resolved-and-systemd-networkd-to-use-local-dns-server-f –  Jul 07 '20 at 04:29
  • Are both computers failing to resolve in 127.0.0.53 or only the 18.04 one? If that is failing, then the systemd resolved stub server is failing to work. Please read the link I provided on the previous post. –  Jul 07 '20 at 04:31
  • I understand what you want: to ping computer1823 to work, not ping computer1823.local. The question is: what (of all things) is failing? –  Jul 07 '20 at 04:33
  • I do not see how the post you linked is related to this as I do not have a domain for all the hostnames. Also, the 16.04 computer is set up very differently. Static IP was set up in /etc/network/interfaces and the nameserver was set by putting nameserver 192.168.1.1 in the resolv.conf. – Blaine141 Jul 07 '20 at 04:39
  • We are not understanding each other. I am not assuming you have a domain, nor that you need one. About the ~. read in man systemd-resolved. If you do have a nameserver 192.168.1.1 in the 16.04, then, have you tried setting the same on the 18.04 ?. Did it work? –  Jul 07 '20 at 04:44
  • I was told online that that is a poor way to set up a machine. If you recommend it, i'll go right ahead – Blaine141 Jul 07 '20 at 04:44
  • I do not know if it is "a good" or "a bad" way to set up a machine. But in any case, trying doesn't mean that it must stay. If it works, then, we have more information toward solving the problem. If it doesn't work, no damage done. A said: good luck .... –  Jul 07 '20 at 04:47
  • I'll try it out. was told that in 18.04 netplan should be used for all network config so I was scared I was going to mess it up. I'll let you know what I find – Blaine141 Jul 07 '20 at 04:48
  • Netplan doesn't write resolv.conf systemd netword tells systemd resolved to do it. –  Jul 07 '20 at 04:55
  • Yeah, adding the nameserver makes it work. Know the best way to permanently add a nameserver to resolv.conf? Tried the /etc/resolvconf/resolv.conf.d/base method but it didn't seem to work. – Blaine141 Jul 07 '20 at 05:07
  • What I do recomend you is to not edit such configuration files directly by hand. Just a moment. let me find a post that resolve that. –  Jul 07 '20 at 05:18
  • It seems that it should work automatically provided that the dhcp server is giving the DNS server option to the ubuntu 18.04 computer and that that computer is using that DHCP server to start-up. I am assuming that you do not have Network Manager controlling the network boot-up sequence, that would change what I am saying here. –  Jul 07 '20 at 05:24
  • I have the computer setting up a static IP through netplan. I also got this to work by modifying the /etc/resolvconf/resolv.conf.d/head file. Installed resolvconf as a part of getting this to work. Is this a good practice or would you suggest a different option? – Blaine141 Jul 07 '20 at 05:28
  • If you must use an static IP, there is no alternative. There is no DHCP server giving the information of which nameservers should be used. You can configure the DHCP server in your router to give an static IP to your 18.04 computer via its MAC address though. Depending on the software in the router, it may be easy or dificult. If it is working now, you can "live" with it. –  Jul 07 '20 at 05:35
  • Yeah, my system needs to have a static IP with or without the router connected so seems like this is the only option. It's a robot that is sometimes connected to a larger network sometimes autonomous. Thanks for all the help – Blaine141 Jul 07 '20 at 05:47
  • To future me, I experienced this issue again and came across this post again. The solution is to install resolvconf over apt and then add the router nameserver to /etc/resolvconf/resolv.conf.d/head and not /etc/resolvconf/resolv.conf.d/body. Have a good day – Blaine141 May 11 '21 at 00:23

1 Answers1

0

Solved by adding the router DNS nameserver address to resolv.conf.

As the address of the computer is manually set (not using DHCP), the nameserver address information also needs to be manually configured via resolconf, for example, Not a good idea in other set-ups, but manually setting a fixed address leaves not much options.

If the router DHCP server could be configured to always give the same address to the computer, there is no need to manually edit resolv.conf.

  • Note that the .local is implemented using mDNS (multicast-dns protocol implemented by the avahi package) and does not rely on any feature of the router. However only Linux and MacOS (and probably other BSDs) have that feature enabled by default. – Jan Hudec Sep 01 '22 at 15:49