Join Log in
Score:0
sancho.s ReinstateMonicaCellio avatar Ubuntu

Why do two Ubuntu systems in the same network behave differently in DNS resolution?

pl flag
sancho.s ReinstateMonicaCellio

EDIT (tl;dr)

I seem to have identified part of the problem here, as at least the differences in /etc/resolv.conf and related files are gone.

But I still cannot connect via WiFi, so other difference probably persist.

I mean to identify these, and act upon them.

I intentionally selected the same title as this OP. I have two Ubuntu systems, server1 and server2, very similar in all respects. Both are connected to the same router, via WiFi. I worked by comparing the two systems to help tracking the problem.

In server2, I just started having DNS name resolution problems. I was connected to a VPN, and the server was rebooted, so I guess this PostScriptum may describe the case. server2 did not have resolvconf and I installed it as an outcome. At that time /etc/resolv.conf started pointing at /run/resolvconf/resolv.conf (note the modification date below), instead of /run/systemd/resolve/stub-resolv.conf. To do that, I had to manually add nameserver 8.8.8.8 at the top in /etc/resolv.conf, plug a wired internet connection, and I could immediately sudo apt update, etc. Note: As of now, the problem with file permissions quoted in the link above is not present. If it shows up next time I connect to/disconnect from a VPN, I will deal with it.

I am listing below: 1) what is different in server1 and server2, 2) what is the same in both (with any replacing the server name), and 3) what is almost the same (with irrelevant differences, in my understanding).

Why DIFFERENCE #3 below? (nameserver ::1).
How to fix server2, if possible, by leaving it with the same configuration as server1? I could try modifying /etc/resolvconf/resolv.conf.d/tail in server2, but since that file is empty in server1 this action would possibly mask other problems, even if successful.

I guess if I could only have DIFFERENCES #1-4 below fixed, that will solve the problem. But all 4 files are quoted as dynamically created. I could not locate who is/was responsible for "creating" the differences, and how to fix that.

Different

dig:

[server1]$ dig google.com

; <<>> DiG 9.16.1-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64202
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     94  IN  A   216.58.202.46

;; Query time: 36 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mar ago 10 03:44:51 -03 2021
;; MSG SIZE  rcvd: 55

vs.

[server2]$ dig google.com

; <<>> DiG 9.16.1-Ubuntu <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

/etc/resolv.conf and related files:

[server1]$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search fibertel.com.ar                                     <--- DIFFERENCE #1

[server1]$ cat /run/systemd/resolve/stub-resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# 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 127.0.0.53
options edns0 trust-ad
search fibertel.com.ar                                     <--- DIFFERENCE #2

[server1]$ cat /run/systemd/resolve/resolv.conf
# 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.0.1                                     <--- DIFFERENCE #3
search fibertel.com.ar                                     <--- DIFFERENCE #3

[server1]$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search fibertel.com.ar                                     <--- DIFFERENCE #4

[server1]$ ll /etc/resolv.conf 
lrwxrwxrwx 1 root root 29 feb  1  2021 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
[server1]$ ll /run/resolvconf/resolv.conf
-rw-r--r-- 1 root root 327 ago  9 20:59 /run/resolvconf/resolv.conf

vs.

[server2]$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

[server2]$ cat /run/systemd/resolve/stub-resolv.conf 
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# 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 127.0.0.53
options edns0 trust-ad

[server2]$ cat /run/systemd/resolve/resolv.conf
# 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 ::1                                     <--- DIFFERENCE #3

[server2]$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

[server2]$ ll /etc/resolv.conf
lrwxrwxrwx 1 root root 29 ago  9 22:38 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
[server2]$ ll /run/resolvconf/resolv.conf
-rw-r--r-- 1 root root 304 ago 10 03:13 /run/resolvconf/resolv.conf

Same

[any]$ uname -a
Linux <serverN> 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[any]$ dpkg -l | grep resolvconf
ii  resolvconf                                    1.82                                all          name server information handler

[any]$ cat /etc/netplan/01-network-manager-all.yaml 
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

[any]$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

[any]$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   <serverN>

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

[any]$ cat /etc/nsswitch.conf
...
[any]$ cat /etc/systemd/networkd.conf 
...
[any]$ ss -plnt | grep ':53'
LISTEN   0        4096       127.0.0.53%lo:53            0.0.0.0:* 
[any]$ sudo systemctl status resolvconf.service
...
[any]$ /lib/systemd/network/
...

Almost the same

[server1]$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal

[server2]$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:printing-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal

Related:

  1. DNS set to systemd's 127.0.0.53 - how to change permanently?
179
1 + 4
dns
guiverc avatar
cn flag
guiverc
The show very different with regards *patch* level (one still says 20.04.1 meaning it's not received patches from before 4-Feb-2021 at least (https://fridge.ubuntu.com/2021/02/05/ubuntu-20-04-2-lts-released/ though that date is the ISO release date, installed systems upgraded to 20.04.2 before that date). *Given that difference alone (6 months) no doubt a load of differences exist between them you're ignoring*...
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
@guiverc - I agree that may represent significant differences (*overall*) and can try updating. But do you think that has anything to do with the two questions (in boldface)?
0
Reply
guiverc avatar
cn flag
guiverc
It shows very different systems; either one has been ignored for six months & not updated (so updating it would fix the differences), or more likely - it's been altered in such a way that prevents upgrades from being installed, and is potentially also the cause for the difference and what you're looking for.
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
@guiverc - I did the upgrade, but the issue persists. Please see edited OP.
0
Reply
Score:1
chili555 avatar Ubuntu
cn flag
chili555

The file /etc/resolv.conf is intended to be a symbolic link to /run/systemd/resolve/stub-resolv.conf Check:

ls -al /etc/resolv.conf

If it is not, correct it:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/stub-resolv.conf  /etc/resolv.conf

Your netplan yaml file indicates that you are running Network Manager. That is the place to make your changes to DNS nameservers.

enter image description here

0 + 5
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
As stated in the OP, I just installed `resolvconf`. "At that time `/etc/resolv.conf` started pointing at `/run/resolvconf/resolv.conf` ..., instead of `/run/systemd/resolve/stub-resolv.conf`." So yes, I have it as a soft link, but different now from what you posted. As for manually changing DNS nameservers in *Menu* -> *Settings* -> *Wi-Fi* -> ..., why would I need to do that in one system (`server2`), and not in the other (`server1`)? I will try it anyway.
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
I confirm that manually setting the values as you show makes WiFi work. But why would that be needed? How can I avoid that? It should be possible I guess... `server1` works that way. And `server2` was working that way too up until yesterday.
0
Reply
chili555 avatar
cn flag
chili555
Your netplan yaml says, as it should when Network Manager is installed and running, to turn over everything to NM. Therefore, that's where we set the DNS configuration. If that's not what you want, remove NM entirely and amend your netplan yaml accordingly. If that's what you want, please start a new question. I am wondering why NM is installed on a server. If I have given a helpful answer to your question, please accept it: https://askubuntu.com/tour
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
So you mean that the *only* place to set DNS configuration when NM is in charge is the config of each WiFi connection? (could you point to which file/s store the modifications introduced via GUI?) As said, on one hand, that worked for `server2`. OTOH, it does not seem to be "the" place to handle DNS configuration. In `server1` that seems to be set somewhere else, as my WiFi connection has automatic config, which is the easiest to handle, and what I mostly want to have. So the answer *is* helpful (+1)... I would wait to possibly receive additional answers/info clarifying the point.
0
Reply
chili555 avatar
cn flag
chili555
In automatic config, or more properly, DHCP, the access point, usually a wireless router, provides all necessary details; IP address, gateway and DNS nameservers. Find out which with: `systemd-resolve --status | grep 'DNS Servers' -A2` In a manual configuration, that is, you wish to specify either the IP address, DNS nameservers or both, the details will be recorded in: `sudo cat /etc/NetworkManager/system-connections/MYROUTER.nmconnection` where MYROUTER is the name of the access point to which you are connected. Here is a snip from my file: `dns=8.8.8.8;8.8.4.4;`
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.