
Dnsfire: A proof-of-concept DNS-driven firewall enforcer - fanf2
https://github.com/wupeka/dnsfire
======
thegagne
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.

------
resill
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?

~~~
gregmac
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).

~~~
tssva
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.

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

------
zamadatix
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.

