01
Subdomain Setup: DNS, Routing, and HTTPS
Plan a subdomain as a complete public endpoint: choose the record, prepare host routing, account for DNS caches, and verify TLS and application behavior.
DNS · HTTPS · public hostnames
and.guide explains the path from a name in a DNS dashboard to a working HTTPS response—without collapsing records, routing, certificates, and cache timing into one vague “propagation” problem.
Three learning paths
Understand A, AAAA, CNAME, flattening, TTL, and what a public resolver can actually see.
Start with DNS recordsKeep DNS ownership, provider host binding, redirects, and certificate issuance as separate checks.
Connect a custom domainUse resolver answers and HTTP headers to distinguish cache timing from routing and TLS failures.
Follow the full rolloutEditor’s starting points
Six entry points covering the full path from record choice to public cleanup.
View the full library01
Plan a subdomain as a complete public endpoint: choose the record, prepare host routing, account for DNS caches, and verify TLS and application behavior.
02
Compare direct IPv4 records with hostname aliases, including CNAME coexistence and zone-apex constraints, provider-specific alias features, and verification steps.
04
Configure a Cloudflare DNS record with an explicit target, proxy decision, accurate TTL expectations, and checks for both DNS and the public application path.
06
Use custom domains locally without turning your setup into a guessing game. This guide covers hosts files, local DNS, HTTPS, and when to use a real public subdomain.
11
Choose a public hostname with a purpose-owner-lifecycle worksheet, a practical naming rubric, and an expiry plan for previews and temporary environments.
15
Build an owner-backed inventory of public hostnames, choose the correct keep, protect, redirect, or retire state, and verify cleanup without leaving broken DNS or stale search results behind.
Editorial method
Each guide is organized around a real decision or failure boundary instead of a broad keyword summary.
Product-specific behavior is checked against vendor documentation, standards, or project documentation.
Commands and illustrative outputs make it clear what to inspect, what an answer means, and what it does not prove.
Published, updated, and source-review dates are visible, with a direct path for reporting technical errors.
A secondary service
The site also accepts limited subdomain requests. Names and project context are reviewed manually; availability checks are not a promise of approval or provisioning.