A company I am servicing has a Domain Controller Name called internal.example.com
and whenever their employees go home, Apache is flooded by wpad.dat request. This flood of requests are redirected to 404, this overwhelms apache and it bogs down.
There is a wildcard DNS entry for *.example.com to be redirected to the main website.
These are the things I already did:
Served a wpad.dat file in the root directory of their website. Apache stops bogging down when I started serving a static file.
Added DNS entries for
wpad.internal.example.com
,internal.example.com
,wpad.example.com
to127.0.0.1
.
After adding the DNS and letting it propagate, I can still see requests on my log files.
I don't know what domain they are trying to access. The log file is referring to the main website instead of what they are trying to access.
Here are the applications that are requesting the wpad.dat file
- WinHttp-Autoproxy-Service/5.1
- Microsoft Office 2014
- Kaspersky Proxy-Server detection agent
- Mozilla/5.0
This thread is related Being flooded by wpad.dat but there is no conclusive answer how to fix or at least block requests.
EDIT: I don't know what subdomain they are trying to access and apache reporting it is coming from the main website. The entries I added to the DNS are intelligent guesses, I don't have concrete proof on what they are accessing.
Instead of setting up a DNS record pointing to 127.0.0.1, you should set up one that will be considered unresolvable. The easiest way to do that is to set up a TXT record for
wpad.example.com
, like this:This way,
wpad.example.com
will never resolve to any IP adress and the clients will not even try to download something.Note that any DNS lookups which have already been made may have been cached, so that clients will continue to use the cached results. This means that a DNS change will not immediately take affect with all clients, but you should see a tapering off.
The best way to handle this is at a firewall and block the requests completely from ever hitting your web server, possibly using
fail2ban
or similar.If this is not practical (for whatever reason), then catching it as early as possible on your web server server and redirecting it away before any disk I/O is done is the most efficient solution.
Here is the configuration I've used in the past to do this sort of thing. In this case I redirect the request to http://127.0.0.1/ via an external redirect which cause the users browser/script to either do nothing or make a request to itself.
You should be able to customise this to your exact needs. But if youhave problems add a description to your question.