HowToCodePage

Subdomains, wildcards and delegation strategies

Creating and delegating subdomains, the risks of wildcard records, per-subdomain nameservers, and naming conventions that still make sense at scale.

Subdomains and subzones

; simple subdomains inside the parent zone
www      IN  CNAME  example.com.
blog     IN  CNAME  example.com.
api      IN  A      203.0.113.30
staging  IN  A      203.0.113.31

; a subzone: the child is authoritative, the parent only delegates
; parent zone
api      IN  NS     ns1.api.example.com.
api      IN  NS     ns2.api.example.com.
ns1.api  IN  A      203.0.113.41
ns2.api  IN  A      203.0.113.42

; child zone, served by ns1.api and ns2.api
$ORIGIN api.example.com.
@        IN  SOA    ns1.api.example.com. hostmaster.example.com. ( 2026091801 7200 3600 1209600 300 )
@        IN  NS     ns1.api.example.com.
@        IN  NS     ns2.api.example.com.
v1       IN  CNAME  api.example.com.
  • A subdomain inside the parent zone is just another record. A subzone needs its own SOA and its own NS records, plus a delegation in the parent.
  • Delegate when a different team owns the records, when a different provider must host them, or when the child needs a different change process.
  • Do not delegate to solve an organisational problem. Every delegation adds a place an outage can hide.

Wildcards and their traps

; a wildcard matches any name at one level, and only if no exact record exists
*        IN  A     203.0.113.50
*.docs   IN  A     203.0.113.51

; these still beat the wildcard
mail     IN  A     203.0.113.60

; the apex is NOT covered by * - add it explicitly if you want it
@        IN  A     203.0.113.61
TrapWhat happensAvoid it by
Typo domains resolveexmaple.example.com answers with the wildcard hostAccepting the noise, or listing subdomains explicitly
Certificate validationA wildcard certificate covers one level onlyUsing the certificate product that matches the name depth
Test names go liveanything.example.com hits productionNever wildcard a zone that serves the public site
Email misdeliveryA wildcard MX accepts mail for typosWildcard A records only, never MX
Exact records forgottenThe wildcard silently serves the wrong targetList every real subdomain explicitly and audit quarterly
Delegation hidden* NS delegates everything belowAlmost never what you want; be explicit
# does a name that should not exist resolve?
dig +short this-should-not-exist-12345.example.com
dig +short www.example.com

# and check whether the answer came from a wildcard
dig this-should-not-exist-12345.example.com | grep -E "ANSWER:|status:"

A wildcard is a useful tool for a documented purpose - a per-tenant subdomain service, for example - and a liability everywhere else. If you cannot state in one sentence why every possible name must resolve, do not add one.

Naming that scales

  • Keep the depth predictable: service.region.example.com or region.service.example.com, but not both.
  • Short names cost nothing and are easier to type: api and cdn beat application-programming-interface.
  • Never encode infrastructure detail in a public name. web-prod-03.example.com leaks topology and is a gift to anyone probing.
  • Use a separate registrable domain for environments that must not share cookies or reputation, such as a marketing staging site.
  • Record the owner of every subdomain in the same repository as the zone, so a stale record has a name attached to it.
Convention that survives growth

  www.example.com              canonical public site
  api.example.com              versioned API
  docs.example.com             documentation
  status.example.com           status page on separate infrastructure
  cdn.example.com              CNAME to the CDN edge
  mail.example.com             MX target (never a CNAME)

  Every other name is either a deliberate service or a bug.
💡
Once you have more than a handful of subdomains, the audit question changes from "is this record correct" to "who owns this name and is it still needed". An inventory file next to the zone, with an owner and a review date per record, answers that without a meeting.

FAQ

Should I put staging on a subdomain of the main site?
Preferably not. A staging subdomain can be indexed, can share cookies, and can be reached by accident. Use a separate registrable domain, basic authentication, and noindex on every page.
Can a wildcard and an exact record coexist?
Yes, and the exact record always wins. That is how you keep a wildcard for a service while pinning a specific name to something else - but it also means a forgotten exact record silently overrides the wildcard.

The DNS hierarchy, zones and delegation DNS and CDNs: apex CNAME, ALIAS and flattening

Last refreshed 2026-09-18.