From buying a domain through A records, CNAMEs, proxies, and certificates – the whole journey from acquiring a domain name to hosting your application on HTTPS via containers.
DNS records for every situation
Sub-Domain 'app.example.com' : A Record to the server IPv4; AAAA can be added if there is IPv6. The easiest and most common
Root Domain/Apex 'example.com': Also an A Record; Classic CNAME cannot be used for the root domain, although ALIAS/Flattening at services such as Cloudflare helps circumvent that issue
Wild Card (*. example.com ): A single record directs all subdomains to the server and works great when preview URLs are required per client or branch; can be used along with DNS-01 for wildcard certificate
www: Use CNAME to direct www to the root domain, and vice versa at the proxy
TTL: 300s during setup; increases to 3600+s when ready
How a single server manages many domains
All the domains point to the same IP address; however, the proxy distinguishes between them through the Host header (and the SNI when using TLS). When requests are sent to app-a.com, they go to container A, and when requests are made to app-b.com, they are forwarded to container B; hundreds of domains on one machine without port forwarding. In Peon, you just add your domain to the service setup.
Verification, layer by layer
DNS incorrect: fix the entry; confirm that you modified the live nameservers (confusion between registrar and Cloudflare is common)
DNS correct, routing incorrect: the domain isn’t linked to the service or container is sick; verify proxy logs
Routing correct, TLS failed: most likely port 80 is firewalled or DNS was incorrect just a while ago; certificates try again automatically
Layer 1: DNS
dig +short app.example.com # expect your server IP
Layer 2: routing (bypass DNS, test the proxy directly)
curl -H "Host: app.example.com" http:/// -I
Layer 3: TLS
curl -vI https://app.example.com 2>&1 | grep -E "subject|expire"
Propagation myths
The well-known “wait 48 hours” myth is folk wisdom. DNS updates can be seen as quickly as cache expirations, usually in minutes, based on your record’s TTL. Where things go wrong: Your local OS has cached the old value (try using dig @1.1.1.1 to query from an external DNS server), negative caching if you have previously queried the name before adding the new record, and modifying the zone file when you don’t control the domain.
Top comments (0)