Public DNS Is Free Reconnaissance

I wanted a friendlier way to reach a self-hosted service than typing a raw IP address into a browser. The obvious move — point a hostname at the box — turned out to be a small security decision wearing a convenience disguise. The instant you publish a DNS record, you’ve told the entire internet that this name maps to this address. That’s not a private convenience; it’s reconnaissance you’ve handed out for free. How you publish it determines how much you just gave away.

A DNS record is a public statement

DNS is a public lookup system. When you create a record that resolves a name to an address, anyone who can guess or enumerate the name learns the address behind it — and naming is rarely as unguessable as people assume. So every record is a fact about your infrastructure, voluntarily disclosed: this service exists, it lives here, come find it.

That’s fine for things meant to be found. It’s a problem when you reflexively point a nice hostname at an origin you’d rather keep quiet, because you’ve just made an obscure-by-default box trivially discoverable. The friendly URL that makes the service easier for you to reach makes it easier for everyone else to reach too.

Three ways to publish, three levels of exposure

The useful realization is that “give it a hostname” isn’t one choice — it’s at least three, and they expose very different amounts. Using a provider that can both serve DNS and proxy traffic, the options line up like this:

• DNS only (direct). The record points straight at your origin and clients connect directly. Works on any port, but the real address is public, there’s no protection in front of it, and the client has to be able to route to it.
• Proxied (behind an edge). Clients hit the provider’s edge; the edge connects back to your origin. You get the origin address hidden, TLS termination, and a buffer in front — at the cost of living within the edge’s supported ports and rules.
• Outbound tunnel. A daemon on the host makes an outbound connection to the provider, and traffic is routed back through it. No inbound exposure at all — no public IP needed, no port-forward, no firewall hole.

Same friendly hostname in all three. Wildly different answers to “what did I just expose?”

The default leaks the most

Here’s the trap: the easiest option to set up — a plain record pointing at your origin — is the one that exposes the most. It publishes the real address, puts nothing between the internet and your box, and depends on the origin being directly reachable. It’s the path of least resistance and the path of most disclosure, which is a bad combination for anything you didn’t deliberately decide to make public.

The friendly hostname is for your convenience. The exposed origin behind it is everyone else’s. Don’t trade the second to get the first by accident.

Proxying hides the origin and adds TLS and a buffer. A tunnel goes further and removes inbound exposure entirely — the box can sit somewhere with no public reachability and still be served, because the connection it makes is outbound. The more sensitive the thing, the more I lean toward the option that exposes the least, even though it’s more setup than typing one record.

Routability is not reachability

One subtlety worth flagging, because it produces confusing failures: a name resolving doesn’t mean anyone can connect. An address that only routes inside your own network will resolve publicly but refuse connections from the outside world — the record is a true statement about an address nobody off-network can reach. The direct and proxied options both assume the origin is genuinely reachable from where the client (or the edge) sits; only the outbound-tunnel approach sidesteps that question, because the host reaches out rather than waiting to be reached.

So “I made the record and it resolves” is not “it works from anywhere.” Resolution and reachability are separate problems, and conflating them is its own afternoon of head-scratching — the same way IPv6 makes you separate name resolution from transport.

A friendly name on an unauthenticated service is an invitation

The sharpest version of this: putting a memorable hostname in front of a service that has no authentication doesn’t just make it easier for you to use. It makes it easier for anyone to find and use. Obscurity was never security, but a hard-to-type address was at least friction; a clean public name removes the friction for everyone equally.

So before fronting something with a nice domain, I ask whether it should be reachable by strangers at all — and if not, an authentication layer (the kind you can put in front via the edge or tunnel) goes on before the friendly name does, not after. The convenience and the access-control decision are the same decision; treat them together.

Publishing is a security decision

The takeaway isn’t “DNS is dangerous.” It’s that publishing a record is a deliberate act of disclosure, and you get to choose how much you disclose: expose the origin directly, hide it behind a proxy, or never expose it inbound at all. Pick on purpose, scaled to how sensitive the thing is. It’s the same instinct behind reaching services without opening ports and treating security as architecture rather than decoration. If you’re about to put a public name on something and aren’t sure which path fits, I’m easy to reach.