pfSense Digest

While the author of dnsmasq does not feel it is susceptible to the recent DNS vulnerability “panic”, he did release an updated RC version including query source port randomization. It appears dnsmasq is not vulnerable because it does not do any recursive queries – it relies entirely upon your ISP’s DNS servers or internal ones you have defined. Hence it appears that as long as your ISP isn’t vulnerable, you aren’t vulnerable. If you have instead defined internal DNS servers, they are the ones that will need to be patched.

The DNS server package in pfSense uses djbdns, which is the only major DNS server package that was not vulnerable.

We feel it’s safe to say this probably does not affect dnsmasq in pfSense – but we can’t say for sure until the details are released at Black Hat in August. This fix is still a good one to deploy because it makes other potential cache poisoning vectors much more difficult.

Please help us test this new version of dnsmasq. This is for 1.2-release systems only, those using 1.2.1 or 1.3 snapshots can update by installing a new full update from the snapshot server. We have been testing it and have not found any issues.

At that point you will be running the updated dnsmasq and everything should be working properly.

Thanks to dnsmasq author
Thanks much to Simon Kelley for making a dnsmasq update available so quickly, and promptly replying to our inquiry!

Updated release information
Once this fix has been more widely tested, we will release pfSense 1.2a with only this change. Based on the information we have available, this currently does not warrant a wrecklessly quick fix with the potential cost of stability. All things at this time point to this specific issue being applicable only to servers that issue recursive queries, and hence not dnsmasq.

For DNS Resloving in the shell i believe it uses /etc/resolv.conf and asks the DNS servers directly. I killed dnsmasq and was able to ping domain names from the shell all day long. I also did the update with the domain name and it worked fine.

Fetching the updated file isn’t relevant to whether or not dnsmasq is running, since the local system uses /etc/resolv.conf.

I think ronpfs means don’t access the webGUI by hostname if your client is using that system for its DNS. That shouldn’t matter either as the DNS cache on your client system should be more than long enough to accommodate doing this, but it’s not bad advice.