On Sat, Feb 15, 2025 at 08:49:01PM +0100, Gerald Galster via Postfix-users
wrote:
> >> 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).
> >
> > I guess that should be possible by setting up a local resolver with
> > suitable features and then configure options use-vc edns0 trust-ad
> > as you suggested.
> >
> > Currently we are using our ISP's resolver.
>
> As Viktor said, you should run a local resolver.
>
> Without any configuration changes to unbound.conf and without any resolv.conf
> options, this works:
>
> [rpmbuild@centos8-dev name-addr-test]$ ./getaddrinfo
> smtpfra7.fortimailcloud.com | fmt
> Hostname: smtpfra7.fortimailcloud.com Addresses: 154.52.2.155
> 154.52.2.146 154.52.2.232 154.52.2.225 154.52.2.224 154.52.2.148
> 154.52.2.250 154.52.2.152 154.52.2.147 154.52.2.251 154.52.2.154
> 154.52.2.227 154.52.2.141 154.52.2.156 154.52.2.157 154.52.2.226
> 154.52.2.236 154.52.2.151 154.52.2.158 154.52.2.142 154.52.2.240
> 154.52.2.231 154.52.2.242 154.52.2.153 154.52.2.228 154.52.2.245
> 154.52.2.229 154.52.2.243 154.52.2.248 154.52.2.241 154.52.2.235
> 154.52.2.233 154.52.2.238 154.52.2.239 154.52.2.149 154.52.2.234
> 154.52.2.246 154.52.2.237 154.52.2.247 154.52.2.249 154.52.2.244
> 154.52.2.150 154.52.2.143 154.52.2.145 154.52.2.230 154.52.2.144
I see, so the real problem seems to be that the *ISP* resolver does not
support TCP. It just sends truncated responses, and provides no means
of recovery. The Linux stack tries a TCP connection and just times out.
If so, it is appropriate to retract dispersions cast on Rocky, and put
the blame where it belongs. The ISP is the problem. The OP can for
example test with a suitable subset of 1.1.1.1, 8.8.8.8 and 9.9.9.10,
and of course better still run a local validating resolver.
Avoiding the ISP's busted DNS will very likely solve the real underlying
problem, but edns0 is still worth doing too.
https://datatracker.ietf.org/doc/html/rfc7766
Abstract
This document specifies the requirement for support of TCP as a
transport protocol for DNS implementations and provides guidelines
towards DNS-over-TCP performance on par with that of DNS-over-UDP.
This document obsoletes RFC 5966 and therefore updates RFC 1035 and
RFC 1123.
https://datatracker.ietf.org/doc/html/rfc7766#section-1
The majority of DNS server operators already support TCP, and the
default configuration for most software implementations is to support
TCP. The primary audience for this document is those implementors
whose limited support for TCP restricts interoperability and hinders
deployment of new DNS features.
This document therefore updates the core DNS protocol specifications
such that support for TCP is henceforth a REQUIRED part of a full DNS
protocol implementation.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
