On Sat, Feb 15, 2025 at 04:45:41PM +0200, Nikolaos Milas via Postfix-users
wrote:
> > I don't recall seeing you testing with "getaddrinfo" (and perhaps also
> > "getnameinfo" to see whether it is slow PTR lookup that is the problem).
> > It may also help to perform tcpdumps to see how long the delay is
> > between that client connecting and the Postfix 220 greeting.
>
> You are right Victor.
Too often perhaps (I've been cursed with that affliction).
> ===========================================================================
> On: mailgw1.noa.gr
> ------------------
>
> [root@mailgw1 postfix-tools]# time ./getaddrinfo smtpfra7.fortimailcloud.com
> host smtpfra7.fortimailcloud.com not found: Name or service not known
>
> real 6m34.031s
> user 0m0.000s
> sys 0m0.004s
Well, now we have data! This explains the observed symptoms. But it is
not yet clear whether the issue is a bug in the library or a problem
with your configuration.
Have you tried adding "options edns0" to your resolv.conf? The "A"
RRset for this name exceeds 512 bytes, and so, absent edns0 can only be
returned via TCP, and some Linux versions had no TCP fallback support in
the libc resolver.
FWIW, even in far away Australia, I get:
$ time ./getaddrinfo smtpfra7.fortimailcloud.com
Hostname: smtpfra7.fortimailcloud.com
Addresses: 154.52.2.251 154.52.2.148 154.52.2.245 154.52.2.248
154.52.2.229 154.52.2.238 154.52.2.145 154.52.2.149 154.52.2.155
154.52.2.231 154.52.2.154 154.52.2.143 154.52.2.152 154.52.2.156
154.52.2.249 154.52.2.226 154.52.2.146 154.52.2.250 154.52.2.225
154.52.2.233 154.52.2.241 154.52.2.244 154.52.2.157 154.52.2.246
154.52.2.243 154.52.2.247 154.52.2.237 154.52.2.141 154.52.2.150
154.52.2.151 154.52.2.239 154.52.2.242 154.52.2.144 154.52.2.240
154.52.2.236 154.52.2.147 154.52.2.153 154.52.2.224 154.52.2.235
154.52.2.228 154.52.2.227 154.52.2.232 154.52.2.158 154.52.2.230
154.52.2.234 154.52.2.142
real 0m0.004s
user 0m0.000s
sys 0m0.003s
> [root@mailgw1 postfix-tools]# time dig +short -t a
> smtpfra7.fortimailcloud.com | sort | fmt
> 154.52.2.141 154.52.2.142 154.52.2.143 154.52.2.144 154.52.2.145
> 154.52.2.146 154.52.2.147 154.52.2.148 154.52.2.149 154.52.2.150
> 154.52.2.151 154.52.2.152 154.52.2.153 154.52.2.154 154.52.2.155
> 154.52.2.156 154.52.2.157 154.52.2.158 154.52.2.224 154.52.2.225
> 154.52.2.226 154.52.2.227 154.52.2.228 154.52.2.229 154.52.2.230
> 154.52.2.231 154.52.2.232 154.52.2.233 154.52.2.234 154.52.2.235
> 154.52.2.236 154.52.2.237 154.52.2.238 154.52.2.239 154.52.2.240
> 154.52.2.241 154.52.2.242 154.52.2.243 154.52.2.244 154.52.2.245
> 154.52.2.246 154.52.2.247 154.52.2.248 154.52.2.249 154.52.2.250
> 154.52.2.251
>
> real 0m0.032s
> user 0m0.007s
> sys 0m0.006s
The "dig" command will always use edns0. Is the resolver in your
/etc/resolv.conf local (loopback) or remote? What happens if when
you try:
$ dig +noedns +ignore smtpfra7.fortimailcloud.com
> As you can see:
>
> 1. getaddrinfofails on both systems (Rocky 8 and 9) on ALL my tests until
> now.
But the issue may be a combination of lack of TCP fallback in the
resolver and edns0 not being default enabled. If the resolver is local
(loopback), and your mail volume is low to modest you might do better
with:
options use-vc edns0 trust-ad
> 2. getaddrinfo works fine in other cases (for the test I used the primary MX
> of bbc.co.uk).
The responses are much smaller.
> 4. getnameinfo works fine every time.
The response is a single PTR record.
> I believe you could reproduce the above results on any Rocky 8 / 9
> box.
Plausible, provided the configuration is similar,
> I hope the above tests may be of help in troubleshooting the problem:
> Why getaddrinfo fails with smtpfra7.fortimailcloud.com?
>
> I am at your disposal for any additional tests and I look forward to your
> advice.
The Dilbert cartoon still applies, however, you may have workarounds
other than switching from a laptop-oriented to a server-oriented OS.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
