resolv.conf resets to 8.8.8.8 and 8.8.4.4

Periodically my resolv.conf gets reset to 8.8.8.8 and 8.8.4.4. I discover this when my users report they are receiving too much spam. Unless resolv.conf is set to the server's own public IP, DNS-based blocklists do not work properly.

I'm using the Resolver Configuration wizard in WHM to set this; any advice on making it stick?

 

Thanks Mike. It is a VPS and probably OpenVZ. I will write a script to correct resolv.conf at each boot.

The error in question that is resolved by using the server's public IP in resolv.conf is:

Code:

0.0 URIBL_BLOCKED     ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                      See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information.

From the link:

Some RBLs don't seem to care, but URIBL in particular does seem to limit the queries a single DNS server can make. I really like this RBL in particular - it catches 75% of spam that hits my server, with zero false positives.

 

A follow-up question: Is it simply a matter of making sure resolv.conf is correct, or do I need to restart anything after I correct it?

EDIT: I saw your post above after I wrote this. Thank you.

 

From within WHM, navigate to Nameserver Selection and verify that BIND is working. If it is, you're already good to go.

You may also be interested in another RBL called Barracuda. It's free but requires registration of your IP address. It too is very accurate and in my testing caught 61% of spam with no false positives. The other RBL I use is Spamhaus's Zen.

I use the following scores:

score URIBL_BLACK 10
score RCVD_IN_SBL 10
score RCVD_IN_XBL 10
score RCVD_IN_PBL 10
score URIBL_DBL_SPAM 10
score RCVD_IN_BRBL_LASTEXT 10
score RCVD_IN_BL_SPAMCOP_NET 0 1.246 0 1.347

These high scores of 10 tag any mail on these RBLs as spam, but still deliver it to the users so they can inspect what is being tagged if necessary. (Assuming your "SpamAssassin™ reject spam score threshold" is high.)

In my testing, 98.5% of spam is on one of these blocklists. 1.3% is caught by Bayesian or other rules. I'm still trying to figure out how to catch the remaining 0.2%.