Re: Timeout setting
> On 26 Mar 2021, at 20:44, FUSTE Emmanuel > wrote: > > Le 25/03/2021 à 22:15, Mark Andrews a écrit : >> This is a bug in postfix. Temporary failures in the DNS are not supposed to >> result in permanent failure at the SMTP level. SERVFAIL is not NXDOMAIN. >> > This is not a postfix bug. Temporary failure are perfectly handled by > postfix with a 450 SMTP temporary error, not a 550 permanent error. > > 450 4.7.1 Client host rejected: cannot find your reverse hostname, > [17.179.250.111]; from= > to= proto=ESMTP helo= > (total: 1) Fine. I shouldn’t comment before my first cup of tea in the morning. > You should have OS/network configuration problems. Such timeout are > completely unnatural. Timeouts will happen. Networks aren’t perfect. Links can be congested. Links can be noisy. Hosts can be congested. Hosts can be down. There can be routing failures. There are those that configure their DNS such that it requires excessive numbers of lookups to actually resolve an lookup. Then there are those that drop ICMP and fragmented packets breaking legitimate traffic flows. There is a reason there are 400 codes for DNS lookup failures. > Emmanuel. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Timeout setting
Le 25/03/2021 à 22:15, Mark Andrews a écrit : > This is a bug in postfix. Temporary failures in the DNS are not supposed to > result in permanent failure at the SMTP level. SERVFAIL is not NXDOMAIN. > This is not a postfix bug. Temporary failure are perfectly handled by postfix with a 450 SMTP temporary error, not a 550 permanent error. 450 4.7.1 Client host rejected: cannot find your reverse hostname, [17.179.250.111]; from= to= proto=ESMTP helo= (total: 1) You should have OS/network configuration problems. Such timeout are completely unnatural. Emmanuel. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Timeout setting
This is a bug in postfix. Temporary failures in the DNS are not supposed to result in permanent failure at the SMTP level. SERVFAIL is not NXDOMAIN. -- Mark Andrews > On 26 Mar 2021, at 04:12, Julien Salort wrote: > > Hello, > > > I have a VPS running postfix and bind9. Bind is used as a recursive resolver, > in particular to be able to query anti-spam database. > > Postfix is also configured to reject incoming connections from servers with > no reverse dns. > > It works great overall, but sometimes legitimate messages get rejected > because the reverse dns query fails. > > Here is an example (anonymized email and host address): > > In mail.log: > > 450 4.7.1 Client host rejected: cannot find your reverse hostname, > [17.179.250.111]; from= > to= proto=ESMTP helo= (total: > 1) > > In named journal: > > mars 02 01:14:20 example.com named[2756114]: client @0x7f3a0808c750 > 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: > 111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1) > > mars 02 01:14:25 example.com named[2756114]: client @0x7f3a08079d00 > 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: > 111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1) > > mars 02 01:14:32 example.com named[2756114]: client @0x7f3a0808c750 > 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query failed (timed out) for > 111.250.179.17.in-addr.arpa/IN/PTR at query.c:6883 > > mars 02 01:14:32 example.com named[2756114]: client @0x7f3a000d5110 > 127.0.0.1#49520 (insideapple.apple.com): query: insideapple.apple.com IN MX + > (127.0.0.1) > > > So there is a timeout. > > Now if I try again: > > $ dig -x 17.179.250.111 @localhost +short > rn2-msbadger07105.apple.com. > > > So it seems that it is just that sometimes the query takes a bit longer... > > > Is there a general advice regarding timeout for bind? > > Should I just choose a longer timeout? Or is there a reason for the default > value? > > > I did not have such problems when I was using the ISP dns server instead of a > local recursive resolver. So I was wondering if the configuration is > sub-optimal somehow... > > > Thank you, > > > Cheers, > > > Julien > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Timeout setting
Le 25/03/2021 à 18:21, John W. Blue via bind-users a écrit : When I queried the authoritative server directly it worked: ;; QUESTION SECTION: ;111.250.179.17.in-addr.arpa. IN PTR ;; ANSWER SECTION: 111.250.179.17.in-addr.arpa. 86400 IN PTR rn2-msbadger07105.apple.com. ;; Query time: 62 msec ;; SERVER: 17.47.176.10#53(17.47.176.10) I would recommend that you too do a dig @ and see what you get. If it works then you can start examining your on prim configs .. if it does not work then you need to be using wireshark to figure out what is happening to the traffic. Either way you need to first break your troubleshooting into two parts .. on prim vs off prim and proceed from there. Thank you for your answer. If I query either authoritative server with dig, or the local recursive server, it works in both cases (though I get 164 msec, instead of your 62 msec, presumably because I am based in Europe; I guess 100 msec to cross the Atlantic ocean is not too bad): ;; QUESTION SECTION: ;111.250.179.17.in-addr.arpa. IN PTR ;; ANSWER SECTION: 111.250.179.17.in-addr.arpa. 86400 IN PTR rn2-msbadger07105.apple.com. ;; Query time: 164 msec ;; SERVER: 17.47.176.10#53(17.47.176.10) Besides, I have other messages from the same source that do get delivered. Even the particular message that was originally rejected, was eventually accepted when the relay tried again later. I have not been able to reproduce the timed out result from command line. It seems to be a rare occurrence. I have also an example with messages from this list: I usually receive them, but three messages from today failed (they have actually been sent to my backup mx, so I still received them in the end). Julien ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Timeout setting
When I queried the authoritative server directly it worked: ;; QUESTION SECTION: ;111.250.179.17.in-addr.arpa. IN PTR ;; ANSWER SECTION: 111.250.179.17.in-addr.arpa. 86400 IN PTR rn2-msbadger07105.apple.com. ;; Query time: 62 msec ;; SERVER: 17.47.176.10#53(17.47.176.10) I would recommend that you too do a dig @ and see what you get. If it works then you can start examining your on prim configs .. if it does not work then you need to be using wireshark to figure out what is happening to the traffic. Either way you need to first break your troubleshooting into two parts .. on prim vs off prim and proceed from there. Good hunting. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Julien Salort Sent: Thursday, March 25, 2021 12:11 PM To: bind-users@lists.isc.org Subject: Timeout setting Hello, I have a VPS running postfix and bind9. Bind is used as a recursive resolver, in particular to be able to query anti-spam database. Postfix is also configured to reject incoming connections from servers with no reverse dns. It works great overall, but sometimes legitimate messages get rejected because the reverse dns query fails. Here is an example (anonymized email and host address): In mail.log: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [17.179.250.111]; from= to= proto=ESMTP helo= (total: 1) In named journal: mars 02 01:14:20 example.com named[2756114]: client @0x7f3a0808c750 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1) mars 02 01:14:25 example.com named[2756114]: client @0x7f3a08079d00 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1) mars 02 01:14:32 example.com named[2756114]: client @0x7f3a0808c750 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query failed (timed out) for 111.250.179.17.in-addr.arpa/IN/PTR at query.c:6883 mars 02 01:14:32 example.com named[2756114]: client @0x7f3a000d5110 127.0.0.1#49520 (insideapple.apple.com): query: insideapple.apple.com IN MX + (127.0.0.1) So there is a timeout. Now if I try again: $ dig -x 17.179.250.111 @localhost +short rn2-msbadger07105.apple.com. So it seems that it is just that sometimes the query takes a bit longer... Is there a general advice regarding timeout for bind? Should I just choose a longer timeout? Or is there a reason for the default value? I did not have such problems when I was using the ISP dns server instead of a local recursive resolver. So I was wondering if the configuration is sub-optimal somehow... Thank you, Cheers, Julien ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
