8.8.8.8 rejecting DNS requests from SMTP gateway

[s.t...@gmail.com]

Background information:

Our company has 9 email SMTP gateways.  They are all clustered and using the same DNS settings, 8.8.8.8.  If a change is made to the DNS settings on one gateway, it would change settings to all 9 gateways.  Two of these gateways are new and were just brought online at the end of last year.  They are not routing any mail at this time. 

 

Issue information

On Friday morning between 10:45am and 11am CST, the two new gateways could ........

• no longer receive a response from 8.8.8.8. 
• no longer able to telnet to 8.8.8.8. 
• no longer able to perform an nslookup. 

 

The following error was received.

Mon Feb 12 16:35:36 2016 Info: DNS Temporary Failure cisco.com MX - Failed to bootstrap the DNS cache.

Mon Feb 12 16:35:36 2016 Warning: Failed to bootstrap the DNS resolver. Unable to contact root servers.

 

I figured maybe Google DNS started rejecting these IP requests due to not having any public DNS information (A & PTR records).  I requested these records be created.  Prior to these records being created one of the gateways began to receive DNS information and still can as of writing this post.

 

Lets refer to the two gateways as SMTP8 and SMTP9. 

 

I ran a packet capture from each gateway to see if packets are being received.

 

SMTP8 (204.44.23.10) is able to connect successfully with 8.8.8.8

 

SMTP9 (204.44.23.11) receives a reset from 8.8.8.8

 

These gateways are both in the same datacenter and as you can see they are in the same subnet. 

 

Does anyone know why this IP may be rejected from receiving DNS requests?  Is there some sort of blacklist Google uses?  I have checked public blacklists and do not see these IP's listed.

Any help would really be appreciated.

[Shen Wan]

Hi,

Please follow https://developers.google.com/speed/public-dns/docs/using#troubleshooting to diagnose and provide us your result if you still need help.

Thanks!

[Alex Dupuy]

It's a bit unusual that your SMTP servers were generating TCP requests to 8.8.8.8 rather than using UDP; it's possible that there was some anti-DoS protection activated at that time, but captures of nslookup/dig output, or packet captures of the UDP traffic would be needed to understand that.

TCP connection rejects could be issued in cases of service overload or excessive QPS, we'd need to know what level of DNS queries your servers were generating (QPS limits are on a per-client-IP basis).

If you encounter these problems again, please report them on the Google Public DNS issue tracker.