450 4.7.1 Client host rejected: cannot find your reverse hostname, [XXX.XXX.XXX.XXX] #85
Comments
|
This issue is known. |
|
look at this #52 |
|
Closed with new master. |
|
Actually my issue hasn't being fixed. Here is the log from bind9 Attaching to mailcowdockerized_bind9-mailcow_1 Perhaps something else is going on.. |
|
I don't see any errors in the log. |
|
I get this back: nslookup -q=ptr 192.30.252.194 172.22.1.254 ** server can't find 194.252.30.192.in-addr.arpa: SERVFAIL |
|
and |
|
This is very odd $ nslookup -q=ptr 192.30.252.194 8.8.8.8 $ nslookup -q=ptr 192.30.252.194 Non-authoritative answer: |
|
Check your Docker installation and iptables. Something may be overriding the netfilter rules by Docker.
… Am 05.03.2017 um 09:56 schrieb Stratos Goudelis ***@***.***>:
This is very odd
$ nslookup -q=ptr 192.30.252.194 8.8.8.8
;; connection timed out; no servers could be reached
$ nslookup -q=ptr 192.30.252.194
Server: 46.28.201.21
Address: 46.28.201.21#53
Non-authoritative answer:
194.252.30.192.in-addr.arpa name = github-smtp2-ext3.iad.github.net.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I fixed my issue by adding forwarders in the bind configuration. |
|
@sgoudelis i could be wrong, but i'd give a huge NO on forwarders. Especially if you set those to some large known resolvers, like google dns. Most DNSBL limit or block queries from large public dns. I guess mailcow has tests in place that you don't use 4x8 but i don't know if that's done at setup time and can spot later modifications. |
|
Hi, Today I just deployed mailcow to a new fresh Centos 7,2 installation. The same thing happened to me. It prevented the server to receive mail from google. The docker already uses bind9. |
|
You should check the bind9 container logs. And please try to ping google.com from one of the containers. |
|
I really cannot do anything as this does not happen on any of my test boxes. Without any logs or information about the firewall, there is nothing I can change to fix it. :/ |
|
Pinging works from bind9 container. And for the logs, there are lots happening here. 7-May-2017 10:10:02.706 FORMERR resolving './NS/IN': 192.228.79.201#53 |
|
Hi, i just tried pinging from postfix box, it says unknown host. Any idea how to trace the reason for this? The thing is, i issue a ping request to my local website and it reports an unknown, which is weird. |
|
And the bind container logs?
… Am 27.05.2017 um 11:56 schrieb ferdisn ***@***.***>:
Hi, Today I just deployed mailcow to a new fresh Centos 7,2 installation.
The same thing happened to me. It prevented the server to receive mail from google.
The docker already uses bind9.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I put my log in the previous comment. I do assume that this is caused by DNSSEC.
|
|
Hi, just want to add up. After disabling DNSSEC
I manage to receive the email. EDIT: only for a moment. Afterwards, email starts getting rejected again. |
|
What's in the logs after disabling DNSSEC? |
|
I just had this issue and the suggestion above from @sgoudelis regarding "adding forwarders in the bind configuration" solved the issue for me, note that when editing the And then restart the container: Also note that the container doesn't contain |
|
Public servers? That will break blacklist lookups. Or you will at least be heavily rate limited.
What happened before it stopped resolving? What's in the bind logs?
You should not need to enter the bind containers shell. Either check its logs or run nslookup, ping, dig etc. from phpfpm to Test the resolver. :)
… Am 27.05.2017 um 14:50 schrieb ferdisn ***@***.***>:
Hi, just want to add up. After disabling DNSSEC
option { dnssec-enable no; dnssec-validation no; }
I manage to receive the email.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@andryyy no not public DNS servers, two DNS servers that we are running for our own subnet and they don't rate limit for local requests. Where are the bind logs? The errors that the mail server that was trying to send email to the Mailcow server had in it's Postfix logs were like this: Good to hear that "You should not need to enter the bind containers shell." as I was struggling to find many useful tools... no |
|
Hi @chriscroome are the said dns servers using different gateway compared to your mailcow server? |
|
@ferdisn no, same subnet, same gateway. |
|
Hello guys again, Unfortunately, my VPS provider does not allow using any other DNS server than their own. Can someone give some instructions on what needs to be modified to make the whole system work even without blacklisted DNS lookups ? |
|
Also I am getting this due to the same fact.
|
|
I recommend to switch your provider, seriously. :-( |
|
Understood and I agree with you. In the mean time can someone please tell what needs to change in order to make the whole stack use a custom set of dns servers ? Even with reduced capability. |
|
You can try to remove all sections from docker-compose.yml, then it falls back to Docker's built-in DNS proxy. Or you can replace |
|
Yeap that worked. Thank you very much. Can you tell what exactly or approximately I lost by doing this ? |
|
|
Thank you for the information |
Hello,
I recently installed mail cow on my VPS box and I getting this error message all the time after when I try to send an email to an address under the mailcow system. I have also found perhaps the source of the problem here:
Attaching to mailcowdockerized_pdns-mailcow_1
pdns-mailcow_1 | Mar 03 16:24:00 PowerDNS Recursor 4.0.4 (C) 2001-2016 PowerDNS.COM BV
pdns-mailcow_1 | Mar 03 16:24:00 Using 64-bits mode. Built using gcc 5.4.0 20160609 on Jan 13 2017 09:37:53 by root@2e330ddb85a7.
pdns-mailcow_1 | Mar 03 16:24:00 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
pdns-mailcow_1 | Mar 03 16:24:00 Reading random entropy from '/dev/urandom'
pdns-mailcow_1 | Mar 03 16:24:00 If using IPv6, please raise sysctl net.ipv6.route.max_size, currently set to 4096 which is < 16384
pdns-mailcow_1 | Mar 03 16:24:00 NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable
pdns-mailcow_1 | Mar 03 16:24:00 Only allowing queries from: 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8
pdns-mailcow_1 | Mar 03 16:24:00 Will not send queries to: 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10, 0.0.0.0/8, 192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 240.0.0.0/4, ::/96, ::ffff:0:0/96, 100::/64, 2001:db8::/32, 0.0.0.0, ::
pdns-mailcow_1 | Mar 03 16:24:00 PowerDNS Recursor itself will distribute queries over threads
pdns-mailcow_1 | Mar 03 16:24:00 Redirecting queries for zone 'mailcow-network.' with recursion to: 127.0.0.11:53
pdns-mailcow_1 | Mar 03 16:24:00 Inserting rfc 1918 private space zones
pdns-mailcow_1 | Mar 03 16:24:00 Listening for UDP queries on 0.0.0.0:53
pdns-mailcow_1 | Mar 03 16:24:00 Enabled TCP data-ready filter for (slight) DoS protection
pdns-mailcow_1 | Mar 03 16:24:00 Listening for TCP queries on 0.0.0.0:53
pdns-mailcow_1 | Mar 03 16:24:00 Set effective group id to 106
pdns-mailcow_1 | Mar 03 16:24:00 Set effective user id to 105
pdns-mailcow_1 | Mar 03 16:24:00 Launching 3 threads
pdns-mailcow_1 | Mar 03 16:24:00 Done priming cache with root hints
pdns-mailcow_1 | Mar 03 16:24:00 Done priming cache with root hints
pdns-mailcow_1 | Mar 03 16:24:00 Done priming cache with root hints
pdns-mailcow_1 | Mar 03 16:24:00 Enabled 'epoll' multiplexer
pdns-mailcow_1 | Mar 03 16:24:08 Failed to update . records, got an exception
pdns-mailcow_1 | Mar 03 16:24:08 Failed to update . records, RCODE=-1
pdns-mailcow_1 | Mar 03 16:24:09 Failed to update . records, got an exception
For some reason the pdns-recursor cannot fetch the root DNS zones ?
Any ideas ?
The text was updated successfully, but these errors were encountered: