Quantcast

Why does reject_unknown_reverse_client_hostname reject this mail?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why does reject_unknown_reverse_client_hostname reject this mail?

Tobi
Hello list

recently I setup rDNS rejects for postfix via

> reject_unknown_reverse_client_hostname

in smtpd_client_restrictions in main.cf

After that I saw in the logs that mails from the ntp mailinglist get rejected

> Client host rejected: cannot find your reverse hostname,
>     [185.140.48.241]

I checked their rDNS on the same machine that rejected them and found

> 241.48.140.185.in-addr.arpa. 2731 IN    CNAME  
> 241.192/26.48.140.185.in-addr.arpa.
> 241.192/26.48.140.185.in-addr.arpa. 931    IN PTR    psp3.ntp.org.

Is that rDNS bogus so postfix "thinks" it's a unknown/broken rDNS and rejects it?

Regards

tobi


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Wietse Venema
Tobi:
> > Client host rejected: cannot find your reverse hostname,
> >     [185.140.48.241]

Here's a hint:

% host 185.140.48.241
;; connection timed out; no servers could be reached

Note that zone 48.140.185.in-addr.arpa has DNS servers with IPv4
and IPv6 addresses, but I get no reply from their IPv6 address.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Tobi
Am 16.05.2017 um 13:15 schrieb Wietse Venema:
> Tobi:
>>> Client host rejected: cannot find your reverse hostname,
>>>     [185.140.48.241]
> Here's a hint:
>
> % host 185.140.48.241
> ;; connection timed out; no servers could be reached
I can reliably resolve that ip from my server.
Since then I have a script running on the server that checks the rdns
every 5min. Not one try that could not get a rdns

host 185.140.48.241
241.48.140.185.in-addr.arpa is an alias for
241.192/26.48.140.185.in-addr.arpa.
241.192/26.48.140.185.in-addr.arpa domain name pointer psp3.ntp.org.

If you say that the above result cannot not trigger such a reject then I
would assume a timeout issue too.
I just wanted to be sure as I've never seen such a rdns reply before :-)

Thanks and regards

tobi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Wietse Venema
Tobi:
> Am 16.05.2017 um 13:15 schrieb Wietse Venema:
> > Tobi:
> >>> Client host rejected: cannot find your reverse hostname,
> >>>     [185.140.48.241]
> > Here's a hint:
> >
> > % host 185.140.48.241
> > ;; connection timed out; no servers could be reached
> I can reliably resolve that ip from my server.

Read my reply again, and pay attention to the part that
talks about IPv6.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Tobi
Hi Wietse

Sorry should have mentioned after your reply that ipv6 is disabled on all my boxes. And have postfix inet_protocol set to ipv4 anyway
So no reason for postfix to query a nameserver via ipv6. At least I do not see one :-)

Regards

tobi

----- Originale Nachricht -----
Von: Wietse Venema <[hidden email]>
Gesendet: 16.05.2017 - 16:19
An: Postfix users <[hidden email]>
Betreff: Re: Why does reject_unknown_reverse_client_hostname reject this mail?

> Tobi:
>> Am 16.05.2017 um 13:15 schrieb Wietse Venema:
>> > Tobi:
>> >>> Client host rejected: cannot find your reverse hostname,
>> >>>     [185.140.48.241]
>> > Here's a hint:
>> >
>> > % host 185.140.48.241
>> > ;; connection timed out; no servers could be reached
>> I can reliably resolve that ip from my server.
>
> Read my reply again, and pay attention to the part that
> talks about IPv6.
>
> Wietse

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Wietse Venema
Tobi:
> Hi Wietse
>
> Sorry should have mentioned after your reply that ipv6 is disabled
> on all my boxes. And have postfix inet_protocol set to ipv4 anyway
> So no reason for postfix to query a nameserver via ipv6. At least
> I do not see one :-)

Postfix does not query IPv6 DNS servers when looking up the client
hostname.

Instead, the SYSTEM LIBRARY does that. Postfix calls the getnameinfo()
system library function which goes through NSSWITCH and other Rube
Goldberg machinery to query DNS, caching daemons, local files, etc.

Considering that some Linux distros enable CHROOT for Postfix by
default, your tests may be irrelevant.

See http://www.postfix.org/DEBUG_README.html#no_chroot for how to turn
off chroot. This may fix the problem.

It may also be caused by SeLinux configuration: you did your tests
as root, and Postfix doesn't.

Or it could be even both, or something else.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Wietse Venema
Wietse Venema:

> Tobi:
> > Hi Wietse
> >
> > Sorry should have mentioned after your reply that ipv6 is disabled
> > on all my boxes. And have postfix inet_protocol set to ipv4 anyway
> > So no reason for postfix to query a nameserver via ipv6. At least
> > I do not see one :-)
>
> Postfix does not query IPv6 DNS servers when looking up the client
> hostname.
>
> Instead, the SYSTEM LIBRARY does that. Postfix calls the getnameinfo()
> system library function which goes through NSSWITCH and other Rube
> Goldberg machinery to query DNS, caching daemons, local files, etc.

In the above paragraph, Postfix does not choose whether the DNS
request will be made over IPv4 pr IPv6, so it does not matter how
Postfix is configured.

> Considering that some Linux distros enable CHROOT for Postfix by
> default, your tests may be irrelevant.

For example, the configuration setting that controls DNS lookups
may not exist inside the chroot environment.

> See http://www.postfix.org/DEBUG_README.html#no_chroot for how to turn
> off chroot. This may fix the problem.
>
> It may also be caused by SeLinux configuration: you did your tests
> as root, and Postfix doesn't.
>
> Or it could be even both, or something else.

Good luck debugging this. I expect yiu have a chroot issue.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

Tobi
Hi Wietse


Am 16.05.2017 um 20:11 schrieb Wietse Venema:
> Good luck debugging this. I expect yiu have a chroot issue.
>
as usual you are right :-)
Had chroot 'y' for several postfix processes in master.cf
After setting to 'n' and postfix restart the reverse dns check seems to
be working as expected
Just have to wait until the next mail from ntp mailinglist to be fully sure.

The only thing I do not understand yet is why forward dns resolution
worked in same chrooted environment. Also the dnsbl lookups from
postscreen always worked in chroot.
It was just rdns lookups that made problems

Thanks for your lesson in "how dns resolution works" and your patience :-)

Regards

tobi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

alias in rDNS WAS: Why does reject_unknown_reverse_client_hostname reject this mail?

Geert Stappers
In reply to this post by Tobi
On Tue, May 16, 2017 at 01:36:57PM +0200, Tobi wrote:
> host 185.140.48.241
> 241.48.140.185.in-addr.arpa is an alias for
> 241.192/26.48.140.185.in-addr.arpa.
> 241.192/26.48.140.185.in-addr.arpa domain name pointer psp3.ntp.org.
>
> If you say that the above result cannot not trigger such a reject then I
> would assume a timeout issue too.
> I just wanted to be sure as I've never seen such a rdns reply before :-)


The first I saw it, I was also surprised. Plesantly surprised.
These days I wonder why we don't see it more often??


It is named

  Classless IN-ADDR.ARPA delegation


Quoting introduction from https://tools.ietf.org/html/rfc2317

   This document describes a way to do IN-ADDR.ARPA delegation on non-
   octet boundaries for address spaces covering fewer than 256
   addresses.  The proposed method should thus remove one of the
   objections to subnet on non-octet boundaries but perhaps more
   significantly, make it possible to assign IP address space in smaller
   chunks than 24-bit prefixes, without losing the ability to delegate
   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
   method is fully compatible with the original DNS lookup mechanisms


Groeten
Geert Stappers
--
Leven en laten leven
Loading...