I do ULA+global unicast too, but it would be far simpler if I actually had a reliable stable prefix and could just use that. I put my ULA addresses in local DNS (because that’s why I need ULA, I need to not worry about rewriting my zone file whenever my cable modem reboots), but that means I have to do split horizon DNS. I wish I didn’t have to. (Yes I do mDNS too but I need real DNS for lots of use cases.)
You also said
> NAT is here to stay
Which, uh, it sure sounds like you're not using IPv6 NAT. In fact, it looks like aside from probably being confused about what "split horizon DNS" is [0] your setup is exactly like mine. Address autoconfig for both a annoyingly-frequently-changing global prefix, and a constant ULA prefix with DNS entries for the ULA addresses.
[0] Does your DNS server serve LAN _and_ WAN clients? If it doesn't, and it only serves LAN clients, you're almost certainly confused.
> They pretty clearly talk about public hosts
Thing is, I ALSO have public hosts on my LAN. And they're in both the public DNS and in the DNS on my LAN. But public DNS is not served from my local DNS, so I don't have a split-horizon setup.
The mere act of maintaining (in two entirely unrelated DNS servers) records for the same resource but with different data doesn't make a split-horizon setup. If it did, then I could reasonably claim "I'm running a split-horizon setup for mit.com!" just by adding an A record for "mit.com" to my local DNS server, despite being neither connected to any MIT internal networks, nor in a position to serve any data to MIT's Internet clients.
I do DNS such that the same hostname, which I control, resolves to the ULA address if asking locally, but the public address if asking from an external machine. But it's not literally the same server, I use DNSimple for my public DNS and unbound on my local DNS. You can split hairs about whether split horizon means "the same DNS server serving both views" or not, but that's a needlessly pedantic snipe. But to cut off this argument: Sure, you're right. You score one internet point, I used the word "split horizon" incorrectly. You're very smart.
No, I'm really rock-stupid.
I also happen to be correct about the terminology.
> > NAT is here to stay
It's not generally good form to cherry-pick things I said from other threads and put them out of context. "NAT is here to stay" can for the purposes of this discussion mean "Thinking about global vs local addresses is here to stay", even if it's not NAT per se that is happening (ie. if you're using a ULA + global unicast, like I do.)
> you're almost certainly confused
I'm not confused. I do split horizon DNS. I serve WAN and LAN clients (not currently from the same DNS server, although that's what I'd prefer to do. The same hostnames are currently configured in different DNS systems depending on who's asking, hence "split horizon".)
To be clear, here's my setup. It's not unique or interesting compared to any other "home lab" setup:
- I have multiple machines that I want to be able to access by DNS name externally.
- I also want to be able to use those same DNS names for local configuration, to keep things sane.
To do this, I have two options:
1) Use the publicly-routable global unicast addresses in my DNS, and make a system to keep them updated in a reprefix
2) Use a ULA prefix for local DNS, and the global unicast equivalent addresses for public DNS, and make a system to update only the public DNS when I get reprefixed
I chose option (2) because I want to mitigate the damage that happens when my ISP reprefixes me. (It's happened 6 times over the past year, it's not uncommon.)
When I get reprefixed, any local traffic that's using DNS to lookup the address keeps working as usual, because the ULA address doesn't change. I have to worry about reconfiguring public DNS, but that's the lesser of two evils IMO:
Because if I picked option (1), I'd have to reconfigure public DNS and my local traffic would all be disrupted while the reprefix happened: My hosts would all be trying to communicate with one another via their old prefixes, and failing until DNS reconfigures.
And this is all not to mention that I have to do the exact same reconfiguration dance with my firewall config: When I get reprefixed, my pf.conf is now referencing invalid IP's. I disable-by-default so it's not a security issue, but it's something that I had to solve with automation (in my case, by templatizing my pf.conf and writing dhcpcd hooks that reconfigure it when the prefix changes. It wasn't trivial.)
Now, to get back to my original argument: IPv6's simplicity benefits "erode" when you consider that worrying about internal vs external addresses is still something you have to deal with in the real world, at least in residential deployments where you don't own your own prefix. Granted: These issues are inherent to any system where your ISP is dynamically assigning you IP's, but it's important to understand: Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work, due to it being the real world.
What? Press "parent" on the comment of yours that I'm quoting from right now four times. You'll find the comment of yours where you say "NAT is here to stay" right here in this comment tree.
> To be clear, here's my setup.
Yep, that's my setup as well, except I don't screw around with applying per-host inbound traffic firewall rules at my router. Either traffic is worth blocking to an entire subnet, or it gets blocked at the host that cares about it. Saves a ton of maintenance.
> Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work...
Yep. It's less complexity than with NAT. Substantially so. That's like the entire point. The additional complexity you keep pointing at is because of a feature that you can't have with typical end-user NAT... the ability for each host on your LAN to have a globally-accessible IP address. And you can get rid of most of what you're complaining about by paying for a static prefix and getting it tunneled to your site, as folks elsewhere in this sprawling conversation tree have mentioned (or getting friendly with a local clued-in ISP and having them statically-assign you one).