> > The question is, should the above configuration be "baked in" to the code?
> As I understand, this vulnerability arises from the Web Proxy Automatic
> Discovery (WPAD) protocol, not from dnsmasq itself.  And, dnsmasq
> configuration provides - or will provide - a configuration mechanism to
> obviate the shortcomings of the WPAD protocol.  My inclination would be to
> *not* change the code, on the off-chance that someone might consider this
> specific function of the WPAD protocol to be a "feature", and instead, to rely
> upon the proper dnsmasq configuration, which would make overt to the
> network administrator just how the "wpad" sub-domain is being handled.
> And then, for instance, as you say,
> dhcp-name-match=set:wpad-ignore,wpad
> dhcp-ignore-names=tag:wpad-ignore
> could be recommended in the default dnsmasq configuration file.
> Also, the CERT note says "Other autodiscovery names, such as, ISATAP,
> autodiscovery and autoconf may also be exploitable."  And dnsmasq could
> be playing "wack-a-mole" with sub-domain names in the code, if handled
> that way.  It's easier to play "wack-a-mole" from the configuration file.

I fully agree with this. IMHO, the new 2.80 config settings for name matches to 
ignore should maybe added to default config.


By the way, I'd also like to "ignore" the name "localhost", as exposed by 
Samsung SmartTVs. This is annoying, as it registers "localhost" as a domain 
name. It should just ignore that hostname, if provided by the DHCP client. If 
the above option helps to provide this "ignores", then we can add more 
hostnames like this that cannot be taken by DHCP clients.


Dnsmasq-discuss mailing list

Reply via email to