ODD DNS behaviour on Pi ZERO W with Bullseye OS

The Natural Philosopher · 2025-11-18T12:08:31+00:00

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.So I removed exim which was too much like hard work, installed PostFix and all is well...,except it isn't.If I send a mail out of the blue after a a few hours delay, the mail immediately *always* gets stuck in the queue with a message about being unable to determine the IP address of the SMTP relay.If I send another message everything Just Works, and indeed the h mail queue gets flushed eventually as well with a successful delivery.I have looked on line but not found this exact behaviour mentioned anywhere..I am not sure what is running DNS on that Zero W right now. But its clo9ck is up to date with the internet...,

Nov 18, 2025 Last reply: 8 months ago 26 Replies

Rate this thread:

Richard Kettlewell 8 months ago

Maybe, but the above doesn’t prove it; you’ve asked for an A record but Postfix asks for an MX record, so your lookup won’t have populated the cache (if there is one). (It’ll look for the A record next, but until it’s got the MX record it doesn’t know what A record to ask for.)

If there is doubt about what name server is being used you could use tcpdump to find out.

sudo tcpdump -np -i br0 udp port 53

Replace br0 with your own network interface. You’ll need to check at least loopback (lo) and any real network interfaces.

Vote

Marco Moock 8 months ago

Then make sure your postfix doesn't check that. It seems for me it does.

Vote

The Natural Philosopher 8 months ago

Dig...mx returns instantly with the correct answer too

Vote

Lawrence D’Oliveiro 8 months ago

If that were the problem, then the mail would not eventually go through. It would be blocked, and that’s that.

Vote

Lawrence D’Oliveiro 8 months ago

dnsmasq by default uses /etc/resolv.conf, unless you point it at another such file with the --resolv-file option -- obviously you have to do this to avoid circularity, if dnsmasq is supposed to be the one handling DNS requests sent to the 127.0.0.1 address.

It is normal for DNS clients to use /etc/resolv.conf. Can’t see any reason to configure any of them to use some special setting -- apart of course from a local caching DNS server like dnsmasq, or special DNS diagnostic tools like dig and host. In other words, everything that just expects to use the DNS, rather than be part of administering/troubleshooting the DNS infrastructure, should just be using /etc/resolv.conf.

dig has nothing to do with Postfix. DNS tools like dig and host implement their own low-level DNS clients, which can be configured to do queries in all kinds of ways, precisely to help with troubleshooting DNS problems.

Vote

Lawrence D’Oliveiro 8 months ago

Some DNS admins don’t like the idea of any kind of “wildcard” or “all information” queries: they want you to specifically ask for what you want, no casual browsing permitted.

Vote

Richard Kettlewell 8 months ago

That is obviously not going to cause a temporary failure looking up the MX for vps.templar.co.uk. Just look at the logfile fragment rather than guessing blindly. We know what the error is and it’s absolutely nothing to do with source address validity.

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required