Subj : Re: ODD DNS behaviour on Pi ZERO W with Bullseye OS To : All From : The Natural Philosopher Date : Wed Nov 19 2025 10:33:19 On 19/11/2025 08:50, Richard Kettlewell wrote: > The Natural Philosopher writes: >> On 18/11/2025 21:08, Computer Nerd Kev wrote: >>> The Natural Philosopher wrote: >>>> Seriously,m its not the server, its the DNS. > >>>> It (the PI) cant even *find* the SMTP server >>>> Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270: >>>> uid=0 from= >>>> Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: >>>> message-id=<20251118104656.CC05B1F270@heating-controller> >>>> Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270: >>>> from=, size=387, nrcpt=1 (queue active) >>>> Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: >>>> to=, relay=none, delay=0.38, >>>> delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name >>>> not found. Name service error for name=vps.templar.co.uk type=MX: Host >>>> not found, try again) >>> >>> If it's the only network activity the thing does regularly, maybe >>> the WiFi interface has gone into some sort of sleep mode and the DNS >>> resolver isn't waiting for it to wake up. If you leave ping running >>> (eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface >>> active, maybe it will work the first time? >>> >> I was logged in over ssh at the time, so that hound don't hunt :-( > > Was the SSH session actually doing anything? An idle SSH session doesn?t > have to exchange any packets at all. > I used it to compose and send the mail...from the command line > But ?it?s always DNS? is a pretty reliable starting point for network > debugging, and I think it?s the right one here. > > What are you using as a name server? i.e. what is in resolv.conf on this > machine? > Stuff that apparently isn't used. It was set to 127.0.0.1 and IIRC dnsmasq was running. I set it to my internal servers that run BIND but I dont think its actually using them > Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: > to=, relay=none, delay=0.38, > delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain > name not found. Name service error for name=vps.templar.co.uk type=MX: > Host not found, try again) > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > It?s a temporary failure, ?TRY_AGAIN? ultimately from something in > resolv.h or netdb.h, but with a lot of Postfix-specific DNS code around > it. > Well I figured that it was temporary by the way the thing turns up a few minutes later... > vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk. > > Your MX record has 1-hour TTL, so an hour after the last successful > query, your local (or ISP-provided) name server will have to ask > domaincontrol.com again. That may explain why ?a few hours delay? brings > the condition back. > Ah, cache timed out. But local servers contacting that address to fetch mail every few minutes, so the local dns servers will always have it. Question is whether the pi is actually using them When I tried to discover what was being used it turns out that there are (at least) three possible mechanisms in use whose config files did not match anything on the Pi. Usual 'lets change it all for this release' stuff. So no, I don't know what it is now using as a DNS client. Its very odd. I just did this... # dig vps.templar.co.uk ; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good) ;; QUESTION SECTION: ;vps.templar.co.uk. IN A ;; ANSWER SECTION: vps.templar.co.uk. 3726 IN A 185.113.128.151 ;; Query time: 9 msec ;; SERVER: 192.168.0.101#53(192.168.0.101) ;; WHEN: Wed Nov 19 10:21:12 GMT 2025 ;; MSG SIZE rcvd: 90 ....then this... root@heating-controller:/var/ramlog# echo "This is more bollox isn't it?" | mail -a "From: oil-monitor@heating-controller" -s "another message" superroot@templar.co.uk ....and this... root@heating-controller:/var/ramlog# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller (Host or domain name not found. Name service error for name=vps.templar.co.uk type=MX: Host not found, try again) superroot@templar.co.uk -- 0 Kbytes in 1 Request. Now unless dig is using some other means than postfix to look up DNS, it looks like the problem is in postfix somehow. I don't know how to work that out. Maybe I should forget postfix and code up a simple SMTP client Just like the old days....:-) and finally a few minutes later... # mailq Mail queue is empty ....so it finally figured out how to send it.. Curiously the headers reveal this Received: from [212.69.38.60] (helo=heating-controller) by vps.templar.co.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1vLfOk-0006a6-4z for superroot@templar.co.uk; Wed, 19 Nov 2025 10:26:50 +0000 Received: by heating-controller (Postfix, from userid 0) id C459D1FE2E; Wed, 19 Nov 2025 10:21:48 +0000 (GMT) Indicating a 5 minute delay between being queued and being sent... > domaincontrol.com seems to be pretty fast from here but if for whatever > reason the network between you and domaincontrol is slow or unreliable, > or the name server you?re using is underprovisioned, then that could > explain the temporary failures here. By the time you send the another > message everything has caught up, explaining why it works on the second > attempt. > All other machines work just fine. I wonder if in fact something is swapped out on the zero. -- ?The urge to save humanity is almost always only a false face for the urge to rule it.? ? H. L. Mencken --- PyGate Linux v1.5 * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10) .