resolving domain with dig is fast but using ping is slow

masenko · 2024-04-13 07:40:50

seth wrote:

I've found that that's the only stable way to keep /etc/resolv.conf correct
What? How? Why?

I've experienced on linux in general (multiple other distros) that /etc/resolv.conf tries to get modified by a bunch of different processes, i followed a guide to only use systemd-resolved and now my /etc/resolv.conf is working correctly.

seth wrote:

How do you configure the network to being with?

I use NetworkManager, if that's your question.

seth wrote:

Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

In the future, could you please give a short explanation of what your command will do? I found out myself but it can be a little intimidating for newbies to get sent a long command and to just trust it wont brick your install.

cronie.service                             | multi-user.target.wants
cups.path                                  | multi-user.target.wants
cups.service                               | multi-user.target.wants
cups.service                               | printer.target.wants
cups.socket                                | sockets.target.wants
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.resolve1.service      | system
dbus-org.freedesktop.timesync1.service     | system
display-manager.service                    | system
getty@tty1.service                         | getty.target.wants
NetworkManager.service                     | multi-user.target.wants
NetworkManager-wait-online.service         | network-online.target.wants
p11-kit-server.socket                      | sockets.target.wants
pipewire-pulse.socket                      | sockets.target.wants
pipewire-session-manager.service           | user
pipewire.socket                            | sockets.target.wants
remote-fs.target                           | multi-user.target.wants
systemd-resolved.service                   | sysinit.target.wants
systemd-timesyncd.service                  | sysinit.target.wants
systemd-userdbd.socket                     | sockets.target.wants
wireplumber.service                        | pipewire.service.wants

seth wrote:

Then disable systemd-resolved and make sure it's not auto-used by NM.

I have /etc/resolv.conf symlinked to /run/systemd/resolve/stub-resolv.conf, if that's what you mean.

seth · 2024-04-13 08:17:31

I have /etc/resolv.conf symlinked to /run/systemd/resolve/stub-resolv.conf, if that's what you mean.

What means it's under control of the (running, enabled) systemd-resolved.service, you'll have to configure the DNS through that or not at all.
https://wiki.archlinux.org/title/System … NS_servers
To combat your anecdote w/ my own: /etc/resolv.conf is exclusively configured through resolvconf invoked by dhcpcd here - and I can make that stop and limit it to "vim" any time I want.
If multiple processes touch resolv.conf you're running concurrent network managing services. That's exclusively a you-problem.

In the future, could you please give a short explanation of what your command will do? I found out myself but it can be a little intimidating for newbies to get sent a long command and to just trust it wont brick your install.

So you wouldn't trust the command but the explanation handed by the same source?

masenko · 2024-04-13 09:13:41

seth wrote:

That's exclusively a you-problem.

Isn't that why i'm posting here? Why i use systemd-resolved is because i didn't know of all the services that would try to modify the /etc/resolv.conf file, i now know of dhcpcd, resolved, nm.

seth wrote:

So you wouldn't trust the command but the explanation handed by the same source?

Maybe the explanation would give someone an idea of what they're about to run and if it will brick their install or not, you don't know everything that's going on on their machine. I'm not saying anyone on this forum would intentionally brick someone's pc, but unintentionally.

I've answered your questions for you to maybe fix my problem, do you have any more clues as to what the problem is?

seth · 2024-04-13 13:53:09

You're posint because "resolving domain with dig is fast but using ping is slow" and then made an unfounded statement that "I've found that [resolved]'s the only stable way to keep /etc/resolv.conf correct" because "on linux in general (multiple other distros) that /etc/resolv.conf tries to get modified by a bunch of different processes" which is factually incorrect and simply hints at previous misconfiguraions.
This is relevant because

I've answered your questions for you to maybe fix my problem, do you have any more clues as to what the problem is?

seth wrote:

My last-best-guess would be to disable resolved, apparently the configured DNS doesn't matter and 10.0.1.1 seems to be a caching local DNS stub, so there's no point in using resolved anyway.

seth wrote:

disable systemd-resolved and make sure it's not auto-used by NM.

https://wiki.archlinux.org/title/Networ … management
Ie. make that a regular file.
Make sure that after a reboot systemd-resolved no longer runs.

NM will then still write the resolvers, so if you want to control that, see https://wiki.archlinux.org/title/Networ … NS_servers

masenko · 2024-04-13 21:30:29

I've got 2 other debian machines where the /etc/resolv.conf points straight to the dns server and not a local stub, the ping command there works perfectly fine. I've done the same thing now on arch (no resolv.conf symlink and just one nameserver line), and the problem still persists. Would un-symlinking /etc/resolv.conf from systemd-resolved be the same as uninstalling entirely in this case?

seth · 2024-04-13 21:32:22

stat  /etc/resolv.conf
cat  /etc/resolv.conf
ps aux | resolv
resolvectl status

masenko · 2024-04-14 14:03:49

seth wrote:

stat  /etc/resolv.conf
cat  /etc/resolv.conf
ps aux | resolv
resolvectl status

#stat  /etc/resolv.conf
  File: /etc/resolv.conf
  Size: 50        	Blocks: 8          IO Block: 4096   regular file
Device: 0,25	Inode: 76711       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-04-04 14:32:03.105851828 +0200
Modify: 2024-04-04 12:08:38.139946827 +0200
Change: 2024-04-04 12:08:38.139946827 +0200
 Birth: 2024-04-04 12:08:38.139946827 +0200

#cat  /etc/resolv.conf
# Generated by NetworkManager
nameserver 10.0.1.2

#ps aux | resolv
-bash: resolv: command not found

#resolvectl status
Failed to get global data: Could not activate remote peer: activation request failed: unknown unit.

seth · 2024-04-14 15:07:49

Sorry, I dropped a "grep", but resolved is gone.
Why is the nameserver "10.0.1.2" now? You've previously used and reported on 10.0.1.1?
(But that was also ½ a year ago…)

dig @10.0.1.2 -x duckduckgo.com

is still fast?
(Post the output)

masenko · 2024-04-15 09:30:28

seth wrote:

Why is the nameserver "10.0.1.2" now? You've previously used and reported on 10.0.1.1?

It used to be arch>router>dns and now it's just arch>dns. Routing reasons made me have to use the previous option before i fixed it all, now there's one less caching dns in between.

seth wrote:

dig @10.0.1.2 -x duckduckgo.com
is still fast?
(Post the output)

; <<>> DiG 9.18.25 <<>> @10.0.1.2 -x duckduckgo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29331
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;com.duckduckgo.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
in-addr.arpa.		504	IN	SOA	b.in-addr-servers.arpa. nstld.iana.org. 2022093804 1800 900 604800 3600

;; Query time: 0 msec
;; SERVER: 10.0.1.2#53(10.0.1.2) (UDP)
;; WHEN: Mon Apr 15 11:29:26 CEST 2024
;; MSG SIZE  rcvd: 124

seth · 2024-04-15 13:47:01

Ok, status-quo ante, the DNS replies instantly and correctly w/ NXDOMAIN
And it's not resolved.

cat /etc/nsswitch.conf

And just ftr

ping -nc8 duckduckgo.com # still fast?
ping -c8 duckduckgo.com # still slow?

Brocellous · 2024-04-15 23:44:11

Pretty sure you are observing https://github.com/systemd/systemd/issues/28166. It was resolved in https://github.com/systemd/systemd/pull/31645.

You can set MulticastDNS=no in resolved.conf for the time being to disable it on all interfaces, until the next release, and you probably want to disable LLMNR anyway. You should restore the symlink to stub-resolv.conf as well.

Last edited by Brocellous (2024-04-15 23:46:05)

Arch Linux

#26 2024-04-13 07:40:50

Re: resolving domain with dig is fast but using ping is slow

#27 2024-04-13 08:17:31

Re: resolving domain with dig is fast but using ping is slow

#28 2024-04-13 09:13:41

Re: resolving domain with dig is fast but using ping is slow

#29 2024-04-13 13:53:09

Re: resolving domain with dig is fast but using ping is slow

#30 2024-04-13 21:30:29

Re: resolving domain with dig is fast but using ping is slow

#31 2024-04-13 21:32:22

Re: resolving domain with dig is fast but using ping is slow

#32 2024-04-14 14:03:49

Re: resolving domain with dig is fast but using ping is slow

#33 2024-04-14 15:07:49

Re: resolving domain with dig is fast but using ping is slow

#34 2024-04-15 09:30:28

Re: resolving domain with dig is fast but using ping is slow

#35 2024-04-15 13:47:01

Re: resolving domain with dig is fast but using ping is slow

#36 2024-04-15 23:44:11

Re: resolving domain with dig is fast but using ping is slow

Board footer