Preventing host lookup/reply

Unbound
1

Specifically in this case I want to prevent wpad.<whatever> lookups.

Seems I can refuse to answer the query with:

local-zone: "wpad.<whatever>." refuse

or send effectively invalid information:

local-data: "wpad.<whatever>. A 127.0.0.1" - or via a stub-zone auth
server (nsd) method

The network in question has a mix of corporate owned and privately
owned systems, the users have full control over their privately owned
systems however they must use the local unbound cache for DNS as only
the server running unbound has egress to port 53. DHCP assigns only
this one DNS server to the internal clients.

Is one more effective than the other? Does a refusal effectively stop
further inquiries from the client? Or would it free up the client
sooner, longer or more effectively to send it the localhost address?
Is one possibly more effective against a rogue DNS server on the
network? Or against a rogue system with a hostname of wpad (maybe
advertising itself via NetBIOS - hopefully static wins entries prevent
this - or some other method)?

Thank you,

Chris

2

Specifically in this case I want to prevent wpad.<whatever> lookups.

Seems I can refuse to answer the query with:

local-zone: "wpad.<whatever>." refuse

or send effectively invalid information:

local-data: "wpad.<whatever>. A 127.0.0.1" - or via a stub-zone auth
server (nsd) method

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.

Is one more effective than the other? Does a refusal effectively stop
further inquiries from the client? Or would it free up the client
sooner, longer or more effectively to send it the localhost address?

The client should make a WPAD lookup once per HTTP session, if it is
configured to 'automatically detect proxy settings'.

Returning REFUSED/NXDOMAIN will have no effect on the rate of queries.

Is one possibly more effective against a rogue DNS server on the
network? Or against a rogue system with a hostname of wpad (maybe
advertising itself via NetBIOS - hopefully static wins entries prevent
this - or some other method)?

You can configure, via DHCP, for clients to disable NetBIOS over TCP/IP.
As for rogue DHCP/DNS servers, check to see if your network hardware
supports "dhcp snooping"/"arp inspection"/"switchport protection" or
whatever the non-Cisco equivalent might be.

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?

WPAD (if you do not know) is how many systems automatically hunt for
proxy servers...which is a *good* thing. It is always handy to have a
proxy server, especially as you can use it to help your userbase get to
braindead websites that put HTTP services on ports other than 80/tcp
(means your firewalling is easier).

Cheers

3

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 :slight_smile: 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