Dnsfire: A proof-of-concept DNS-driven firewall enforcer

github.com

7 points·fanf2··6 comments

This is an expected response to the client privacy vs network control arms race that escalated with the rise of DNS over HTTPS.

Without picking a side in that fight, I’m not sure this solution totally solves the problem when shared IP infrastructure is in play. A CDN may use the same IP for a malicious website and a perfectly good one, and the only difference is the incoming hostname being requested.

The result is you annoy dns over https users, but in the end do not gain any control.

I'm not sure I like this approach. This would probably cause a lot of problems for people that insist on running their own name resolver (e.g. Unbound), right?

It would also block any services that connect directly to an IP address, use hosts file to resolve, or use external DNS servers (eg, Google devices using 8.8.8.8 directly).

Most likely anyone deploying this is also capable of redirecting all standard dns traffic destined for external DNS servers to this resolver instead.

The use of host files and direct connections to external IP addresses based upon ip address are rare among user workstations. Any legitimate need to connect directly via IP address could be handled by exception.

dnsmasq also has out-of-box support for adding DNS replies to ipset: the --ipset option.

If you want to enforce traffic on your clients run an explicit proxy. There is no way to act as secure middleman without... being the middleman to secured traffic.

Reply on news.ycombinator.com