Subdomain to a CDN
- Input
- cdn.example.com CNAME → dxxxxx.cloudfront.net
- Expected output
- Cadeia CNAME resolvida pelos três resolvers
The root domain usually cannot use a literal CNAME.
Carregando ferramenta… / Loading tool…
CNAME record propagation
CNAME is the most common record when connecting a subdomain (www, cdn, assets) to a third-party service, a CDN, a hosting platform or a load balancer, because those services often change IPs without notice, and CNAME avoids having to track that manually.
The root domain usually cannot use a literal CNAME.
Common on platforms like Vercel, Netlify and Cloudflare Pages.
It's the time a DNS record change takes to be reflected across every recursive resolver in the world. There is no mechanism to "push" the change, each resolver only fetches the new value after the old cached value's TTL expires.
The DNS spec forbids a CNAME from coexisting with other records at the same name, and the zone apex always needs NS and SOA records. Most DNS providers offer a proprietary substitute (ALIAS/ANAME) that behaves like a CNAME under the hood.
The resolver automatically follows the CNAME chain until it finds a real A/AAAA record, and returns both. This is normal and expected.
It follows the same TTL rule as any record. The practical advantage of CNAME is that, once propagated once, the target provider (the CDN) can change its own IPs freely without you needing to change anything or wait for a new propagation on your end.
The check queries 3 public resolvers (Cloudflare, Google Public DNS and DNS.SB) in parallel, straight from your browser, without touching our server. If all of them agree, propagation is complete.
For safety, the browser talks directly to fixed public resolvers, passing only the queried name, the J-Kit server is never used as an intermediary, avoiding IP exposure and SSRF. A DNS query is public by nature, like any name resolution.