Weird DNS issues after sysupgrade

The sysupgrade routine I finished today seemed to be largely successful. I did the Download OpenWrt firmware for your device option since I needed a particular module for my usb-to-ethernet interface.

But after the upgrade I'm noticing some strange issues that seem to be related to DNS. For example, when I try to ping google by name from the command line on a connected hosts there is a long pause where there is no response, but after several seconds I get:

ping: sock4.fd: 3 (socktype: SOCK_DGRAM), sock6.fd: 4 (socktype: SOCK_DGRAM), hints.ai_family: AF_UNSPEC

ai->ai_family: AF_INET, ai->ai_canonname: 'www.google.com'
PING www.google.com (142.250.105.104) 56(84) bytes of data.
64 bytes from yt-in-f104.1e100.net (142.250.105.104): icmp_seq=1 ttl=57 time=56.0 ms
64 bytes from yt-in-f104.1e100.net (142.250.105.104): icmp_seq=2 ttl=57 time=56.0 ms
64 bytes from yt-in-f104.1e100.net (142.250.105.104): icmp_seq=3 ttl=57 time=55.5 ms
64 bytes from yt-in-f104.1e100.net (142.250.105.104): icmp_seq=4 ttl=57 time=56.3 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 55.461/55.928/56.261/0.291 ms

Issuing ping using the same command from the router itself (rpi4, ssh session) works as expected, with immediate ping responses. Also, from the same connected host when I try to click on some web link there is a delay of several seconds before the link resolves and the linked site is displayed.
On the router itself, using luci I am unable to update software lists and get the message "Unable to execute opkg update command: SyntaxError: Unexpected end of JSON input" after a wait of about 20 seconds when I try. And my ddns is not working either and does not update my IP at my provider (dnsexit). The Adblock package, as well, cannot update any of its lists. So something is kinda off here.
I see some possible indicators of issues in the log files but I'm not conversant enough in the technical end of things to be able to identify red flags. And I don't want to post the whole output here.
Also, when I try to run opkg update from a root ssh session on the router I get a failure and the message "Failed to send request: Operation not permitted."
Any input on what might be going on here and how to diagnose and fix it will be appreciated. Thanks

Anyone spot anything concerning in the following system log output?

Fri Mar 21 14:59:26 2025 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Fri Mar 21 14:59:26 2025 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: started, version 2.90 cachesize 150
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: DNS service limited to local subnets
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using nameserver 64.94.33.1#53
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using nameserver 208.67.220.220#53
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using nameserver 1.1.1.1#53
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for test
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for local
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Fri Mar 21 14:59:26 2025 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Fri Mar 21 14:59:26 2025 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry

This is output after I did another reflash of a different firmware out of which I decided to remove a couple of packages, btw.

Incidentally, I timed the delay that happens between clicking on a link on a connected host and a web page actually rendering. It takes about 8 seconds for the browser to navigate to the link and render the page.

Here's some additional potentially relevant information:

root@pi4:~# cat /tmp/resolv.conf
search mke
nameserver 127.0.0.1
nameserver ::1

and

root@pi4:~# cat /tmp/resolv.conf.d/resolv.conf.auto 
# Interface WAN
nameserver 209.18.47.61
nameserver 209.18.47.63
search tx.rr.com
# Interface lan
nameserver 192.168.1.1

So I have 2 Arch systems on my little LAN and 2 Void systems. The ping issue I described occurs only on the Arch machines for some crazy reason. On both Void systems issuing ping www.google.com results in the expected behavior, namely an immediate ping with an immediate reply. On one Arch system there is a pause of several seconds before the first ping succeeds. On the other Arch system I can't ping www.google.com at all. There, I get "Temporary failure in name resolution" when I try. In any case, the ping delay/failure seems a separate issue from the one I'm seeing with opkg and ddns not functioning on the router/gateway/AP. For what it's worth.

Does 1 use systemd-resolved? The issue was resolved after using resolved.

I had a DNS issue when I upgraded my rpi4 to openwrt 24.10.

See

And

1 Like

Yeah. The Arch systems both use systemd-resolved. Will look into that.

Adding options single-request to the end of /etc/resolv.conf on both of the Arch systems did, indeed, resolve the delayed or failed ping response on those machines. Which is nice to know--thanks for connecting this issue with that thread, d687r02j8g.
But the ping issue is only part, and not even the most important part, of the issues I'm facing after my sysupgrade. More important are the fact that I can't get opkg to work and, perhaps relatedly, ddns won't work either. I don't want to turn this into a frankenthread so I'll probably create a new thread that in the attempt to resolve those more pressing issues.

Incidentally, here's what the Arch wiki says about adding that line to /etc/resolv.conf:

Hostname lookup delayed with IPv6
If you experience a 5 second delay when resolving hostnames it might be due to a DNS-server/Firewall misbehaving and only giving one reply to a parallel A and AAAA request.[1] You can fix that by setting the following option in /etc/resolv.conf:

/etc/resolv.conf
options single-request