My DNS queries were seem refused

[lowhigh]

Who 'owns' the server at the zimbraDNSMasterIP address? Is this under your control? Can you do a DNS lookup using the server? In any case, have you tried changing the zimbraDNSMasterIP to something else such as "1.1.1.1" or one of your choice?

This zimbraDNSMasterIP 203.162.0.181 own by ISP but everyone can lookup using this DNS server.
After change zimbraDNSMasterIP to 1.1.1.1, the situation still no change

Sep 21 17:41:05 mail amavis[8919]: (08919-02) _WARN: dns: sendto() to [127.0.0.1]:53 failed: Operation not permitted, failing over to [::1]:53
Sep 21 17:41:05 mail amavis[8919]: (08919-02) _WARN: dns: sendto() to [::1]:53 failed: Connection refused, failing over to [127.0.0.1]:53
Sep 21 17:41:05 mail amavis[8919]: (08919-02) _WARN: dns: sendto() to [127.0.0.1]:53 failed: Operation not permitted, no more alternatives
Sep 21 17:41:05 mail amavis[8919]: (08919-02) _WARN: dns: sendto() to [127.0.0.1]:53 failed: Operation not permitted, failing over to [::1]:53
Sep 21 17:41:05 mail amavis[8919]: (08919-02) SA info: dns: bad dns reply: bgread: recv() failed: Connection refused at /opt/zimbra/common/lib/perl5/Mail/SpamAssassin/DnsResolver.pm line 743.
Sep 21 17:41:05 mail amavis[8919]: (08919-02) SA info: dns: bad dns reply: bgread: recv() failed: Connection refused at /opt/zimbra/common/lib/perl5/Mail/SpamAssassin/DnsResolver.pm line 743.
Sep 21 17:41:08 mail amavis[8919]: (08919-02) SA info: dns: bad dns reply: bgread: recv() failed: Connection refused at /opt/zimbra/common/lib/perl5/Mail/SpamAssassin/DnsResolver.pm line 743.

[JDunphy]

This is quite the mystery.

Is there a local ip table here? That sendto failing to 127.0.0.1 is really suspicious. The bgread tells us that it was an udp packet but that the socket had a read error when it attempted to recv from it.
If you have iptables on this box, have you verified that you don't have a bunch of nf_conntrack: table full, dropping packet" in syslog.

What is odd is that I get that the client resolver might not get any answer from your local resolver. I do not get why your local resolver would refuse the connection.

It feels like a FW issue. Have you any dynamic rules like ipsets that could be firing from unsual acitivty loads. I know one of the tricks we sometime see is with spammers with tons of NS records and then rejecting our resolvers attempts to verify the reverse so we go down the line looking for the next server. It puts on quite the 'RCODE refused' show with named. LOL

Code: Select all

Sep 21 05:54:30 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.139.178.48#53
Sep 21 05:54:30 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.136.192.12#53
Sep 21 05:54:30 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 120.196.165.40#53
Sep 21 05:54:35 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.139.178.48#53
Sep 21 05:54:35 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.136.192.12#53
Sep 21 05:54:35 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 120.196.165.40#53
Sep 21 05:54:37 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.139.178.48#53

Our noc has a swatch monitor up watching for syslog patterns and it will turn red when these errors are displayed because we track errors with red on the monitor. I saw one last week with 20+ NS records and they connected repeatedly before our dynamic ipset rules put them in timeout for 4 hr. Always something isn't it?

[lowhigh]

This is quite the mystery.

Is there a local ip table here? That sendto failing to 127.0.0.1 is really suspicious. The bgread tells us that it was an udp packet but that the socket had a read error when it attempted to recv from it.
If you have iptables on this box, have you verified that you don't have a bunch of nf_conntrack: table full, dropping packet" in syslog.

What is odd is that I get that the client resolver might not get any answer from your local resolver. I do not get why your local resolver would refuse the connection.

It feels like a FW issue. Have you any dynamic rules like ipsets that could be firing from unsual acitivty loads. I know one of the tricks we sometime see is with spammers with tons of NS records and then rejecting our resolvers attempts to verify the reverse so we go down the line looking for the next server. It puts on quite the 'RCODE refused' show with named. LOL

Code: Select all

Sep 21 05:54:30 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.139.178.48#53
Sep 21 05:54:30 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.136.192.12#53
Sep 21 05:54:30 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 120.196.165.40#53
Sep 21 05:54:35 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.139.178.48#53
Sep 21 05:54:35 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.136.192.12#53
Sep 21 05:54:35 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 120.196.165.40#53
Sep 21 05:54:37 relay10 named[971]: error (unexpected RCODE REFUSED) resolving '18.186.239.120.in-addr.arpa/PTR/IN': 211.139.178.48#53

Our noc has a swatch monitor up watching for syslog patterns and it will turn red when these errors are displayed because we track errors with red on the monitor. I saw one last week with 20+ NS records and they connected repeatedly before our dynamic ipset rules put them in timeout for 4 hr. Always something isn't it?

Thanks everybody for your susgests!

I was upset for 3 days from this issue raises, SA includes DCC, DNS Blocklist and Razor, Pyzor seem cannot connect to get data, so the system immediately was attacked by SPAM, even the SPF module also doesnot work when it always said that: Gmail has no correct SPF record......

Many many errors related Host not found or Domain cannnot lookup although i change DNS master anymore.....

With "Operation not permitted" i think it's related permission but zmfixperms don't think like this, everything is good.
With "dns: bad dns reply" this clue drives me to check the queries to DNS but when i manually queried, it's seem OK.
Finally, i found that some queries are good, some queries are bad because the firewall block UDP due to a Outbound UDP Flood rule. This rule limit 20 connections/s.
I disabled this rule for 24h till now, everything come back like before. SPAM was denied by DNS Blocklist and DCC, Razor + Pyzor score count again and SPF module works as a gate keeper.

The problem was RESOLVED, thanks everybody so much!

[davidkillingsworth]

Finally, i found that some queries are good, some queries are bad because the firewall block UDP due to a Outbound UDP Flood rule. This rule limit 20 connections/s.
I disabled this rule for 24h till now, everything come back like before. SPAM was denied by DNS Blocklist and DCC, Razor + Pyzor score count again and SPF module works as a gate keeper.

The problem was RESOLVED, thanks everybody so much!

Hi guys, I am having something very similar, which I highlighted in this viewtopic.php?f=15&t=66112 seperate zimbra forum thread.

Some of my DKIM verification queries are failing in Spamassassin due to DNS timeout. On the command line, I'm trying to issue dig commands and most of the time they are successful, but for one particular domain, they always fail. If I turn off the dnscache zimbra server, I can successfully issue the dig command that queries the txt DKIM entry for the domain that is failing when dnscache is enabled.

We are using a Cisco ASA 5505. Not sure if it has any fancy time based rules, but will check.

Any ideas or any input based on the other thread I linked to?

Code: Select all

zimbra@zimbra:~$ cat /etc/issue
Ubuntu 14.04.6 LTS \n \l

zimbra@zimbra:~$ zmcontrol -v
Release 8.8.11.GA.3737.UBUNTU14.64 UBUNTU14_64 FOSS edition, Patch 8.8.11_P4.

Thanks,
David

[phoenix]

We are using a Cisco ASA 5505. Not sure if it has any fancy time based rules, but will check.

I've no experience with Cisco kit but it can cause problems at times, there are quite a few posts on the internet about your type of problem here: https://www.startpage.com/do/dsearch?qu ... ge=english

I also don't use dnscache, I prefer to run my own PowerDNS server & resolver so I don't actually see any such timepout problems. Have you considered using a resolver other than googles, ones such as 9.9.9.9 and 1.1.1.1 might be worth trying to see if anything changes.

[davidkillingsworth]

Have you considered using a resolver other than googles, ones such as 9.9.9.9 and 1.1.1.1 might be worth trying to see if anything changes.

Yes, I used my ISP's DNS servers in the configuration instead of Google. I get the same issue.

I just want to note that I manage a few other Ubuntu/Zimbra servers that were all built around the same time, have pretty identical configuration settings, and are all kept up to date on the same patch cycle and we have no problems with any of these others.