Subdomain Setup: DNS, Routing, and HTTPS

A subdomain is ready only when four layers agree: DNS identifies a destination, the destination recognizes the hostname, TLS covers that hostname, and the application returns the intended response.

Changing only the DNS record can therefore produce a correct DNS answer and a broken site. This guide treats the hostname as a small deployment with an owner, a rollback plan, and checks at every layer.

Define the public contract

Write down these details before opening a DNS dashboard:

• the exact public hostname
• the team or person responsible for it
• the destination supplied by the hosting provider or origin operator
• the required record type and proxy mode, if any
• the mechanism that will issue and renew TLS
• the old value or record that will be restored if the change fails

If the destination documentation is unclear about whether it expects an IP address or a hostname, resolve that first. The A record and CNAME comparison explains the protocol-level difference and the important apex exception.

Choose a name that describes the service

Names such as these communicate a stable role:

• docs.example.com
• status.example.com
• preview.example.com
• api.example.com

Names such as site2, temp-final, or new-prod encode a moment in time rather than the service’s purpose. If the endpoint has an expiry date, record that date and owner outside DNS rather than hiding lifecycle information in an ambiguous label.

Match the record to the documented target

For common subdomain deployments:

• an A record contains an IPv4 address
• an AAAA record contains an IPv6 address
• a CNAME aliases one DNS name to another DNS name

The provider’s setup instructions remain the source of truth. Do not resolve a provider hostname once and copy its current IP into an A record; that bypasses the provider’s ability to change its own address mapping.

The following zone-file-style records are examples, not values to publish:

app.example.com.    300    IN    CNAME    tenant.hosting.example.
api.example.com.    300    IN    A        203.0.113.42

example.com, .example, and 203.0.113.0/24 are reserved for documentation. Replace them with the real hostname and target supplied for your deployment.

Prepare host routing before the DNS cutover

DNS directs a request toward an endpoint; it does not tell a reverse proxy which application should handle the request. A self-managed NGINX endpoint might use a server block like this:

server {
  listen 443 ssl;
  http2 on;
  server_name docs.example.com;

  ssl_certificate /etc/letsencrypt/live/docs.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/docs.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
  }
}

This is an illustrative NGINX fragment, not a complete production configuration. The operational point is that the destination needs an explicit binding for docs.example.com; otherwise it may return a default site or reject the host.

Managed platforms usually expose an equivalent “custom domain” or “domain binding” step. Complete that step before or alongside the DNS change, following the platform’s documented order.

Treat TTL as cache policy

TTL controls how long recursive resolvers may cache a DNS answer. Lowering a TTL does not invalidate copies that were already cached with the previous, longer TTL.

For a planned cutover:

1. lower the TTL far enough in advance for the old TTL window to expire
2. change the record
3. leave the old destination available during the expected cache overlap when practical
4. raise the TTL only after the endpoint is stable

Cloudflare has a provider-specific detail: proxied records use Auto, currently 300 seconds, and that value cannot be edited. DNS-only records can use Auto or a supported custom value. See the DNS propagation and cache guide for a resolver-by-resolver verification method.

Verify the DNS answer, not just the dashboard

Start with the record type you intended:

dig app.example.com CNAME +noall +answer
dig api.example.com A +noall +answer

Then compare independent recursive resolvers:

dig @1.1.1.1 app.example.com CNAME +noall +answer
dig @8.8.8.8 app.example.com CNAME +noall +answer

For a high-risk change, also query each actual authoritative name server directly. Agreement at the authoritative layer proves the zone is consistent; agreement between recursive resolvers shows caches are catching up.

Worked verification illustration

Illustrative example using reserved example domains and IPs. The following SVG is a constructed teaching aid, not a terminal capture from a live deployment. Provider-style labels or response values shown in it are placeholders.

Illustrative example using reserved example domains and IPs. It does not contain customer data or evidence of a production change.

Use the sequence, not the literal sample values: inspect the DNS record, confirm the resolved destination, and then test the public HTTPS endpoint.

Validate TLS for the exact hostname

Certificate automation varies by platform and ACME client. With Let’s Encrypt:

• HTTP-01 validation retrieves a token over port 80 for the requested hostname
• DNS-01 validation checks a TXT record under _acme-challenge
• wildcard certificate issuance requires DNS-01

Follow the hosting platform or ACME client’s instructions rather than adding validation records speculatively. After issuance, test the actual endpoint:

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

Substitute your real hostname. A 200, 301, or 302 can all be intentional; verify the complete behavior instead of treating one status code as universally correct:

• the certificate is valid for the requested hostname
• the redirect target is expected
• the response comes from the intended application
• HTTP-to-HTTPS behavior matches the deployment policy

Diagnose by layer

Observation	Likely layer to inspect
No record or wrong target in dig	Authoritative DNS configuration
Authoritative answer is new but recursive answers differ	Resolver caches and remaining TTL
DNS is correct but the wrong site appears	Host binding, reverse proxy, or platform domain mapping
Correct app over HTTP but TLS warning over HTTPS	Certificate issuance, SNI, or certificate attachment
TLS works but callback or login fails	Application base URL, redirect URI, or trusted-host configuration

This separation prevents repeated DNS edits from obscuring an application or certificate problem.

Record the completed change

Keep a short change note containing:

• hostname and record ID
• previous and new values
• proxy status
• TTL before and after the rollout
• destination owner
• certificate issuer or platform
• verification time and commands used
• rollback condition

For Cloudflare-hosted zones, the Cloudflare DNS setup guide covers proxy status and Cloudflare’s fixed TTL behavior for proxied records. The same layered checks still apply with another authoritative DNS provider.