3 ms·

If you're really serious about DNS interception, you'd setup something where a) you stop accepting A lookups, because it's 2025 and IPv4 only is dead (let's pr

by toast0 2y ago

If you're really serious about DNS interception, you'd setup something where a) you stop accepting A lookups, because it's 2025 and IPv4 only is dead (let's pretend anyway) b) for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts). Then only let clients connect to these IPv6 addresses you setup. If someone smuggles address resolution through, outside of DNS, their clients can't connect. (this is going to be a big PITA, but that's how these things go)

dullcrisp 2y ago
I guess at that point they’d have to establish a tunnel and route ads through the same HTTPS connection as legitimate traffic.
ignoramous 2y ago
> for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts) We employ exactly this technique for our Android firewall app. It can do IPv4 (by mapping hash(domain) name onto RFC6598 reserved subnet [0]) as number of unique AAAA/A requests on a client seldom exceeds 35k/mo! Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for. > (this is going to be a big PITA, but that's how these things go) You don't say. [0] https://github.com/celzero/firestack/blob/2191381f/intra/dnsx/alg.go#L1286-L1299 https://github.com/celzero/firestack/blob/2191381f/intra/dns...
- vladvasiliu 2y ago
  > Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for. This sounds good, and I've wondered how I could implement such a thing. However, with the clearly hostile approach all IoT appliances are taking, I wonder if they'll actually fall back to a "degraded" (for them) config with the network-provided DNS, or whether they'll just fail and complain the network is broken or something.

by toast0 2y ago

dullcrisp 2y ago

I guess at that point they’d have to establish a tunnel and route ads through the same HTTPS connection as legitimate traffic.

ignoramous 2y ago

> for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts) We employ exactly this technique for our Android firewall app. It can do IPv4 (by mapping hash(domain) name onto RFC6598 reserved subnet [0]) as number of unique AAAA/A requests on a client seldom exceeds 35k/mo! Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for. > (this is going to be a big PITA, but that's how these things go) You don't say. [0] https://github.com/celzero/firestack/blob/2191381f/intra/dnsx/alg.go#L1286-L1299 https://github.com/celzero/firestack/blob/2191381f/intra/dns...

vladvasiliu 2y ago
> Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for. This sounds good, and I've wondered how I could implement such a thing. However, with the clearly hostile approach all IoT appliances are taking, I wonder if they'll actually fall back to a "degraded" (for them) config with the network-provided DNS, or whether they'll just fail and complain the network is broken or something.