Monitor DNS queries

I’m not sure if I understood “Monitor DNS queries” properly.

If I disable it, shouldn’t this disable CPF from displaying alerts for applications sending DNS requests?

I have Ver 2.3.6.81 installed, however, regardless of whether enabling or disabling Monitor DNS queries, CPF always prompts for every application performing a DNS request :frowning:

AFAIK If DNS Client (windows service) is disabled then applications will require their own DNS request instead of using svchost, so CPF will still ask for every app.

*DNS Client is normally disabled if your running a custom host file.

Another question: Does “Monitor DNS queries” protect against DNS spoofing?

This option only appears to effect whether applications ask for DNS. Whats the point in that? Surely what you want is an option to restrict to your DNS servers only.

DNS Client is normally disabled if your running a custom host file.

Stopping the DNS client service and providing rules for each application to make their own queries also provides more security, as only those apps you have specifically allowed should be able to perform lookups.

Does "Monitor DNS queries" protect against DNS spoofing?

Add a DNS rule for each application by specifing just your ISP’s DNS server address(s), then add two futher rules, one for TCP and one for UDP blocking access to any other DNS server. For example:

Your App.exe [ISP DNS SRV Address] 53 TCP Out Allow
Your App.exe ANY 53 TCP Out Block
Your App.exe ANY 53 UDP Out Block

Providing CPF retains the block rules and doesn’t get hung up on the ordering, it should work…

The big issue is that normally you will have two DNS Servers (primary & secondary) that cannot be added to a single zone as usually they do not form a range (not sequential addresses). Unfortunately, CPF doesn’t have the option to define a Zone based on a list of distinct IP addresses nor nesting Zones!

The issue is severe for laptop/wireless users; as they travel around and connect to friendly hot spots, they get different DNS Servers from the connected ISP which makes adding DNS rules for every application quite non-practical.

I don’t agree on adding two rules to block all other DNS servers as this will shut you down if your ISP changes the DNS IP addresses, sometimes it’s temporary for maintenance. Similarily, laptop/wireless users will suffer again and need a major rework (searching & editing the rules one by one).

The suggested solutions, as I see, can be any of the followings:
1) Ability to define a DNS Zone based on a list of trusted DNS IP addresses with priorities. To make this more user friendly: when an application attempts to connect to a new DNS address, the alert dialog has an option (checkbox) to add this new DNS address to the DNS Zone. (Most secure, also user friendly)
2) Ability to nest Zones. Each DNS server can be assigned to a Zone, and all of these Zones nested into a Master Zone. (Not user friendly, but will do)
3) An option to allow/trust the DNS addresses added manually by the user in the TCP/IP settings of the designated interface. (For power users, but less appealing than the first option)
4) An option to allow/discover the DNS addresses assigned automatically by DHCP. (Most user friendly in terms of simplicity, but less secure and less appealing for power users compared to the above)

Of course, the above should be limited to DNS port 53 (UDP/TCP) and checked by the Application Monitor (or maybe introduce a new DNS Monitor).

Yes, it appears that “Monitor DNS queries” option is limited to requests through the cache of “DNS Client” service and not a generic one for all applications. “DNS Client” caches DNS requests to avoid multiple DNS lookups for the same site but is prone to DNS poisoning. I also recommend disabling the DNS Client, the result is that your application will do the DNS lookup on its own every time (if you are in a corporate network, consult with the IT admin).

Instead of using the hosts file, I highly recommend using DNSKong along with eDexter (http://www.pyrenean.com) which provides better performance.