3 ms·
The issue isn't network filtering, it's encryption. Standard DNS is unencrypted. DNS-over-HTTP is encrypted. Or DNSSEC or any number of newer standards that se
by manigandham 6y ago
The issue isn't network filtering, it's encryption.
Standard DNS is unencrypted. DNS-over-HTTP is encrypted. Or DNSSEC or any number of newer standards that secure the DNS lookup. At that point, filtering will require MITM proxies, whether it's for DNS or HTTP or any other protocol.
It's a trade-off with security on the open network meaning harder penetration and control in your internal network. There's no easy answer.
- tptacek 6y agoDNSSEC is not encrypted. Moreover, between end systems and DNS servers --- the scenario we're discussing on this thread --- it isn't even authenticated.
- manigandham 6y agoSure, DNSSEC provides authentication and integrity rather than encrypted traffic, which makes spoofing or rewriting the responses hard. Why do you say it's not authenticated? If they're using the newer standards then that's what it provides. If they're not then there's no issue with network filtering as usual.
- tptacek 6y agoAgain: the article discusses an environment where machines on a home network are refusing to use the DNS servers the network is configured to use. DNSSEC authenticates requests between servers. But between DNS clients ("stub resolvers") and servers ("full recursers"), there is no authentication, just a single bit in the header that says "trust me, I authenticated this data". It doesn't matter if you're using your ISP's servers, 8.8.8.8, 1.1.1.1, or a custom server you set up on Digital Ocean somewhere: an on-path attacker can forge DNSSEC responses to you. It's a ridiculous situation.