resolv.conf resets to 8.8.8.8 and 8.8.4.4

[Mango45]

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?

 

[MikeDVB]

If you're on a OpenVZ VPS it's being reset on boot/reboot. If not - then I don't know anything within WHM that would cause it to change automatically.

That said - 8.8.8.8 and 8.8.4.4 are Google PublicDNS Resolvers - we actually use them in our office, on our servers, and on just about everything. I've not had or seen any issues with RBLs not working while using Google PublicDNS and I suspect you may be correlating two unrelated issues.

 

[Mango45]

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:

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:

Resolving the block might be as simple as using your own non-forwarding caching nameserver to avoid being lumped together with other users['] queries.

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.

 

[MikeDVB]

/etc/rc.local

echo -e "nameserver IPHERE\nnameserver IPHERE" > /etc/resolv.conf

That should give you the desired result I imagine if on CentOS.

 

[Mango45]

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.

 

[MikeDVB]

I don't believe anything needs restarted. You could do some simple tests with 'dig' to see what DNS it's querying.

 

[kdean]

You could make the changes to your resolv.conf and then set the immutable flag so it is basically locked from further changes.

chattr +i /etc/resolv.conf

Then if you do need to make changes in the future, just remove the immutable flag with:

chattr -i /etc/resolv.conf

 

[Tom Risager]

How does this actually work - if you set resolv.conf to your servers own public IP, how does domain name resolution work?

I'd like to use URIBL, but cannot at the moment because my hosting providers resolvers are blocked.

 

[Mango45]

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%.

 

[Tom Risager]

So easy - thanks for your response

 

[cPanelMichael]

Hello

I am happy to see your question was answered. I am marking this thread as [Resolved].

Thank you.