Re: Failure to check FCrDNS with long DNS replies?

[Tassilo Philipp]

Mhmm… but they returned different results, for dig vs OpenSMTPd filter lookup? 


Not sure, as I don't log the replies, but I don't think so.


May cache TTL have expired and record re-fetched with your local test? 
What’s your local cache software, is it able to handle large A record lists? 


It's "unbound", so yes, it should handle that just fine. The result I 
pasted was also queried through it.



In regards to the dnscrypt servers, are you sure you hit the same 
recursive resolver with dig as with OpenSMTPd filter before?


Absolutely, I enforced a single one for a test, namely soltysiak.


If you can reproduce, this would indeed point to an issue in the 
filter or local cache.  But that case should be easy test by just 
sending some test-mails from a sfr.fr  account? 


Correct. Unfortunately I don't know anyone with such an account, and 
wanted to setup just a local test, faking it, to at least be able to 
exclude opensmtp as a culprit.


In the end I just disabled the check, as one email user was desperately 
waiting for a mail that was affected, and I saw it in the logs being 
rejected over and over again, and I hade some others spinning plates to 
handle at that time. Now I have a bit more time and headspace again and 
can look into it more.



Maybe someone subscribed to this list has such an account and could send 
you a test mail?


That would be terrific!

Re: Failure to check FCrDNS with long DNS replies?

[Joerg Jung]

> On 3. Aug 2020, at 12:23, Tassilo Philipp  wrote:
> 
> Thanks for the reply and your thoughts.
> 
>> There should be nothing limit FCrDNS here, despite that
>> these are a lot of records.
>> 
>> But have you tried the dig lookup below from the actual mail
>> server at the time (or shortly after) the time of the failure?
> 
> Yes, that was the first thing I tried, and I had those delivery failures 
> before and after that test. (In fact, I changed the error message to one 
> specific to the fcrdns check, restarted opensmtp and waited for the next 
> delivery attempt).
> 
> After that I started looking into the sources of OpenSMTPd and all I found 
> was a loop running over all records in the reply, so yeah, no limitation 
> there.
> 
> 
>> While the DNS record seems to be there and correct:
>> At the time of the connect your mail server was not be able to resolve the 
>> record through whatever you have configured as forwarder/lookup/recursive 
>> DNS servers.
>> Reasons can vary from local provider network hiccup to
>> global BGP issues.
>> Your mail server may use a different route and different
>> lookup servers than your local client you test dig command with.
> 
> It's a local DNS cache which forwards to some dnscrypt servers. I verified 
> from the logs that my manual name resolution test I did, and the lookup from 
> OpenSMTPd did use the same resolution.


Mhmm… but they returned different results, for dig vs OpenSMTPd filter lookup?
May cache TTL have expired and record re-fetched with your local test? 
What’s your local cache software, is it able to handle large A record lists?
In regards to the dnscrypt servers, are you sure you hit the same recursive 
resolver 
with dig as with OpenSMTPd filter before?

If you can reproduce, this would indeed point to an issue in the filter or 
local cache.
But that case should be easy test by just sending some test-mails from 
a sfr.fr  account?
Maybe someone subscribed to this list has such an account and could send
you a test mail?

Re: Failure to check FCrDNS with long DNS replies?

[Tassilo Philipp]

Thanks for the reply and your thoughts.


There should be nothing limit FCrDNS here, despite that
these are a lot of records.

But have you tried the dig lookup below from the actual mail
server at the time (or shortly after) the time of the failure?


Yes, that was the first thing I tried, and I had those delivery failures 
before and after that test. (In fact, I changed the error message to one 
specific to the fcrdns check, restarted opensmtp and waited for the next 
delivery attempt).


After that I started looking into the sources of OpenSMTPd and all I 
found was a loop running over all records in the reply, so yeah, no 
limitation there.




While the DNS record seems to be there and correct:
At the time of the connect your mail server was not be able to 
resolve the record through whatever you have configured as 
forwarder/lookup/recursive DNS servers.

Reasons can vary from local provider network hiccup to
global BGP issues.
Your mail server may use a different route and different
lookup servers than your local client you test dig command with.


It's a local DNS cache which forwards to some dnscrypt servers. I 
verified from the logs that my manual name resolution test I did, and 
the lookup from OpenSMTPd did use the same resolution.




I have often seen local ISP forwarding DNS servers being
blocked by other large ISP DNS servers already,
e.g. Hetzner DNS recursive Forwarders (and even
whole Hetzner netblocks) are blocked by Telekom
authoritative DNS servers, due to abuse reasons. 


Yeah, I hear you, I had similar experiences in the past, one also with 
Telekom btw., in our case it was for an online game, and we ultimately 
needed to tell players that were affected to "tunnel around" some hop in 
Frankfurt, as it was impossible to get in contact with anyone at 
Telekom that was able or willing to get us in contact with the 
technicians, there. After like 2 months that route was fine again.




I also have similar experiences the other way around with
other ISPs blocking Telekom forwarders, etc.

Sometimes you may be able to contact abuse/tech addresses
to get the relevant IPs unblocked, but often this is just
temporary anyways.

Not everything is reachable from everywhere as it should be.
This happens all the time. This is the Internet.


This is very true, this is the internet.

While looking into this I was just really surprised to see the long list 
of A records this resolves to and it felt like this was maybe the 
culprit... everything else worked fine and no other mail server 
connecting was rejected that way.


I'll reenable the fcrdns check again, and see what happens. It was 
disabled now for a while b/c of a user depending on some mails coming 
from SFR.


Thanks for the feedback!