On Sat, Feb 19, 2011 at 5:54 AM, Alexander Clouter <[email protected]> wrote: > If 'wpad.example.com' does not actually have an A/AAAA/CNAME record, > then what are you trying to do? I do not think unbound supports > wildcard blocking (ie. 'wpad.*') either; I think to do this you would > have to look to the python hooks to help you out.
Looking to find the cleanest way to handle this - as opposed to timeouts and/or sending the inquiries upstrream to the forwarders. Many systems are quite persistent in looking for wpad - I've seen queries for wpad.example.com, wpad.com, wpad, and even wpad.example (thank you Windows 7 for this one). Right, I tried a refusal with a wpad.* entry but it was not honored. Would love that feature! Especially, as mentioned, many of the clients are not under my control - they have for whatever mistaken reason configured a static domain which overrides any connection specific suffix and the wpad queries are sent upstream. > Returning REFUSED/NXDOMAIN will have no effect on the rate of queries. Then I'll use REFUSED - it appears to be faster. > You can configure, via DHCP, for clients to disable NetBIOS over TCP/IP. Yes, but I need NetBIOS although static WINS entries seem to solve this. > What is it you are trying to achieve? I'm curious about how you think > blocking WPAD lookups will help you get closer to your goal? Maybe it > is just the wording, but it seems you are attempting to obliterate every > byte of supposedly unwanted traffic on the local network? Wish that were possible :) Again just the cleanest way to handle it all, allow the systems to get on with the shortest delay, prevent "wpad hijacking" and not send queries upstream. > WPAD (if you do not know) is how many systems automatically hunt for > proxy servers...which is a *good* thing. If I ran, or wanted to run a proxy server, "wpad hijacking" didn't exist as a problem, and there was some great consistency across platforms and browsers then it would be good.thing. I'm not convinced at this point. Thank you, Chris _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
