Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

In case it wasn’t clear: This won’t stop you from going to 192.168.1.1 or otherwise accessing private network resources from Chrome. This is about closing specific public/private boundary security vulnerabilities that you don’t want 99% of the time. The author of this article happens to have a 1% corner case, but the average user generally doesn’t want this.

View on HN

I think split-horizon DNS is a bit more than a 1% corner case: it's almost universal in corporate and education contexts.

They can apply group policy to make it work then.

When I read that all I could think of was routing things through a privacy-invading proxy. Is that what it is?

There often is such a proxy in these environments but it isn't really related. The scenario here is that you have servers with both internal and external IP addresses, and for whatever reason if someone is connecting from inside the network you want them using the internal IPs and not the external ones. (Simpler routing, different features available to internal clients, etc.) So you set up the DNS servers for your network to serve internal IP addresses for your domains, but anyone outside the network sees the public IPs for those same domains. (That's the "split horizon" part.)

Now someone in the network could follow a link from a page served from a public IP to a domain with a private IP address—which this change would disallow unless the first page was served from a "secure context" (with TLS) and the internal server responds to a "preflight" OPTIONS request with the required CORS headers to allow following links from public networks.

This is extremely common in Universities where you share 2-4 public IPs that you can usually ask ports to be forwarded to a internal IP, and often there are resources (Like say Servers with GPUs) available on a interally reachable IPs using a easy to use hostname served by the internal DNS server.

Ofc this change won't be that big of a issue, things would just need to change a little, using Split-DNS was already a pain when students wanted to say use DNS-over-HTTPS and didn't want the University DNS servers to know every site they visited.

Use IPv6 and stop with the NAT. It makes all the split-horizon DNS pain go away.

Lack of IPv6 support is unfortunately quite common among devices, as are buggy/bad/underbaked implementations.

+1 Especially for the devices this is targeting, like IoT stuff, printers, fridges, cameras etc. In fact all the IoT stuff I have don't support IPv6 well (or at all) and many of them don't even support 5Ghz ac WiFi.

I'd just return it if it says IPv6 on the package, but is implemented shoddily. Manufactureres should do better in 2021.

> Use IPv6 and stop with the NAT. It makes all the split-horizon DNS pain go away.

Sure. Just give me a week or two(or several months) to shut down whole network and reconfigure all the servers, devices, and services.

Also all our business partners and vendors who integrate with our services, will be glad to switch to our new setup, exactly when we need them to.

If you are building new site/network ipv6 is way to go. Migrating existing ones is next to impossible due to all of the dependencies out of your control

It's about shifting a security boundary from one place to another, because the original location of it has been ignored for generations and is now about as good as keeping invaders out as the Great wall of China.

Reply on news.ycombinator.com