# DNS setup

DNS, certificates and hosting are separate operator-controlled layers. MarkStack builds files and metadata; it does not register domains, create/check DNS, request TLS certificates or redirect one hostname automatically. Choose the actual reader origin, configure host/provider and records, then build matching configuration and inspect live behavior.

Changing siteUrl does not move traffic. Changing a DNS record does not rebuild metadata or install a certificate. A resolving hostname does not prove the intended page/Host/cookie/perimeter works.

# Names and destinations

Cloudflare’s current record reference confirms A/AAAA/CNAME/TXT roles. Your DNS provider’s proxy/flattening/delegation semantics still matter. Do not copy a fictional IP from this page into a real zone.

# Illustrative zone-style records, not provider dashboard commands.
docs.example.com.      300  IN  A     203.0.113.10
docs.example.com.      300  IN  AAAA  2001:db8::10
www.example.com.       300  IN  CNAME example.com.

Dashboard name fields may expect relative labels, full names or different TTL formats. Inspect the actual provider interface and zone before saving. A CNAME target is a hostname, not https://... or a path. Existing conflicting records and delegated subdomains need deliberate review.

# Apex and canonical address

Cloudflare CNAME flattening supports apex CNAME configuration by returning resolved IP addresses. That is provider behavior, not ordinary CNAME support on every DNS platform. Do not assume another provider accepts identical apex setup.

Pick canonical reader address and redirect the alternative through the actual host/proxy/provider. DNS aliases alone do not create HTTP redirects or canonical metadata. Set siteUrl to final origin/path and baseUrl to intended subpath. Authored Markdown paths need their own prefix handling.

# Cloudflare Pages association first

Open the intended project’s custom-domain flow and use actual successful deployment/hostname. Do not derive a guessed .pages.dev URL from display name. If the zone already uses Cloudflare, follow record confirmation there. For an external DNS provider, create the requested CNAME after Pages association. Enterprise zone holds/policy can affect activation and require separate operator review.

Check actual domain status and HTTPS before releasing that URL. An account connection or an editable zone does not approve a domain cutover. Cloudflare setup covers project/build/output distinction.

# Direct server and TLS

For a VPS/static or editor proxy, point intended A/AAAA to reachable listener host, then issue/install certificates through selected ACME/host process. Do not add AAAA merely because one is in the example: broken IPv6 can fail clients even when IPv4 works.

These are current Let’s Encrypt rules, not a MarkStack certificate service. For HTTP-01 the name must resolve to correct validation endpoint and port 80 be reachable; multiple servers must supply challenge. Supported redirects have their own restrictions. A certificate renews through ACME client, not through reader build.

DNS-01 can validate a private web service without public web-server reachability, but requires correct DNS control/propagation and a reliable automated renewal process. Use narrowly scoped credentials or separate validation service. Do not put full DNS API keys in Markdown, repository, command arguments or support logs.

The proxy supplies browser HTTPS and certificate chain. V2 secure cookie setting does not create TLS. Keep editor exact allowed Host and real trusted proxy connection addresses aligned with actual hostname/port/chain.

# TTL and cutover planning

Lower a configurable TTL ahead of an intended move if your provider permits it, then allow previous cached answers to age. It is not a promise immediate global propagation. Cloudflare proxied record TTL is automatic/noneditable under current policy; DNS-only choices differ. Do not demand a provider setting that its current record mode does not expose.

Keep old destination available as required by your cutover/return plan. Certificate, host config and artifact must be ready on the new destination before traffic moves. Record actual accepted DNS target and observed reader, not just dashboard save.

# Read-only lookup examples

dig docs.example.com A +short
dig docs.example.com AAAA +short
dig docs.example.com CNAME +short
dig @1.1.1.1 docs.example.com A +short
nslookup docs.example.com

These examples send the hostname to the selected resolver; use only appropriate public names. Tools may need OS installation and organizational resolver policies. Review authority/record and both IPv4/IPv6 from more than one network where needed. An empty CNAME response under flattening/proxy mode is not alone proof of failure; inspect provider behavior and resulting reachable host.

Then check HTTP/TLS and actual content, not only DNS. Search/index/resources can still use wrong origin/prefix. A resolving editor name can still fail exact Host/cookie/proxy controls; do not disable them to mask misconfiguration.

# Failure matrix

Protect private data and avoid production destructive tests. No registrar/DNS zone, certificate issuance, renewal or real traffic cutover was performed for this guide. Source-backed templates need staging/production verification on your infrastructure.

# Official sources

Checked 12 October 2026:

• Cloudflare record types.
• Cloudflare CNAME flattening.
• Cloudflare TTL.
• Pages custom domains.
• Let’s Encrypt challenge types.