On Sat, Feb 15, 2025 at 07:08:20PM +0200, Nikolaos Milas via Postfix-users
wrote:
> > 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.
>
> Thank you Victor for the detailed analysis and the edns0 hint.
>
> I am pleased to report that the edns0 option worked. I did:
>
> nmcli connection modify "ens13" ipv4.dns-options "edns0"
> nmcli connection reload
> nmcli connection up ens13
>
> and following that:
>
> [root@mailgw1 postfix-tools]# time ./getaddrinfo smtpfra7.fortimailcloud.com
> Hostname: smtpfra7.fortimailcloud.com
> Addresses: 154.52.2.235 154.52.2.230 154.52.2.236 154.52.2.142
> [...]
> 154.52.2.226 154.52.2.239
>
> real 0m0.433s
> user 0m0.002s
> sys 0m0.000s
>
> So, case closed. I would think this option should have been enabled by
> default anyway?
Yes, though some then get excited about IP fragmentation attacks, that
don't happen without edns0, because the UDP packet size is then below
the IP min MTU. If your resolver is local, as it should be on an MTA,
you don't have to worry about that.
> A final question: Should we enable the same option for IPv6? (I'd guess yes,
> but please confirm.)
Yes, but what you really need is working TCP fallback, when the DNS
response is truncated due to exceeding the UDP packet size limit (even
happens with EDNS0, the default UDP buffer size could still be too small
for some queries). Just EDNS0 is not the whole story, it just pushes
out the problem to case with many more IP addresses that exceed even
the ~1.2k–~4k EDNS0 buffers (vary by implementation).
> > The Dilbert cartoon still applies, however, you may have workarounds
> > other than switching from a laptop-oriented to a server-oriented OS.
>
> Please give me a break! We have been using RHEL / CentOS / Rocky Linux
> for decades. Isn't THAT a server-oriented OS?!
Perhaps, but now likely quite dated, and the larger Linux ecosystem,
including glibc, systemd, ... has a focus that at times ends up trading
off features against robustness. But I too am now on a Linux server, it
just happens to be Fedora 41, where I don't reproduce the problem.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
