Your AI Agent Shipped the Site. Now It Needs a Name: DNS for Agents, Headless

Your AI agent shipped the site. Now it needs a name: a practical guide to DNS for agents

Every guide about coding agents ends the same way: the agent writes the code, the tests pass, the preview runs on localhost:3000. Then you hit the part nobody scripts. The site needs a real hostname, and a hostname means DNS.

Deploying is automated. Naming is not. Here is how to close that gap, from cheapest to most permanent.

The gap: hosts speak HTTP, registries speak DNS

A hosting platform gives your agent a URL the moment it deploys. That URL lives on the platform's domain: my-app.vercel.app, project.pages.dev, app.railway.app. It is real, it has TLS, and it works. It is also not yours. The moment you migrate hosts, every link, cookie scope, webhook allowlist and OAuth redirect URI that names that URL breaks at once.

Buying a second-level domain fixes that, but it drags in a registrar account, a payment method, an email inbox for verification, and a DNS dashboard your agent has no keys to. Most agent setups stop at the platform URL for that reason, and then the migration pain arrives later.

There are three practical ways to give an agent a hostname it controls, without a human babysitting a registrar.

Option 1: A tunnel for previews only

Tools like cloudflared and ngrok give you a public HTTPS URL to a local port with no DNS work at all. Two properties make them previews, not homes:

1. The URL is temporary unless you tie it to an account and a domain you already own.
2. The site is only alive while the tunnel process runs on your machine.

Use tunnels to show a client a demo tonight. Do not point a portfolio, an API, or a webhook at one.

Option 2: Own a domain, hand the agent the API

The durable route is a domain you bought, plus a DNS API your agent can call. The workflow:

1. Buy the domain once, human hands, registrar of your choice.
2. Move DNS to a provider with a real API (Cloudflare, Hetzner DNS, and similar all qualify).
3. Give the agent a scoped API token that can only write records for that zone.
4. In your agent instructions, spell out the record vocabulary:
   • A for an IPv4 address (a VPS, a home server)
   • CNAME for a target hostname (most PaaS hosts: Vercel, Netlify, Cloudflare Pages)
   • TXT for verification and for ACME DNS-01 challenges
   • MX only if you also set up mail

Then the agent's deploy loop becomes fully headless: deploy, read the host's expected record, write the record, poll until the name resolves, request the certificate. Two guardrails make this safe. First, scope the token to one zone, never your whole account. Second, make the agent verify from outside: curl -I the new hostname and check the status code and the certificate before calling the deploy done. A record that exists but points at a stale IP looks identical to a failed deploy from inside the sandbox.

The cost is the domain itself plus the setup afternoon. For a main product, do this.

Option 3: Claim a hostname with one command, no registrar

If you just need a name that is yours to manage (not yourbrand.com, but a real resolvable hostname with records you control), there is a third shape: services that hand out subdomains programmatically.

I build one of these, AgentDomains (I make AgentDomains, so weigh the recommendation accordingly; the category itself is bigger than my tool). An agent claims something.makes.fyi with a single CLI command, then manages A, AAAA, CNAME and TXT records, URL forwarding, reverse proxying with HTTPS on the edge certificate, or full nameserver delegation, from the same CLI or an HTTP API. There is also an MCP server for agent clients that speak Model Context Protocol. Sign-up is instant and needs no email form; free covers 10 names, and confirmation-by-email keeps abandoned names from being pinned forever. It is not a registrar and sells no second-level domains. The point of the category: a hostname the agent controls through an API, in seconds, for zero money.

Other options in the same shape include free subdomain registries that require a GitHub login, and free dynamic DNS services that are really just record-updaters with extra steps. Pick by what your agent can actually do headless: if claiming a name needs an OAuth dance in a browser, that is a human step wearing a CLI costume.

What to check before you trust any hostname

Whatever route you take, make the agent prove the name works before it reports success:

• dig +short <name> returns the record you intended
• curl -Iv https://<name> completes the TLS handshake with a valid cert
• the app responds with the expected status code, not a platform 404 page (a CNAME that resolves but the host never added the domain returns exactly that)
• if the name fronts an API, one authenticated call succeeds end to end

Naming is the last human-shaped bottleneck in agent-built projects. A tunnel solves tonight, an API-driven domain you own solves forever, and an agent-native hostname service solves the ten in-between sites that are not worth a registrar login each. Pick per project, and make the verification loop part of the deploy script either way.