Subj : Re: ODD DNS behaviour on Pi ZERO W with Bullseye OS To : All From : Richard Kettlewell Date : Wed Nov 19 2025 08:50:15 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. 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? 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. 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. 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. -- https://www.greenend.org.uk/rjk/ --- PyGate Linux v1.5 * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10) .