SOLVED CSF Blocking Google DNS + dig Command

[Hays Sleiman]

Hi guys,

Hope someone can help. This issue is more in relation to CSF than WHM but I thought I'd ask here as the people here are super helpful and I've always managed to find a solution on this forum.

I have WHM + CSF installed on a CentOS server, and it's come to my attention we've had issues with some limited mail flow, and a few visitors trying to visit their websites.

Long story short, we came to the conclusion that Google DNS is having trouble resolving any domains on my server. One example is

When I run a dig command using any other DNS server such as open DNS, I get this result:

>dig @208.67.xxx.xxx example.com.au

; <<>> DiG 9.12.2 <<>> @208.67.xxx.xxx example.com.au
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34338
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.au.              IN      A

;; ANSWER SECTION:
example.com.au.       14400   IN      A       66.187.xx.xxx

;; Query time: 579 msec
;; SERVER: 208.67.xxx.xxx#53(208.67.xxx.xxx)
;; WHEN: Thu Sep 06 14:14:57 AUS Eastern Standard Time 2018
;; MSG SIZE  rcvd: 61

As you can see, in the Answer section, the IP 66.187.xx.xxx is retreived. Which is the IP for the server ms1.exampletoo.com.au.

However, when I use either 8.8.8.8 or 8.8.4.4, this is the result:

>dig @8.8.8.8 example.com.au

; <<>> DiG 9.12.2 <<>> @8.8.8.8 example.com.au
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60005
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.au.              IN      A

;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep 06 14:13:10 AUS Eastern Standard Time 2018
;; MSG SIZE  rcvd: 45

Now, the reason I think CSF has something to do with it, is because as soon as I disable csf, the Google command instantly works and no more issues. Then when I re-enable csf, the issue re-occurs.

The command I use to diable csf is just csf -x.

Port 53 is open on TCP and UDP - both incoming and outgoing - both IP4 and IP6.

Other than that, I dont know how to figure this out and it's becoming urgent.

One thing that should be noted is that adding the following line to /etc/csf/csfpre.sh seemed to fix the issue, but I do not know what the line does and don't want to use it if it leaves the server vulnerable.

/sbin/iptables -I INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Any help would be very much appreciated. Thank you.

Regards,

Hays

 

[cPanelLauren]

That rule basically means that related and established connections are accepted in the input chain associated with connection tracking

/sbin/iptables -I (insert) INPUT -m (matches) conntrack --ctstate (connection state)  RELATED,ESTABLISHED -j (target which means what to do) ACCEPT

I'm not really sure how this has anything to do with Google's DNS resolvers though since it would primarily be related only to established sessions.

Port 53 is open on TCP and UDP - both incoming and outgoing - both IP4 and IP6.

How are you verifying this?

What do you have in /etc/resolv.conf? You can find out by running the following:

cat /etc/resolv.conf

 

[Hays Sleiman]

Thanks for the quick reply!

This is what the cat command comes back with:

# Generated by NetworkManager
nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4

In the past, I've removed the "nameserver 127.0.0.1" line, but it just keeps being added automatically.

In regards to port 53, I've got it set in CSF as unblocked on both incoming and outgoing configurations. Also, I sync the server as part of DNS cluster and I don't have any other DNS issues or problems with the dig command using anyone else other than Google. I.e. no issues with openDNS, or ISP DNS servers. So all of that, I assume port 53 is working correctly? Please let me know if I could be wrong.

In the meantime, I'll add iptables rule I mentioned, but I'd rather get to the bottom of the problem.

 

[Hays Sleiman]

Nevermind. That rule isn't making a difference now

So the only way so far has been to just disable csf (csf -x) completely to be able to use Google DNS to dig and solve the email issues.

It's driving me crazy!

 

[Hays Sleiman]

I found the issue!

Just in case anyone has a similar problem.

So it turned out even though Google IPs were allowed through CSF and DNS ports were opened and vaified, Google DNS was being blocked. I know it wasn't a DNS issue specific to my server because every other DNS server was working. The dig and nslookup commands worked with my ISP servers, openDNS, and so on...just not with Google 8.8.8.8 and 8.8.4.4. I knew this meant the block was specific to Google but I couldn't find any Google IPs being blocked in the csf.deny file or anything like that.

The other odd thing was the dig and nslookup commands only failed within Australia. When I RDPd in to an overseas computer and ran the commands using Google DNS, it worked fine. This is what lead us to the resolution.

FINALLY, As per the suggestion from the awesome support team at cPanel, when I emptied my CC_DENY configuration in CSF and Voila! Everything works and Google can find me again!

Due to the large number of spam and brute force attempts from certain countries, I had the following list in my CC_DENY input: CN,RU,IN,TW,PK,LA,PE

So it turns out Google routes its Australian DNS servers through one of the above countries....I'll let you know which one soon...

 

[Hays Sleiman]

Pakistan...It was Pakistan.

I've removed PK from the countries that csf blocks and Google DNS Australia can now see me

 

[Hays Sleiman]

It was also Taiwan...Had to remove TW as well. All good now.

 

[cPanelLauren]

Hi @Hays Sleiman

This is what I was getting at, just because you've unblocked it doesn't mean it's open if you're blocking something related. I'm really glad you figured it out - google most likely routes through a lot of countries which may be something to keep in mind you may not be able to country block and use google DNS at some point.

None the less, thank you so much for following up here with the resolution!


Thanks!