Teams that started with www, mail and a handful of hand-picked hostnames usually hit a wall around the 50-subdomain mark, when nobody can say what a name like app2-new-test belongs to or whether it’s safe to delete. Good subdomain naming conventions fix this early: they make every DNS record readable at a glance, tie each name to an owner and environment, and make stale DNS much easier to find before it turns into a subdomain takeover. This article covers how to design a naming scheme that still works at 500 subdomains, how to roll it out without breaking production, and which mistakes cause the most cleanup work later.
Why Names Decide How Manageable Your DNS Becomes
A subdomain name is the only metadata that travels with a DNS record everywhere. It appears in zone files, certificate transparency logs, browser address bars, SIEM alerts and Terraform state. If the name carries no meaning, every investigation starts with archaeology.
Here’s a familiar scenario. A security engineer reviewing the zone for a mid-sized SaaS company finds 340 records. Around 60 are CNAMEs pointing at Heroku, Azure App Service and AWS CloudFront endpoints, with names like promo, demo-jk, staging3 and newsite. Nobody knows which are live. Tracing owners through Slack history and old Jira tickets takes three weeks, and four of the CNAMEs turn out to be dangling DNS – they point at resources that were deleted long ago.
A naming convention wouldn’t have stopped those resources being deleted. It would have made the orphans obvious within minutes.
Building Blocks of Subdomain Naming Conventions
An experienced DNS administrator designs a naming scheme around the questions people ask during an incident: what is this, who owns it, which environment is it in, and is it supposed to be public? A scheme that scales usually encodes three or four of these dimensions:
Service or function – api, auth, status, docs, cdn. Use what the thing does, not the vendor hosting it.
Environment – prod, stg, dev, sbx. Pick one abbreviation set and keep to it. Using staging, stage and stg side by side defeats the purpose.
Region or tenant – eu1, us2, or a customer slug for multi-tenant platforms.
Owning team – optional in the name itself, since it often fits better in a TXT record or an inventory tag.
The structural choice that matters most is separator versus hierarchy. Flat names such as api-stg-eu1.example.com keep everything at one level, so a single wildcard certificate for *.example.com covers them. Hierarchical names such as api.eu1.stg.example.com read more cleanly and let you delegate stg.example.com to a separate zone with its own access controls. The catch is that a wildcard certificate only covers one label, so *.example.com won’t match api.eu1.stg.example.com.
Production usually works best with flat names on the apex zone and non-production delegated to its own subzone. Delegating dev.example.com to a separate Route 53 hosted zone or Cloudflare zone means a developer with zone-edit rights there can’t touch the production MX or SPF records.
Step-by-Step Rollout Without Breaking Production
Renaming live hostnames is risky, so the rollout should be gradual. A practical sequence that fits into one quarter:
1. Export every record from every zone and list them with owner, target and last-modified date. If an up-to-date inventory doesn’t exist yet, the guide on building a subdomain inventory that actually stays current covers how to start one.
2. Write the convention down in one page: allowed environment tokens, allowed service tokens, separator rules and length limits. DNS allows 63 characters per label and 253 for the full name, but anything over about 30 characters becomes a burden in practice.
3. Apply it to new records only for the first 4-6 weeks. Enforce it in code review, or with a regex check in CI if DNS lives in Terraform or OctoDNS.
4. Migrate existing names in batches. Create the new name, run both side by side, lower the TTL on the old record to 300 seconds, watch traffic for 1-2 weeks, then delete the old one.
5. Delete the old record and the cloud resource behind it in the same change ticket, never separately.
Step 5 matters more than the rest. Most subdomain takeovers start when the resource and the DNS record are retired at different times.
The Myth That Obscure Names Keep Subdomains Hidden
A stubborn belief holds that random-looking names like x7k2-internal.example.com are safe because nobody will guess them. That stopped being true years ago. Any hostname that gets a publicly trusted TLS certificate is written to Certificate Transparency logs, and anyone can search those on crt.sh within minutes. Passive DNS datasets, search engine indexing and a leaked frontend config file expose the rest.
Obscure names give you no security. They only make life harder for your own team. If something shouldn’t be reachable, keep it off public DNS altogether by using split-horizon DNS, a private hosted zone or a VPN-only resolver.
Common Mistakes That Undermine a Naming Scheme
Putting vendor names in hostnames. Names like hubspot.example.com or zendesk.example.com break when marketing moves to another platform, and the old CNAME often stays behind pointing at a decommissioned account. Name the function instead, such as help, go or lp, and record the vendor in your inventory.
Using underscores in hostnames. DNS allows underscores, and they’re required for records like _dmarc and selector._domainkey for DKIM. Hostnames are a different matter: since 2019, publicly trusted CAs have been barred from issuing certificates with underscores in names, so dev_api.example.com will eventually break HTTPS. Keep underscores for service records and use hyphens for hosts.
Treating temporary names as permanent. Campaign and demo subdomains get no expiry date, so they never get removed. Adding a token such as the quarter (spring26-lp) or an expiry TXT record gives cleanup scripts something to act on. The risks here are covered in more detail in when development subdomains become production liabilities.
When the Standard Advice Doesn’t Fit
Teams under 10 people with fewer than 30 records don’t need a four-dimension scheme. Service plus environment is enough, and adding more is overhead. Multi-tenant SaaS platforms that give every customer a subdomain have the opposite problem: tenant names come from user input, so you need a reserved-word list (admin, api, mail, www, autodiscover) to stop a customer from claiming a name that conflicts with infrastructure.
Regulated environments under PCI DSS or NIS2 sometimes require cardholder-data or critical systems to sit in separate zones with separate change approval. In those cases hierarchical delegation is a compliance requirement, not a style choice. Air-gapped and on-prem networks running internal zones on BIND or Active Directory DNS can loosen the public-facing rules, but they should still never reuse a public hostname internally. Split-brain collisions cause some of the most confusing outages there are. More patterns for running many zones are covered in DNS record management in multi-subdomain environments.
FAQ
Should environment come before or after the service name?
Put the service first (api-stg) if you sort and search by service, and the environment first (stg-api) if access control follows environment. Consistency matters far more than which order you choose.
How do I enforce subdomain naming conventions automatically?
Manage DNS as code with Terraform, OctoDNS or DNSControl, and add a CI step that validates each new record name against a regex built from your allowed tokens. Changes made by hand in a provider console will skip this check, so restrict console write access.
Do naming conventions help prevent subdomain takeover?
Indirectly, yes. Consistent names make it easier to match each DNS record to a live resource and an owner, which is how dangling CNAMEs are caught. You still need continuous DNS monitoring to spot when a target disappears.
Summary
A naming scheme that scales encodes function, environment and, where needed, region. It uses hyphens for hosts, keeps vendor names out of hostnames, and delegates non-production to its own zone. Roll it out on new records first, migrate old ones in small batches, and always retire a DNS record in the same change as its resource. A good final check: if a new team member can’t tell what a subdomain does and who owns it just from the name, the convention needs more work.