Solution 1:

It appears that your DNS zone eklundh.com has a wildcard record defined pointing to cluster.atlascms.se. This includes wpad.eklundh.com. I suggest you add a DNS record explicitly defining wpad.eklundh.com. to 127.0.0.1 or something.

Solution 2:

Machines will look for a WPAD.dat file hierarchically based on their own FQDN, if they are configured for proxy autodiscovery. So, if a windows PC is a member of a domain c.d.e.com, it will look for WPAD.dat in:

http://wpad.c.d.e.com/wpad.dat
http://wpad.d.e.com/wpad.dat
http://wpad.e.com/wpad.dat
http://wpad/wpad.dat

Chances are that somewhere, someone has a domain which is a subdomain of one of the ones you are hosting HTTP on, and hasn't properly configured or disabled proxy auto-discovery. In consequence, they are likely searching hierarchically.

It's possible that a virus may have caused them to do this; likely, if the machines making the query are extremely numerous and in diverse subnets, this is what is up.

If possible, avoid defining a DNS record for the wpad subdomain of anything you don't intend to use for proxy auto-discovery.

If this is not an option, you could consider using layer 7 filtering to find queries for wpad.dat and reject the packets with an ICMP message. This might actually be the most effective way to stop the traffic, unless the IPs are all from the same network and their technical contact in whois is responsive.

Things that will point a host at a particular location for wpad.dat include domain settings, the domain name option in DHCP replies, and an explicit setting in the web browser to load proxy information from some URL.