SAYLOR Trace a broken hostname from authoritative DNS through certificate delivery, proxy routing, origin reachability, and application health.
The result you're building
A hop-by-hop proof showing which layer fails — authoritative DNS, recursive resolution, network reachability, TLS/SNI, reverse proxy, origin listener, or application — followed by one corrected configuration and external verification.
Use when: a hostname is down, intermittent, points to the wrong site, has certificate warnings, loops redirects, or returns a proxy error; a deployment works at its provider URL or localhost but not the custom domain; DNS or hosting was recently moved.
Not a substitute for: changing several DNS records, nameservers, certificates, and proxy settings at once; treating local resolver cache as proof of global propagation.
Before you change anything, collect: exact hostname, expected provider/origin, whether apex and www should both work; registrar and authoritative DNS provider; current A/AAAA/CNAME/TXT/CAA/nameserver records; hosting deployment status and origin health URL; certificate names/issuer/expiry and redirect expectations.
Understand the system first
- DNS answers where to connect; TLS proves which server answered — a correct IP doesn't guarantee the right virtual host or certificate. Test DNS, TCP, TLS SNI, HTTP routing, and origin health as separate hops.
- Authoritative truth and recursive cache can differ — query the authoritative server for current config, then multiple recursive resolvers for propagation. TTL limits caching but doesn't force instant refresh.
- Proxy errors describe the hop that failed — 502 usually means the proxy got an invalid upstream response; 504 means it waited too long; a certificate name error occurs before application routing.
Evidence-to-decision map
| Evidence | Likely layer | First check | Meaning |
|---|---|---|---|
| NXDOMAIN / no answer | DNS | dig +trace HOST + authoritative query | Missing delegation/record, DNSSEC failure, or wrong zone owns it |
| Correct IP, wrong TLS name/issuer | TLS/SNI | openssl s_client -servername HOST -connect HOST:443 | Wrong cert binding or traffic reaching an unintended server |
| TLS works, 404/wrong site | Virtual host | curl -I --resolve HOST:443:IP https://HOST | Proxy/site routing doesn't match Host or deployment |
| 502/504 | Origin/proxy | Test origin locally, inspect proxy logs | Listener, bind, protocol, timeout, or upstream name wrong |
| Only some users fail | Cache/IPv6 | Compare A/AAAA across resolvers/networks | Stale answers, broken AAAA, split DNS, regional state |
Step-by-step procedure
01 Record authoritative delegation.
dig +trace example.com
dig NS example.com +short
dig @AUTHORITATIVE_NS example.com A +noall +answerIf delegation and the dashboard disagree, correct registrar nameservers or operate at the authoritative provider.
02 Compare public resolution including IPv6.
dig @1.1.1.1 HOST A +short
dig @8.8.8.8 HOST AAAA +short
dig HOST CNAME +noall +answerRemove AAAA only when IPv6 is intentionally unsupported and dependencies are checked.
03 Test TLS with the correct SNI.
openssl s_client -connect HOST:443 -servername HOST -showcerts </dev/null
curl -Iv https://HOST/The hostname must appear in SANs and verification must succeed.
04 Force-route to distinguish DNS from hosting.
curl -I --resolve HOST:443:TARGET_IP https://HOST/
curl -IL --max-redirs 10 https://HOST/Forced success + ordinary failure = DNS/cache. Both failing the same way = edge/vhost/app.
05 Test origin before proxy.
sudo ss -ltnp
curl -i http://127.0.0.1:PORT/health
sudo nginx -t
journalctl -u APPUNIT -b --no-pager | tail -n 100Local failure = app/service. Local success + public 502 = proxy routing, permissions, or network boundary.
06 Verify externally, preserve mail/service records. Retest apex and www, IPv4/IPv6, redirects, TLS chain, core page, and email DNS records.
Worked example
www.example.com works but the apex shows a certificate warning after migration. Authoritative www CNAME points to the new host; the apex A record still points to the old server; the old server's cert excludes the apex; forced apex resolution to the new host serves the correct cert and site. Decision: the migration omitted the apex record. Fix: recorded the full zone and old apex value, changed only the apex to the documented target, queried authoritative then public resolvers as TTL expired, verified apex redirects once to the canonical HTTPS URL. Proof: both names resolve to the intended platform, present valid SAN coverage, and mail records are unchanged.
Verify, recover, hand off
Complete when: authoritative and public answers converge; A and AAAA both work (or unsupported records are absent); cert chain verifies with full SAN coverage; redirect chain is finite and correct; origin health and public request both succeed; email/verification records intact.
Rollback: restore exported DNS values when the intended edge doesn't serve the domain; keep the old deployment up through at least the max old TTL when practical; revert proxy config from the saved copy if validation fails before reload.
| Symptom | Usually means | Next move |
|---|---|---|
| Authoritative correct, laptop wrong | Recursive/OS/browser cache | Query a public resolver directly, wait TTL |
| A works, AAAA fails | Broken IPv6 route or wrong AAAA | Repair IPv6 or remove unsupported AAAA after confirming deps |
| TLS valid but endless redirects | Proxy/app disagree on scheme or canonical host | Inspect forwarded headers, one canonical redirect owner |
| 502 only through proxy | Origin protocol/port/bind/permission/timeout mismatch | Compare proxy upstream with local listener and logs |
Handoff record: domain, authority, intended DNS targets, saved original zone; A/AAAA/CNAME from authoritative and recursive; TLS subject/SAN/issuer/expiry/fingerprint; status/redirect/body results for normal/forced/local-origin tests; exact changed record/config, TTL, verification time, rollback value.
For agents
Inputs: hostname (FQN, no guessed apex/www relationship), expectedTarget (provider/IP/CNAME/origin/canonical URL), dnsEvidence (authoritative + recursive with timestamps), httpEvidence (TLS/headers/redirects/origin health/logs). Output: diagnosis, plan, verification, handoff. Same refusal/escalation/confidence rules as the series.
References
- https://www.cloudflare.com/learning/dns/what-is-dns/
- https://letsencrypt.org/docs/
- https://nginx.org/en/docs/http/configuring_https_servers.html