CNAME Record Lookup

In iterative trace mode, the resolver is ignored.
Query multiple public resolvers to compare answers.

How to use the DNS lookup engine options effectively

What is the iterative trace?

The trace performs resolution step by step. The resolver first queries the root servers, then the TLD (.com, .fr, .eu), and then the authoritative servers of the target zone. At each step, the page shows the queried server, the answer, the RCODE, and the latency.

  1. 1. Root

    Discovery of the TLD servers for the requested name.

  2. 2. TLD

    Reference to the zone's NS (delegation).

  3. 3. Authoritative

    Final answer (or error) with TTL and latency.

What is it for?

  • Compare answers across resolvers and regions
  • Detect a hot cache, an overly long TTL, or an incomplete delegation
  • Explain a latency difference or an unexpected RCODE

Tip: keep the trace disabled for quick checks; enable it when investigating or preparing a ticket/post‑mortem.

What is the classic trace?

The classic trace queries only the selected resolver (UDP or DoH) and displays the answer as it is perceived from that network vantage point. You get the RCODE, the response sections, and the latency for the client → resolver leg.

  1. 1. Chosen resolver

    Uses the preset or custom configuration to run the query exactly like your service would.

  2. 2. Protocol preserved

    Respects the selected transport (UDP, TCP, or DoH) so you reproduce the real behaviour.

  3. 3. Detailed answer

    Shows the question, answer, and authority/additional sections when present, together with TTL and useful metadata.

Why use it?

  • Check the view of a specific resolver before suspecting delegation issues
  • Confirm cached values and the impact of a TTL or a flush
  • Document a resolution exactly as a client or microservice sees it

Tip: keep the iterative trace option turned off when auditing a given resolver; enable it afterwards to compare with the root → TLD → authoritative path.

How does the propagation test work?

The test queries a set of public resolvers (Google, Cloudflare, Quad9, OpenDNS, ISPs…) in parallel and groups the answers by content and RCODE. You instantly see who already picked up the update.

  1. 1. Multi-point resolvers

    Enables the propagation presets to question several actors spread around the world.

  2. 2. Automatic comparison

    Groups identical answers and highlights divergences or resolver-specific errors.

  3. 3. Actionable summary

    Provides a clear recap, the resolver list, their latencies, and each group's status.

When to use it?

  • Track how a DNS change propagates worldwide
  • Spot stale caches and decide on a targeted flush
  • Share a propagation snapshot in a ticket or post-mortem

Tip: while the propagation test is active, the resolver selector is frozen. Disable the mode to return to single-resolver diagnostics.

Additional information about DNS CNAME records

A CNAME record creates an alias. It links one domain name to another name. The resolver then follows that target name to find A or AAAA records. The browser then obtains the server address through this chaining.
A CNAME record contains a name, a type, a target, and a TTL. The TTL indicates how long the response remains cached in the local resolver.

Example of a DNS CNAME record

NameTypeTargetTTL in seconds
wwwCNAMEhost.example.net.3600

In this example, the name www is an alias. The target is another domain name. That target name must publish A or AAAA records to provide an address. A TTL of 3600 corresponds to one hour.

Only one CNAME per name

The same name cannot have multiple CNAME records. A CNAME cannot coexist with other records at the same location. No A, no AAAA, no MX, no TXT at the same label. The CNAME must stand alone.

TTL explained plainly

A short TTL speeds up the visibility of a target change. Useful during a migration to a new provider.
A medium or long TTL reduces queries to the authoritative servers. Suitable for a stable service.
It's recommended to lower the TTL a few hours before a switchover, then raise it back once everything is stable.

Good to know
A CNAME can chain to another CNAME. This works, but each hop adds a slight delay. It's better to point directly to the final name whenever possible.

Where to use a CNAME

At the root of a domain name (the apex), avoid using a CNAME because the apex must already publish SOA and NS. Some providers offer an equivalent feature called flattening or ALIAS.
For www, a CNAME is often convenient when the target is managed by a provider. For api, cdn, or static, a CNAME keeps the architecture flexible. The target can change without touching the original name.

To avoid
Placing a CNAME at the same location as an A, AAAA, MX, or TXT is not compliant.
Using a CNAME at the apex without a provider's dedicated feature.
Pointing an MX record to a name that itself is a CNAME. The MX must point to a name that publishes A or AAAA.

Check online

An online DNS lookup lets you enter a name. You get the CNAME target and the TTL as visible from the Internet. It's a useful first check. Then run a local test from your machine.

Check on Windows

Windows provides nslookup. You can use it in interactive mode.

Local resolver
nslookup
set q=cname
www.example.com
Specific resolver
nslookup
set q=cname
server 1.1.1.1
www.example.com

The first part queries, according to the machine's network configuration. The second part forces the use of a third‑party resolver, here Cloudflare's.

Check on Linux and on Mac

On these systems, the dig command is handy and easy to use.

Local resolver
dig CNAME www.example.com
Specific resolver
dig CNAME www.example.com @1.1.1.1

Quick reading of responses

A response showing a CNAME indicates the target name. You must then verify that this target name does publish A or AAAA.
A high remaining TTL can explain a delay after a target change.
An overly long CNAME chain can create latency. Shorten the chain when possible.

Simple migration procedure

  1. Prepare the final target that publishes A or AAAA.
  2. Lower the CNAME TTL to 300 or even 60 seconds a few hours before the switchover.
  3. Change the CNAME target at the planned time.
  4. Verify with nslookup or the dig command from multiple networks.
  5. Raise the TTL back to a comfortable value once everything is stable.

Practical tip Note the current target and the planned target before any modification. Keep the date, the TTL, and the reason for the change. This record prevents confusion and speeds up rollback if needed.

Common cases

Site behind a content delivery provider (CDN)

Set www as a CNAME to the name provided by the CDN. Keep A and AAAA records at the apex if the platform offers an apex CNAME equivalent.

External services

For a third‑party–managed service such as transactional email or analytics, a CNAME lets you delegate resolution without publishing an address.

Separating preproduction and production

Point preprod as a CNAME to a distinct hosting name. A simple switch by changing the target when the version is validated.

Quick troubleshooting

  1. If the site does not respond, first check that the CNAME points to the correct name.
  2. Verify that the target publishes A or AAAA. Without that, resolution will not provide an address.
  3. If a service changes infrastructure, update the target. Avoid unnecessary chains.
  4. If the response remains old, wait for the TTL to expire and purge the local resolver cache if possible.

In summary, a CNAME record creates an alias between two names. The resolver follows the target to obtain A or AAAA records. A CNAME must be alone at the same location. Avoid using a CNAME at the apex unless the provider offers a dedicated feature. Verification starts with an online tool, then with nslookup and dig.
With these guidelines, management stays clear. Changes proceed without stress. Visitors reach the site without incident.