>It's absolutely not forwarding. It's resolving recursively. I'm using
unbound with pfsense and I'm suspecting there is something wrong with it.
>When I point to MS DNS server or 9.9.9.9, it's resolving correctly.
The issue has been resolved. Just in case someone finds the solution useful,
>In any case, the OP may well be using a local resolver, but they didn't say
whether it's resolving recursively or forwarding (e.g. to 8.8.8.8), and I'd
bet it's the latter.
It's absolutely not forwarding. It's resolving recursively. I'm using
unbound with pfsense and I'm suspecting there is
On Tue, 9 Aug 2022, Bill Cole wrote:
On 2022-08-09 at 12:50:22 UTC-0400 (Tue, 9 Aug 2022 12:50:22 -0400)
Dino Edwards
is rumored to have said:
Let's do some concreate tests.
1) What is the output from:
dig +short 2.0.0.127.zen.spamhaus.org
Output is nothing
Your DNS resolver is
Dino Edwards:
>
>
> >Let's do some concreate tests.
>
> >1) What is the output from:
>
> > dig +short 2.0.0.127.zen.spamhaus.org
>
> Output is nothing
There should be a list of responses, as pointed out by Bill Cole
(or an error response if you are using a provider's resolver).
On 2022-08-09 at 12:50:22 UTC-0400 (Tue, 9 Aug 2022 12:50:22 -0400)
Dino Edwards
is rumored to have said:
>> Let's do some concreate tests.
>
>> 1) What is the output from:
>
>> dig +short 2.0.0.127.zen.spamhaus.org
>
> Output is nothing
Your DNS resolver is broken. That's a test name which
On Tue, Aug 09, 2022 at 04:22:44PM +0100, Tom McLoughlin wrote:
> > The resumption problem can be worked around by setting the server-side
> > session cache database empty (the default setting):
> >
> >smtpd_tls_session_cache_database =
> >
> > This is the recommended setting, since clients
Viktor,
Thanks for getting back to me.
> The resumption problem can be worked around by setting the server-side
> session cache database empty (the default setting):
>
>smtpd_tls_session_cache_database >
> This is the recommended setting, since clients should be using session
> tickets
Dino Edwards:
>
> << I suggest that you start with dig/nslookup and establish that you have
> properly working DNS, and that your ISP is not replacing all "not found"
> responses with the IP address of some "helpful" website.
>
> Using local DNS servers and not ISP servers. DNS is working as it
On Tue, Aug 09, 2022 at 02:27:17PM +0100, Tom McLoughlin wrote:
> Recently started receiving this error and unable to find any solution to
> this, any ideas?
>
> |OpenSSL version: OpenSSL 3.0.4 21 Jun 2022 (Library: OpenSSL 3.0.4 21
> Jun 2022) Postfix version: mail_version = 3.6.4 Dovecot
Wietse,
Thanks for getting back to me so quickly.
I’ve currently got 2 servers running postfix in a RR config, the first when a
connection is made by my client (Apple Mail) throws this error, however the
second throws no error at all; the configuration is identical as the connection
is
I suggest that you start with dig/nslookup and establish that you
have properly working DNS, and that your ISP is not replacing all
"not found" responses with the IP address of some "helpful" website.
Wietse
Tom McLoughlin:
> Hello,
>
> Recently started receiving this error and unable to find any solution to
> this, any ideas?
>
> |OpenSSL version: OpenSSL 3.0.4 21 Jun 2022 (Library: OpenSSL 3.0.4 21
> Jun 2022) Postfix version: mail_version = 3.6.4 Dovecot version:
> 2.3.19.1 (9b53102964)|
>
>
Hello,
Recently started receiving this error and unable to find any solution to
this, any ideas?
|OpenSSL version: OpenSSL 3.0.4 21 Jun 2022 (Library: OpenSSL 3.0.4 21
Jun 2022) Postfix version: mail_version = 3.6.4 Dovecot version:
2.3.19.1 (9b53102964)|
Log lines:
|Aug 7 22:10:46 mail
13 matches
Mail list logo
