Hacker News Reader

Comment by kccqzy | Hacker News Reader

The split horizon DNS model mentioned in that article is to me insane. Your DNS responses should not change based on what network you are connected to. It breaks so many things. For one, caching breaks because DNS caching is simplistic and is only cached with a TTL: no way to tell your OS to associate a DNS cached response to a network.

I understand why some companies want this, but doing it on the DNS level is a massive hack.

If I were the decision maker I would break that use case. (Chrome probably wouldn't though.)

View on HN

> Your DNS responses should not change based on what network you are connected to.

GeoDNS and similar are very broadly used by services you definitely use every day. Your DNS responses change all the time depending on what network you're connecting from.

Further: why would I want my private hosts to be resolvable outside my networks?

Of course DNS responses should change depending on what network you're on.

> but if you're inside our network perimeter and you look up their name, you get a private IP address and you have to use this IP address to talk to them

In the linked article using the wrong DNS results in inaccessibility. GeoDNS is merely a performance concern. Big difference.

> why would I want my private hosts

Inaccessibility is different. We are talking about accessible hosts requiring different IP addresses to be accessed in different networks.

If you have two interfaces connected to two separate networks, you can absolutely have another host connected to the same two networks. That host will have a different IP for each of their interfaces, you could reach it on either, and DNS on each network should resolve to the IP it's reachable on on that network.

Correct, and this is by design. Keeping in mind "hairpin"-style connections often don't work, also by design (leaving a network then hairpinning back into the same network).

Let's say you have an internal employee portal. Accessing it from somewhere internal goes to an address in private space, while accessing it from home gives you the globally routable address. The external route might have more firewalls / WAFs / IPSes etc in the way. There's no other way you could possibly achieve this than by serving a different IP for each of the two networks, and you can do that through DNS, by having an internal resolver and an external resolver.

> but you could just have two different fqdns

Good luck training your employees to use two different URLs depending on what network they originate from.

I'm surprised you've never seen this before.

Especially for universities it's very common to have the same hostname resolve to different servers, and provide different results, depending on whether you're inside the university network or not.

Some sites may require login if you're accessing them from the internet, but are freely accessible from the intranet.

Others may provide read-write access from inside, but limited read-only access from the outside.

Similar situations with split-horizon DNS are also common in corporate intranets or for people hosting Plex servers.

Ultimately all these issues are caused by NAT and would disappear if we switched to IPv6, but that would also circumvent the OP proposal.

No I haven't seen this before. I have seen however the behavior where login is required from the Internet but not on the university network; I had assumed this is based on checking the source IP of the request.

Similarly the use case of read-write access from inside, but limited read-only access from the outside is also achievable by checking the source IP.

But how do you check the source IP if everyone is behind NAT?

Take the following example (all IPs are examples):

1. University uses 10./8 internally, with 10.1./16 and 10.2./16 being students, 10.3./16 being admin, 10.4. being natsci institute, 10.5. being tech institute, etc.

2. You use radius to assign users to IP ranges depending on their group membership

3. If you access the website from one of these IP ranges, group membership is implied, otherwise you'll have to log in.

4. The website is accessible at 10.200.1.123 internally, and 205.123.123.123 externally with a CDN.

Without NAT, this would just work, and many universities still don't use NAT.

But with NAT, the website wont see my internal IP, just the gateway's IP, so it can't verify group membership.

In some situations I can push routes to end devices so they know 205.123.123.123 is available locally, but that's not always an option.

In this example the site is available externally through Cloudflare, with many other sites on the same IP.

So I'll have to use split horizon DNS instead.

Ohh, your Example Documentation was sooo close to being RFC-compliant! Except for those unnecessary abbreviations of CIDR notation, and...

You can use 203.0.113.0/24 in your examples because it is specifically reserved for this purpose by IETF/IANA: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4

I usually try to write comments with proper notation and proper example values, but if — like in this instance — I'm interrupted IRL and lose my draft, I'll focus on getting my idea across at all rather than writing the perfect comment. Even if that leads to excessive abbreviations, slightly off example values, inconsistency between you/I/passive voice or past/present/future tense.

In this case the comment you see is the third attempt, ultimately written on a phone (urgh), but I hope the idea came across nonetheless.

Reply on news.ycombinator.com