1

I updated my kernel this weekend, and now I'm using 5.3.1.

christopher@HAL4:~$ uname -r
5.3.1-050301-generic

I need to login to servers, but I cannot do so by hostname any longer. For example, I have a server, "web4," and it's local IP is 192.168.64.140. If I run dig:

christopher@HAL4:~$ dig web4

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> web4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1580
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;web4.              IN  A

;; ANSWER SECTION:
web4.           0   IN  A   192.168.64.140

;; Query time: 0 msec
;; SERVER: 192.168.3.222#53(192.168.3.222) <---- Correct! 
;; WHEN: Mon Sep 30 09:50:31 CDT 2019
;; MSG SIZE  rcvd: 49

Same thing for nslookup:

christopher@HAL4:~$ nslookup web4
Server:     192.168.3.222
Address:    192.168.3.222#53

Name:   web4
Address: 192.168.64.140

However, neither ping or ssh work ('login' is a bash script that uses my key):

christopher@HAL4:~$ ping web4
ping: web4: Name or service not known
christopher@HAL4:~$ login web4
ssh: Could not resolve hostname web4: Name or service not known 

My /etc/resolv.conf is:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#


# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.3.222
nameserver 192.168.70.80

It is a symlink to /run/systemd/resolve/resolv.conf.

Here is my /etc/netplan/01-network-manager-all.yaml file:

christopher@HAL4:~$ cat /etc/netplan/01-network-manager-all.yaml 
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
  ethernets:
          enp4s0:
                  dhcp4: no
                  addresses: [192.168.2.47/19]
                  gateway4: 192.168.1.1
                  nameservers:
                          addresses: [192.168.3.222,192.168.70.80]

What happened to my DNS?!

2
  • what happens if you ping web4.? O_o – poige Sep 30 '19 at 15:50
  • @poige same thing as ssh. Nothing. – IRGeekSauce Sep 30 '19 at 18:39
4

Check /etc/nsswitch.conf

look for the line that starts hosts and make sure it has dns on it.

hosts: files dns

Update - as you say in the comments, your nsswitch.conf has:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

This means that hosts resolution will first look in /etc/hosts, and then use mdns4_minimal, which implied that youre using the avahi daemon service, perhaps this isnt running? If it fails to resolve using mdns, host resolution will fail - this is usually by design, to ensure that resolution is sure to use avahi, the fact that youve got resolve [!UNAVAIL=return] after this, means that the systemd resolver may be configured too... [!UNAVAILBLE=return] means that systemd-resolved will always be used if its up, but continue to nss-dns if not. So, determine how you want to resolve names to addresses, if you arent using mdns you can remove mdns4_minimal [NOTFOUND=return] so this may be better for you:

hosts: files resolve [!UNAVAIL=return] dns myhostname

or even:

hosts: files dns myhostname
5
  • That line says: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname – IRGeekSauce Sep 30 '19 at 15:11
  • 2
    comment it out, and set it to just hosts: files dns and see if things improve. I cant comment on your local requirements. – Sirch Sep 30 '19 at 15:19
  • You should edit your answer and add that to it because that worked ! :D – IRGeekSauce Sep 30 '19 at 15:24
  • 1
    But the other stuff is needed in some situations, and removing it will break mDNS. – Sirch Sep 30 '19 at 15:31
  • askubuntu.com/a/853284 – poige Sep 30 '19 at 15:51
0

ping goes through system resolving, meanwhile with dig you're sending requests directly. That's why there're different outcomes.

As to how to solve it — not using separate zone for hosts isn't best (or even good) practice. Say, mDNS (Multicast DNS) service shipped with Ubuntu 18.04 expects .local to be default zone unless it's explicitly specified.

If you don't need mDNS in your system of course you can just adjust /etc/nsswitch.conf accordingly. But in general (read "following best practices") you should have separate DNS zone for your LAN which you can have setup to be tried by default, even if you omit its name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.