Public Names, Private Staging: HTTPS Without Split-DNS

Staging should behave like production: real names, valid HTTPS. It should also stay closed to everyone outside the team. We got both without running a DNS server of our own.

What we needed

Each Hullcore product has development and staging environments alongside production. We wanted them on proper HTTPS names rather than an IP address and a port, so apps, sessions and certificates behave the way they will in production. And we wanted them unreachable from the public internet.

Why we skipped split-DNS

The usual answer is split-DNS: one set of answers for people on the company network, another for everyone else. It works, but it is one more service to run, and when it fails, staging fails with it. In our network, giving team devices a reliable path to a private resolver would have been more work than the problem justified.

Public names, private addresses

So the staging names are ordinary public DNS records. Anyone can look them up. The answer is an address on our private team network, and the public internet does not route it.

On the team network, a staging name works exactly like a production one: the connection goes through and the certificate matches. Everyone else gets an address they cannot reach.

One wildcard certificate covers all of these names. As a side effect, individual staging hostnames never show up in public certificate transparency logs, so adding an environment does not announce it.

What it does not do

Reaching staging is not the same as being let in. The network decides who can connect. The staging APIs still require authentication, just as they do in production.

The names are public, so anyone can learn that a staging environment exists. We keep them generic and never put anything sensitive in a hostname.

Why it stayed

The result is a handful of DNS records, one certificate and the team network we already run. There is no resolver to keep alive and nothing new that can take staging down, and production’s records never changed.