MSGID: 04882df5
REPLY: <10fiosn$1rgr7$1@dont-email.me> b2f303ba
PID: PyGate 1.5
TID: PyGate/Linux 1.5
CHRS: CP1252 2
TZUTC: 0000
REPLYADDR invalid@invalid.invalid
REPLYTO 3:633/10 UUCP
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)
SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700
SEEN-BY: 226/30 227/114 229/110 112 200 206 275 300 317 400 426 428
SEEN-BY: 229/470 616 664 700 705 266/512 291/111 292/854 320/219 322/757
SEEN-BY: 342/200 396/45 460/58 633/10 280 414 418 420 422 509 2744
SEEN-BY: 712/848 770/1 902/26 2320/105 5020/400 5075/35
PATH: 633/10 280 229/426
|
