Subdomain Naming Rules for Public Projects

A public hostname becomes a promise. docs.example.com suggests documentation, status.example.com suggests trustworthy service health, and login.example.com suggests an authentication boundary. The DNS record may take seconds to create, but the expectation created by the name can last for years.

Choose the label only after the audience, owner, destination, and lifetime are known. That order prevents a temporary deployment nickname from becoming a permanent public contract.

Start with the technical boundary

For conventional Internet hostnames, use ASCII letters, digits, and hyphens. A label must begin and end with a letter or digit; RFC 1123 relaxed the older rule so a leading digit is valid. DNS label comparison is case-insensitive, and an individual label is limited to 63 octets.

Those are protocol limits, not naming targets. A public label that uses all 63 characters may be valid and still be difficult to read, dictate, log, or fit into certificates and dashboards. Prefer the shortest label that remains unambiguous.

clear and durable        docs.example.com
clear and scoped         api-eu.example.com
temporary by design      pr-482.preview.example.com
hard to own later        final-new-prod-2.example.com
authority-confusing      secure-account-support.example.com

If a DNS provider, hosting platform, or subdomain program applies a stricter length or reserved-name rule, the stricter rule wins.

Complete the purpose-owner-lifecycle worksheet

Do not approve a name from the label alone. Record the operating facts beside it:

Requested hostname:
Public purpose:
Primary audience:
Service owner:
Destination platform or origin:
Authentication required: yes / no
Search visibility: index / noindex / private
Lifecycle: permanent / release-scoped / temporary
Review or expiry date:
Replacement or redirect plan:
Abuse and incident contact:

The worksheet catches two expensive gaps early:

• No owner: nobody can fix a certificate, remove a stale route, or answer an abuse report.
• No lifecycle: a preview hostname remains public because no event says when it should end.

If the destination record type and HTTPS plan are not known yet, pause naming and work through the subdomain setup sequence first.

Score the name before publishing it

Use a small rubric to make trade-offs visible. Score each dimension from 0 to 2; any zero is a reason to revise, even if the total looks acceptable.

Dimension	0	1	2
Purpose clarity	Misleading or opaque	Understandable only with team context	A visitor can predict the surface
Authority fit	Implies authority the service does not have	Broad label with a real owner	Scope and authority match
Durability	Tied to today’s deployment nickname	Likely to need renaming	Still useful after platform changes
Collision risk	Conflicts with infrastructure or another team	Similar to an existing label	Namespace owner confirms it is distinct
Lifecycle	No owner or end state	Owner exists but cleanup is manual	Owner, review date, and retirement action are recorded

Example:

Candidate	Clarity	Authority	Durability	Collision	Lifecycle	Decision
docs.example.com	2	2	2	2	2	Publish for the canonical docs site
status.example.com	2	0	2	2	1	Reject until a real status process and owner exist
pr-482.preview.example.com	2	2	1	2	2	Publish with automated expiry
new-prod.example.com	0	1	0	1	0	Rename before creating DNS

The numbers are an internal decision aid, not a universal ranking signal. The written reason and accountable owner matter more than the sum.

Treat authority-bearing labels as reserved by default

Some labels carry security or organizational meaning:

• login, auth, account, and secure imply identity handling
• billing, pay, and checkout imply financial actions
• status implies current, maintained incident information
• support and help imply an active response channel
• admin, internal, vpn, and sso imply privileged access
• vendor and product trademarks imply an official relationship

Reserve these labels until the named function exists, the responsible team accepts ownership, and the page delivers what the label promises. A static placeholder at status.example.com is worse than having no status hostname because it creates false confidence during an incident.

For multi-team domains, maintain a namespace registry with reserved infrastructure labels, delegated prefixes, and contacts. DNS can technically contain overlapping ideas such as docs, developer-docs, and help-docs; the registry prevents that ambiguity from reaching users.

Separate permanent surfaces from temporary environments

Permanent names describe a stable visitor purpose:

docs.example.com
api.example.com
handbook.example.com
status.example.com

Temporary names should encode both scope and cleanup mechanics:

pr-482.preview.example.com
release-2026-07.preview.example.com
client-a.review.example.com

Avoid labels such as test, temp, or new without an identifier and expiry. They say that the surface is temporary but provide no way to determine which deployment owns it or when it can be removed.

A useful temporary-host policy includes:

1. a predictable prefix such as preview.example.com
2. an owner derived from the deployment or repository
3. authentication or noindex when the surface should not be discoverable
4. deletion after merge, release, or a fixed retention window
5. a final 404 or 410 state when an exposed URL is retired

If a wildcard will route these environments, read the wildcard DNS and TLS guide before assuming one record or certificate covers every depth.

Illustrative naming worksheet

The image below shows a compact way to keep purpose, owner, and expiry beside a proposed hostname. It is not a capture from a live request system.

Illustrative example using reserved example domains and IPs.

Validate the expectation, not only the syntax

Before launch, ask three different questions.

Does DNS contain the intended name?

dig docs.example.com A +short
dig docs.example.com AAAA +short
dig docs.example.com CNAME +short

Record which answer is expected. Empty output for one type is not automatically a failure when another type is the actual contract.

Does the destination accept the hostname?

curl -I https://docs.example.com

Confirm valid TLS, the correct application, and the intended redirect. A correct DNS answer that reaches a default hosting page is not a successful launch.

Does the name communicate the right job?

Ask someone outside the implementation team what they expect to find at the hostname. If the answer differs from the intended surface, revise the name before links, callbacks, and bookmarks make it expensive.

Google’s URL guidance concerns full URLs rather than DNS governance, but the same user-facing principle is useful here: readable, descriptive words are easier to understand than opaque identifiers. Keep unavoidable build IDs in a controlled preview namespace instead of using them for permanent product surfaces.

Record the decision and the exit

The final naming record should contain:

• the approved hostname and plain-language purpose
• the DNS and application owners
• the expected record type and target
• whether the surface is public, noindex, or authenticated
• the certificate strategy
• the creation date and next review or expiry date
• the redirect, 404, or 410 action when the name is retired

Feed those records into a recurring public subdomain inventory and cleanup runbook. A durable naming system is not one that never changes; it is one where every public name has an owner, a clear promise, and a documented way to end.