Post #2741372

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town Now, if you have a service that you do want publicly accessible, so you run it on a GUA and point DDNS at that, but you also access that service from within your local site, then things can get interesting. I have a few cases like that. To be clear: just accessing from the same site as where the service is running, from other clients in that site, I mean. The trouble is v6 access if/when my Internet service is out. I will start to lose the more ephemeral v6 GUA prefix, and also if I'm accessing the service via a public name with DDNS on it, I start being unable to resolve that name as I want to keep the TTL on the DDNS name short. For that, I ended up creating an ingress. child zone, with things like a.ingress., and b, and c, and so forth, corresponding to the machines running or fronting the actual services. I run a split DNS auth zone for that ingress. locally, and my local resolvers are configured with that as a stub zone to forward to those local auth services. Those a and b and c etc records on the ingress zone then actually have the (stable) ULA addresses of the machines in there. Public users get the DDNS public GUA names; internal users on my own resolvers get shunted over to that internal auth zone via the stub zone config and get the ULAs back as the AAAA records. So, I can still access those local services (that are also publicly available) even if my public Internet connectivity is down.