Dnsmasq times out querying upstream dns for local lookup?

Hi Folks,
Following this how to for NM dnsmasq setup: Setting up dnsmasq - a lightweight DHCP and DNS server [and this rh how to] I seem to have stuffed something up when I went back and changed my network from 192.168.0.0/24 to 192.168.1.0/24

[admin@server dnsmasq.d]$ nslookup server.office.lan 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	server.office.lan
Address: 192.168.1.40
;; connection timed out; no servers could be reached


[admin@server dnsmasq.d]$

The answer is returned straight away, but then nslookup hangs while dnsmasq seems to be querying upstream.

[admin@server dnsmasq.d]$ dig  +noall +answer @127.0.0.1 server.office.lan
server.office.lan.	0	IN	A	192.168.1.40
[admin@server dnsmasq.d]$

Answers straight away.

Pinging server.office.lan from another machine takes about 20 seconds for the first return; ditto accessing cockpit via machine name cf. IP address.

Any ideas what’s been missed where?
Thanks

First thing I would do is to use .local or .home.arpa as a domain to not get unessesary requests to the internet.

See here on this article: What domain name to use for your home network | Ctrl blog

Do not use undelegated domain names like .lan, .home, .homenet, .homegroup, .network, nor should you make up your own domain name. If you use a made-up domain name, then DNS requests may go unfulfilled by your router and it forwards them to the global DNS root servers. This creates needless overhead for the core internet infrastructure, and leaks information about your network (such as device names). Web browsers and other software, including your router, should already know not to do that with .local and .home.arpa domains.

2 Likes

Thanks @ilikelinux but I’ve been using .lan long long before 2018.

Let’s check the output:

systemctl status dnsmasq.service
NetworkManager --print-config
firewall-cmd --get-active-zones
head -v -n -0 /etc/{NetworkManager/,}dnsmasq*.d/*

nslookup first asks the A record for the IPv4 address, next the AAAA record for the IPv6 address. If you do not provide the IPv6 in /etc/hosts, it should ask upstream. For the moment I do not know how to fix, need some manpage study, except filling /etc/hosts with the IPv6 addresses in the LAN.

No.	Time	Source	Destination	Protocol	Length	Info
16	10.843065552	192.168.2.5	192.168.2.254	DNS	74	Standard query 0xa5cb A pcbeneden.home
17	10.843656214	192.168.2.254	192.168.2.5	DNS	90	Standard query response 0xa5cb A pcbeneden.home A 192.168.2.5
18	10.845119977	192.168.2.5	192.168.2.254	DNS	74	Standard query 0x286d AAAA pcbeneden.home
19	10.851131125	192.168.2.254	192.168.2.5	DNS	149	Standard query response 0x286d No such name AAAA pcbeneden.home SOA a.root-servers.net


Note: the response of my ISP router is wrong, it should return an empty AAAA record. 

Addition: Adding local=/lan/ to dnsmasq configuration indicates that dnsmasq is on its own for the lan domain, keeps it from consulting upstream servers and it should return a proper empty AAAA record. (not tested myself)

1 Like

Many thanks @vgaetera - I can see that’s spat out a whole lot of useful info - though dnsmasq is running under NM rather than on it’s own:

output
[admin@server dnsmasq.d]$ sudo systemctl status dnsmasq.service
[sudo] password for admin: 
â—‹ dnsmasq.service - DNS caching server.
     Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; preset: disabled)
     Active: inactive (dead)
[admin@server dnsmasq.d]$ sudo NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: 00-server.conf) (run: 15-carrier-timeout.conf) (etc: 00-use-dnsmasq.conf, crc-nm-dnsmasq.conf, dhcp-client.conf)

[main]
# plugins=
# rc-manager=auto
# migrate-ifcfg-rh=false
# auth-polkit=true
# iwd-config-path=
no-auto-default=*
ignore-carrier=*
dns=dnsmasq
dhcp=dhclient
configure-and-quit=no

[logging]
# backend=journal
# audit=false

[device]
# wifi.backend=wpa_supplicant

# no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"
[admin@server dnsmasq.d]$ sudo firewall-cmd --get-active-zones
internal
  interfaces: ens6f3 bridge0 ens6f0 ens6f1 ens6f2
libvirt
  interfaces: virbr0 crc
public
  interfaces: vnet2 vnet1 bond0 enp3s4f0 enp3s4f1
[admin@server dnsmasq.d]$ sudo head -v -n -0 /etc/{NetworkManager/,}dnsmasq*.d/*
==> /etc/NetworkManager/dnsmasq.d/01-DNS-office-lan.conf <==
# /etc/NetworkManager/dnsmasq.d/01-DNS-office-lan.conf
# This file sets up DNS for the private local net domain office.lan
### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/
### https://fedoramagazine.org/using-the-networkmanagers-dnsmasq-plugin/

# File where to find the list of IP - hostname mapping
addn-hosts=/etc/dnsmasq.hosts
addn-hosts=/etc/hosts

domain-needed
bogus-priv

# Automatically add <domain> to simple names in a hosts-file.
expand-hosts

# Interfaces to listen on
interface=lo
interface=bridge0
# In case of a bridge don't use the attached server virtual ethernet interface

# The below defines a Wildcard DNS Entry.
#address=/.localnet/10.10.10.zzz

# `local` is a synonym for `server` to make configuration files clearer
local=/office.lan/
domain=office.lan

# Upstream public net DNS server (max.three)
server=1.1.1.1
server=1.0.0.1
server=2606:4700:4700::1111

# Don't poll /etc/resolv.conf for changes
no-poll

==> /etc/NetworkManager/dnsmasq.d/02-DHCP-office-lan.conf <==
# etc/NetworkManager/dnsmasq.d/02-DHCP-office-lan.conf
# This file sets up DHCP for the private local net domain office.lan
### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/

# The domain the DHCP part of dnsmasq is responsible for:
domain=office.lan,192.168.1.0/24,local

# interfaces to listen on
interface=bridge0

# general DHCP stuff (options, see RFC 2132)
# 1: subnet masq
# 3: default router
# 6: DNS server
# 12: hostname
# 15: DNS domain (unneeded with option 'domain')
# 28: broadcast address

dhcp-authoritative
dhcp-option=1,255.255.255.0
dhcp-option=3,192.168.1.40
dhcp-option=6,192.168.1.40

# Assign fixed IP addresses based on MAC address
dhcp-host=DC:39:6F:72:3F:A8,fritzbox,192.168.1.30,6h
dhcp-host=2C:44:fD:89:99:B8,server,192.168.1.40,6h
dhcp-host=B4:B5:2F:5B:9A:92,ILOCZJ2320B32,192.168.1.41,6h
dhcp-host=00:00:74:7F:0F:B9,printer,192.168.1.120,6h
dhcp-host=A8:3B:76:BA:AE:87,mymachine,192.168.1.140,6h
dhcp-host=5C:E0:C5:E5:86:B1,myoldmachine,192.168.1.141,6h
dhcp-host=60:B7:6E:03:76:33,myphone,192.168.1.160,6h
dhcp-host=B0:72:BF:CC:FB:08,myphone-gs7,192.168.1.161,6h

# Assign dynamically IP addresses to interface to listen on
# Range for distributed addresses, tagged <int> for further references dhcp-range=tag:enp2s0,10.10.10.150,10.10.10.200,24h
dhcp-range=192.168.1.50,192.168.1.250,6h

==> /etc/NetworkManager/dnsmasq.d/crc.conf <==
server=/apps-crc.testing/192.168.130.11
server=/crc.testing/192.168.130.11

==> /etc/NetworkManager/dnsmasq.d/examples.hidden <==
head: error reading '/etc/NetworkManager/dnsmasq.d/examples.hidden': Is a directory

==> /etc/NetworkManager/dnsmasq.d/libvirt-office-lan.conf <==
### References:
### https://liquidat.wordpress.com/2017/03/03/howto-automated-dns-resolution-for-kvmlibvirt-guests-with-a-local-domain/
### https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/
# /etc/NetworkManager/dnsmasq.d/DNS-libvirt-office-lan.conf

# This file directs dnsmasq to forward any request to resolve
# names under the .libvirt.office.lan domain to 192.168.122.1, the
# local libvirt DNS server default address.
server=/libvirt.office.lan/192.168.122.1
head: cannot open '/etc/dnsmasq*.d/*' for reading: No such file or directory
[admin@server dnsmasq.d]$

@hmmsjan, that’s interesting…:

[admin@server dnsmasq.d]$ nslookup
> set querytype=A
> server.office.lan 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	server.office.lan
Address: 192.168.1.40
> set querytype=AAAA
> server.office.lan 127.0.0.1
;; connection timed out; no servers could be reached

> exit

[admin@server dnsmasq.d]$ 

So, yes - it’s the IPv6 misconfig that’s causing the nslookup timeout - the A query returns immediately and it’s the AAAA query that times out.

But, then - why is ping doing something similar:

:~$ ping -4 server.office.lan
PING server.office.lan (192.168.1.40) 56(84) bytes of data.
64 bytes from server.office.lan (192.168.1.40): icmp_seq=1 ttl=64 time=2.76 ms
64 bytes from server.office.lan (192.168.1.40): icmp_seq=2 ttl=64 time=2.06 ms
64 bytes from server.office.lan (192.168.1.40): icmp_seq=3 ttl=64 time=2.61 ms
^C
--- server.office.lan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 2.063/2.478/2.760/0.299 ms
:~$ ping -6 server.office.lan
ping: server.office.lan: Address family for hostname not supported
:~$

The ping -4 command timesout (apparently) the same as nslookup…?

That said, https://server.office.lan:9090 gets me into cockpit immediately…

It makes some sense that IPv6 needs reconfiguring because although the ISP provides no IPv6, I set it up locally and then didn’t bother to think about it when moving from 192.168.0.0/24 to 192.168.1.0/24. Perhaps I should, but then that still leaves the timeout on ping -4 a mystery…

I do not see a problem with the ping command?? It runs until terminated with ctrl-c and prints a summary.
ping -6 will fail if ipv6 is not properly configured.

If you want to configure it locally, you can use dnsmasq also as DHCP6 server.
But may be problems or delays arise when remote IPv6 addresses come from DNS and your router/isp can’t handle it. dnsmasq has an option to never pass AAAA records.

No, it can’t be seen from the output, you’ll have to take my word for it… There’s a 14 sec delay (counting elephants) between hitting enter and the first return - ping on the IP address rather than host name is immediate

[edit: I’m guessing it would have been the ping command that first alerted me to a problem, it would have been what I used to check things were working after the IP change.]

Is there still a old record pointing to the old IP? In /etc/hosts or so?

p.s.
Do you still have the localhost entry in your hosts file?

# For historical reasons, localhost precedes localhost.localdomain:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

The .local is for mDNS only and should not be used.
The ICANN approved TLD name is .internal for this purpose.
There where people pushing for .home as it was already in wide use.
ICANN did not approve .home, but did reserve it so that it was not allocated to
a registar.

FYI .internal - Wikipedia

1 Like

It’s difficult to judge without the exact configuration, systemd-resolved is also standard active in Fedora. I do not know why, but in the standard systemd-resolved configuration, a “ping -4 hccnet.nl” monitored with wireshark shows a request for A and AAAA record plus, and that might be the culprit, an inverse lookup for the result. Have you tried “ping -n” ?

1 Like

I think this is becuase the C API that ping uses required both the IPv4 and Ipv6 addresses to be returned for the one call.

Thanks @hmmsjan and @barryascott , systemd-resolved not installed (on neither server nor client).

Hmm, interistinger and interestinger… But, that doesn’t seem the case for me, perhaps - it’s a long time since I played with Wireshark, correct me if I’m wrong - here’s 3 pings to server.office.lan via Wireshark:

Wireshark capture

No. Time Source Destination Protocol Length Info
1 0.000000000 192.168.1.141 192.168.1.40 ICMP 98 Echo (ping) request id=0x0031, seq=1/256, ttl=64 (reply in 2)

Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface wlo1, id 0
Interface id: 0 (wlo1)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 9, 2024 19:50:57.569877504 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1725907857.569877504 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Destination: HewlettP_munge2 (2c:44:fd:munge2)
Source: IntelCor_munge1 (5c:e0:c5:munge1)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 84
Identification: 0x10fc (4348)
Flags: 0x40, Don’t fragment
Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0xa5a7 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.141
Destination Address: 192.168.1.40
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xc79e [correct]
[Checksum Status: Good]
Identifier (BE): 49 (0x0031)
Identifier (LE): 12544 (0x3100)
Sequence Number (BE): 1 (0x0001)
Sequence Number (LE): 256 (0x0100)
[Response frame: 2]
Timestamp from icmp data: Sep 9, 2024 19:50:57.000000000 BST
[Timestamp from icmp data (relative): 0.569877504 seconds]
Data (48 bytes)

0000 f8 b1 08 00 00 00 00 00 10 11 12 13 14 15 16 17 …
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 … !"#$%&’
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567

No. Time Source Destination Protocol Length Info
2 0.002187020 192.168.1.40 192.168.1.141 ICMP 98 Echo (ping) reply id=0x0031, seq=1/256, ttl=64 (request in 1)

Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface wlo1, id 0
Interface id: 0 (wlo1)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 9, 2024 19:50:57.572064524 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1725907857.572064524 seconds
[Time delta from previous captured frame: 0.002187020 seconds]
[Time delta from previous displayed frame: 0.002187020 seconds]
[Time since reference or first frame: 0.002187020 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Destination: IntelCor_munge1 (5c:e0:c5:munge1)
Source: HewlettP_munge2 (2c:44:fd:munge2)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 84
Identification: 0x1328 (4904)
Flags: 0x00
Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0xe37b [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.40
Destination Address: 192.168.1.141
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0xcf9e [correct]
[Checksum Status: Good]
Identifier (BE): 49 (0x0031)
Identifier (LE): 12544 (0x3100)
Sequence Number (BE): 1 (0x0001)
Sequence Number (LE): 256 (0x0100)
[Request frame: 1]
[Response time: 2.187 ms]
Timestamp from icmp data: Sep 9, 2024 19:50:57.000000000 BST
[Timestamp from icmp data (relative): 0.572064524 seconds]
Data (48 bytes)

0000 f8 b1 08 00 00 00 00 00 10 11 12 13 14 15 16 17 …
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 … !"#$%&’
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567

No. Time Source Destination Protocol Length Info
3 1.001612662 192.168.1.141 192.168.1.40 ICMP 98 Echo (ping) request id=0x0031, seq=2/512, ttl=64 (reply in 4)

Frame 3: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface wlo1, id 0
Interface id: 0 (wlo1)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 9, 2024 19:50:58.571490166 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1725907858.571490166 seconds
[Time delta from previous captured frame: 0.999425642 seconds]
[Time delta from previous displayed frame: 0.999425642 seconds]
[Time since reference or first frame: 1.001612662 seconds]
Frame Number: 3
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Destination: HewlettP_munge2 (2c:44:fd:munge2)
Source: IntelCor_munge1 (5c:e0:c5:munge1)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 84
Identification: 0x135b (4955)
Flags: 0x40, Don’t fragment
Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0xa348 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.141
Destination Address: 192.168.1.40
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x7897 [correct]
[Checksum Status: Good]
Identifier (BE): 49 (0x0031)
Identifier (LE): 12544 (0x3100)
Sequence Number (BE): 2 (0x0002)
Sequence Number (LE): 512 (0x0200)
[Response frame: 4]
Timestamp from icmp data: Sep 9, 2024 19:50:58.000000000 BST
[Timestamp from icmp data (relative): 0.571490166 seconds]
Data (48 bytes)

0000 46 b8 08 00 00 00 00 00 10 11 12 13 14 15 16 17 F…
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 … !"#$%&’
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567

No. Time Source Destination Protocol Length Info
4 1.004469307 192.168.1.40 192.168.1.141 ICMP 98 Echo (ping) reply id=0x0031, seq=2/512, ttl=64 (request in 3)

Frame 4: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface wlo1, id 0
Interface id: 0 (wlo1)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 9, 2024 19:50:58.574346811 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1725907858.574346811 seconds
[Time delta from previous captured frame: 0.002856645 seconds]
[Time delta from previous displayed frame: 0.002856645 seconds]
[Time since reference or first frame: 1.004469307 seconds]
Frame Number: 4
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Destination: IntelCor_munge1 (5c:e0:c5:munge1)
Source: HewlettP_munge2 (2c:44:fd:munge2)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 84
Identification: 0x161e (5662)
Flags: 0x00
Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0xe085 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.40
Destination Address: 192.168.1.141
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x8097 [correct]
[Checksum Status: Good]
Identifier (BE): 49 (0x0031)
Identifier (LE): 12544 (0x3100)
Sequence Number (BE): 2 (0x0002)
Sequence Number (LE): 512 (0x0200)
[Request frame: 3]
[Response time: 2.857 ms]
Timestamp from icmp data: Sep 9, 2024 19:50:58.000000000 BST
[Timestamp from icmp data (relative): 0.574346811 seconds]
Data (48 bytes)

0000 46 b8 08 00 00 00 00 00 10 11 12 13 14 15 16 17 F…
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 … !"#$%&’
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567

No. Time Source Destination Protocol Length Info
5 2.002903992 192.168.1.141 192.168.1.40 ICMP 98 Echo (ping) request id=0x0031, seq=3/768, ttl=64 (reply in 6)

Frame 5: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface wlo1, id 0
Interface id: 0 (wlo1)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 9, 2024 19:50:59.572781496 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1725907859.572781496 seconds
[Time delta from previous captured frame: 0.998434685 seconds]
[Time delta from previous displayed frame: 0.998434685 seconds]
[Time since reference or first frame: 2.002903992 seconds]
Frame Number: 5
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Destination: HewlettP_munge2 (2c:44:fd:munge2)
Source: IntelCor_munge1 (5c:e0:c5:munge1)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 84
Identification: 0x138f (5007)
Flags: 0x40, Don’t fragment
Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0xa314 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.141
Destination Address: 192.168.1.40
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x8991 [correct]
[Checksum Status: Good]
Identifier (BE): 49 (0x0031)
Identifier (LE): 12544 (0x3100)
Sequence Number (BE): 3 (0x0003)
Sequence Number (LE): 768 (0x0300)
[Response frame: 6]
Timestamp from icmp data: Sep 9, 2024 19:50:59.000000000 BST
[Timestamp from icmp data (relative): 0.572781496 seconds]
Data (48 bytes)

0000 34 bd 08 00 00 00 00 00 10 11 12 13 14 15 16 17 4…
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 … !"#$%&’
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567

No. Time Source Destination Protocol Length Info
6 2.005770709 192.168.1.40 192.168.1.141 ICMP 98 Echo (ping) reply id=0x0031, seq=3/768, ttl=64 (request in 5)

Frame 6: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface wlo1, id 0
Interface id: 0 (wlo1)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 9, 2024 19:50:59.575648213 BST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1725907859.575648213 seconds
[Time delta from previous captured frame: 0.002866717 seconds]
[Time delta from previous displayed frame: 0.002866717 seconds]
[Time since reference or first frame: 2.005770709 seconds]
Frame Number: 6
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Destination: IntelCor_munge1 (5c:e0:c5:munge1)
Source: HewlettP_munge2 (2c:44:fd:munge2)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 84
Identification: 0x1a01 (6657)
Flags: 0x00
Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0xdca2 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.40
Destination Address: 192.168.1.141
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x9191 [correct]
[Checksum Status: Good]
Identifier (BE): 49 (0x0031)
Identifier (LE): 12544 (0x3100)
Sequence Number (BE): 3 (0x0003)
Sequence Number (LE): 768 (0x0300)
[Request frame: 5]
[Response time: 2.867 ms]
Timestamp from icmp data: Sep 9, 2024 19:50:59.000000000 BST
[Timestamp from icmp data (relative): 0.575648213 seconds]
Data (48 bytes)

0000 34 bd 08 00 00 00 00 00 10 11 12 13 14 15 16 17 4…
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 … !"#$%&’
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567

The interesting thing, there are no pings out while I’m counting my 14 or so elephants - the Wireshark capture follows the timeout, but I’m hitting the Wireshark capture button with the enter key for ping - the cursor blinks (1 sec interval) to 10 secs and then stops blinking for the last 4 seconds.

ping -n is just the same.

I guess I’ve got to fix up IPv6 at some point, but I’d like to be able to get to the bottom of what’s going on before guessing at what to fix.

@barryascott ping calls “getaddrinfo” function to look-up addresses belonging to a hostname. You can add some hints to it, and one of the hints is ipv4, ipv6 or both. If I look correctly in the debugger, it selects both even with -4 in the arguments. So both IPv4 an IPv6 are requested.

@mread May be udp.port==53 as display filter in Wireshark is more interesting to see the DNS requests going outside and when. If it is correct, none, because server.office.lan is internal. Do a restart of NetworkManager/dnsmasq before to prevent cached resuls.
I had this once before but was not patient enough to count elephants and entered the IP address without looking for the reason of the problem.

1 Like

My enthusiasm for elephants might taper off a little as it seems clear this is a peculiarity of ping rather than - other than the IPv6 config - a duff set up. I’ll report back my discoveries. Many thanks all for listening.

Tried to simulate your setup in a VM and namespace. It looks like dnsmasq works perfect, server.office.lan gets it’s address, lookup and reverse lookup works, AAAA record is empty, and server can be pinged immediately.

Since ping goes through systemd-resolved in /etc/nsswitch.conf, be sure that it is not running somehow. Should be not installed, disabled,masked. If it is not active, search goes further to DNS.

/etc/resolv.conf should point to 127.0.0.1. Be sure that there are no entries to the old 192.168.0.0 somewhere in /etc/hosts files or routes.

Only problem I had was that the DHCP server did not work because NetworkManager started dnsmasq with listen-address=127.0.0.1, so I started dnsmasq manually with your config.
Bit surprised about “server=2606:4700:4700::1111” if you do not have IPv6. It’s a valid server but without IPv6 support from ISP it will not work.

Another way to find out what ping is doing is starting it with “strace -f”, then all system calls are printed. Complex stuff, but might give an indication and is at least an alternative for counting elephants.

@hmmsjan many thanks for the detailed follow up. I’ll take things a bit at a time, so for now follows the text of Wireshark capture as you suggest, on DNS querries - and yes, they started immediately I started ping, which I let run for 3 pings:

pingDNSoutput

No. Time Source Destination Protocol Length Info
6 1.275905189 192.168.1.141 192.168.1.40 DNS 77 Standard query 0xf803 A server.office.lan

Frame 6: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 37471, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
7 1.275927072 192.168.1.141 192.168.1.40 DNS 77 Standard query 0x9601 AAAA server.office.lan

Frame 7: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 37471, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
8 1.277839545 192.168.1.40 192.168.1.141 DNS 93 Standard query response 0xf803 A server.office.lan A 192.168.1.40

Frame 8: 93 bytes on wire (744 bits), 93 bytes captured (744 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 37471
Domain Name System (response)

No. Time Source Destination Protocol Length Info
333 5.110882358 192.168.1.141 192.168.1.40 DNS 75 Standard query 0xb8e1 A bam.nr-data.net

Frame 333: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 57112, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
336 5.123115787 192.168.1.40 192.168.1.141 DNS 159 Standard query response 0xb8e1 A bam.nr-data.net CNAME bam.cell.nr-data.net CNAME bam.nr-data.net.cdn.cloudflare.net A 162.247.241.14

Frame 336: 159 bytes on wire (1272 bits), 159 bytes captured (1272 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 57112
Domain Name System (response)

No. Time Source Destination Protocol Length Info
337 5.123298791 192.168.1.141 192.168.1.40 DNS 75 Standard query 0xa7ee AAAA bam.nr-data.net

Frame 337: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 59093, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
338 5.125227086 192.168.1.40 192.168.1.141 DNS 157 Standard query response 0xa7ee AAAA bam.nr-data.net CNAME bam.cell.nr-data.net CNAME bam.nr-data.net.cdn.cloudflare.net

Frame 338: 157 bytes on wire (1256 bits), 157 bytes captured (1256 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 59093
Domain Name System (response)

No. Time Source Destination Protocol Length Info
346 6.277610428 192.168.1.141 192.168.1.40 DNS 77 Standard query 0xf803 A server.office.lan

Frame 346: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 37471, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
347 6.280184531 192.168.1.40 192.168.1.141 DNS 93 Standard query response 0xf803 A server.office.lan A 192.168.1.40

Frame 347: 93 bytes on wire (744 bits), 93 bytes captured (744 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 37471
Domain Name System (response)

No. Time Source Destination Protocol Length Info
348 6.280280489 192.168.1.141 192.168.1.40 DNS 77 Standard query 0x9601 AAAA server.office.lan

Frame 348: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 37471, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
427 11.282114417 192.168.1.141 192.168.1.40 DNS 77 Standard query 0xf803 A server.office.lan

Frame 427: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 33377, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
428 11.284379763 192.168.1.40 192.168.1.141 DNS 93 Standard query response 0xf803 A server.office.lan A 192.168.1.40

Frame 428: 93 bytes on wire (744 bits), 93 bytes captured (744 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 33377
Domain Name System (response)

No. Time Source Destination Protocol Length Info
429 11.284495419 192.168.1.141 192.168.1.40 DNS 77 Standard query 0x9601 AAAA server.office.lan

Frame 429: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 50237, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
458 15.114322542 192.168.1.141 192.168.1.40 DNS 75 Standard query 0xb099 A bam.nr-data.net

Frame 458: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 51994, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
460 15.116624178 192.168.1.40 192.168.1.141 DNS 173 Standard query response 0xb099 A bam.nr-data.net CNAME bam.cell.nr-data.net CNAME bam.nr-data.net.cdn.cloudflare.net A 162.247.241.14

Frame 460: 173 bytes on wire (1384 bits), 173 bytes captured (1384 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 51994
Domain Name System (response)

No. Time Source Destination Protocol Length Info
461 15.116741770 192.168.1.141 192.168.1.40 DNS 75 Standard query 0x779b AAAA bam.nr-data.net

Frame 461: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 50030, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
462 15.117745763 192.168.1.40 192.168.1.141 DNS 157 Standard query response 0x779b AAAA bam.nr-data.net CNAME bam.cell.nr-data.net CNAME bam.nr-data.net.cdn.cloudflare.net

Frame 462: 157 bytes on wire (1256 bits), 157 bytes captured (1256 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 50030
Domain Name System (response)

No. Time Source Destination Protocol Length Info
473 16.283920492 192.168.1.141 192.168.1.40 DNS 85 Standard query 0xee54 PTR 40.1.168.192.in-addr.arpa

Frame 473: 85 bytes on wire (680 bits), 85 bytes captured (680 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 56915, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
474 16.284944729 192.168.1.40 192.168.1.141 DNS 116 Standard query response 0xee54 PTR 40.1.168.192.in-addr.arpa PTR server.office.lan

Frame 474: 116 bytes on wire (928 bits), 116 bytes captured (928 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 56915
Domain Name System (response)

No. Time Source Destination Protocol Length Info
488 17.285619094 192.168.1.141 192.168.1.40 DNS 85 Standard query 0xa6a4 PTR 40.1.168.192.in-addr.arpa

Frame 488: 85 bytes on wire (680 bits), 85 bytes captured (680 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 45921, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
489 17.286832058 192.168.1.40 192.168.1.141 DNS 116 Standard query response 0xa6a4 PTR 40.1.168.192.in-addr.arpa PTR server.office.lan

Frame 489: 116 bytes on wire (928 bits), 116 bytes captured (928 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 45921
Domain Name System (response)

No. Time Source Destination Protocol Length Info
494 18.287274907 192.168.1.141 192.168.1.40 DNS 85 Standard query 0xb227 PTR 40.1.168.192.in-addr.arpa

Frame 494: 85 bytes on wire (680 bits), 85 bytes captured (680 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 58774, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
495 18.289180925 192.168.1.40 192.168.1.141 DNS 116 Standard query response 0xb227 PTR 40.1.168.192.in-addr.arpa PTR server.office.lan

Frame 495: 116 bytes on wire (928 bits), 116 bytes captured (928 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 58774
Domain Name System (response)

No. Time Source Destination Protocol Length Info
500 18.354222361 192.168.1.141 192.168.1.40 DNS 88 Standard query 0xd0f2 A discussion.fedoraproject.org

Frame 500: 88 bytes on wire (704 bits), 88 bytes captured (704 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 60746, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
504 18.356077437 192.168.1.40 192.168.1.141 DNS 155 Standard query response 0xd0f2 A discussion.fedoraproject.org CNAME fedoraproject.hosted-by-discourse.com A 184.105.99.43

Frame 504: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 60746
Domain Name System (response)

No. Time Source Destination Protocol Length Info
505 18.356194042 192.168.1.141 192.168.1.40 DNS 88 Standard query 0x89f1 AAAA discussion.fedoraproject.org

Frame 505: 88 bytes on wire (704 bits), 88 bytes captured (704 bits) on interface wlo1, id 0
Ethernet II, Src: IntelCor_munge1 (5c:e0:c5:munge1), Dst: HewlettP_munge2 (2c:44:fd:munge2)
Internet Protocol Version 4, Src: 192.168.1.141, Dst: 192.168.1.40
User Datagram Protocol, Src Port: 49799, Dst Port: 53
Domain Name System (query)

No. Time Source Destination Protocol Length Info
506 18.357214563 192.168.1.40 192.168.1.141 DNS 167 Standard query response 0x89f1 AAAA discussion.fedoraproject.org CNAME fedoraproject.hosted-by-discourse.com AAAA 2602:fd3f:3:ff01::2b

Frame 506: 167 bytes on wire (1336 bits), 167 bytes captured (1336 bits) on interface wlo1, id 0
Ethernet II, Src: HewlettP_munge2 (2c:44:fd:munge2), Dst: IntelCor_munge1 (5c:e0:c5:munge1)
Internet Protocol Version 4, Src: 192.168.1.40, Dst: 192.168.1.141
User Datagram Protocol, Src Port: 53, Dst Port: 49799
Domain Name System (response)

I’ll nibble away at your other suggestions before long.
Thanks

Assuming this server is 192.168.1.40, it should have a static IP and doesn’t need the dhcp-host entry, unless this is a different server.

You can enable DNS query logging and collect the log for:

nslookup server.office.lan 127.0.0.1
nslookup printer.office.lan 127.0.0.1

Also check this:

grep -e ^hosts: /etc/nsswitch.conf
grep -v -e ^# /etc/resolv.conf
pgrep -f -a dnsmasq
sudo ss -lnpAinet | grep -e dnsmasq -e :53

That’s a lot. But big friend “grep” indicates that at 1,6 and 11 seconds there is a request for server.office.lan for A and AAAA record, the A record returns immediately as 192.168.1.40.
At 16,17 and 18 there is a inverse lookup for 192.168.1.40, immediately followed by a PTR response server.office.lan.

So is ping waiting for a response to the AAAA record question, and after 3 failures and 17 seconds it goes on with the reverse lookup of IPv4??
I do not know, I got an empty AAAA from dnsmasq which is correct.
Still wondering whether systemd-resolved is somewhere in between.
What is the output of “resolvectl”, if any?

One other question: server.office.lan is 192.168.1.40. This advertises itself as DNS server and router. Does it get it’s address via self-DHCP (I do not know whether this is possible) or fixed address + entry in /etc/hosts?