A record lookup (IPv4)

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 A records

An A record links a domain name to an IPv4 address. For example, it is the answer from this record that lets the browser reach the right server to visit a website. For IPv6 use an AAAA record. A PTR record does the reverse and maps an IPv4 address to a name.
An A record has a name, a type, a value and a TTL. TTL tells how long the answer stays cached in the local resolver.

Example DNS A record

NameTypeIPv4 addressTTL in seconds
wwwA203.0.113.103600

In this example the name www is a subdomain. To target the domain apex use the at sign. The value must be a valid IPv4 address that is reachable on the Internet. TTL 3600 equals one hour.

Example with several addresses

Publishing several A records for one name is possible. The local resolver receives a list and picks one. This simple rotation spreads a load across servers.

NameTypeIPv4 addressTTL in seconds
wwwA203.0.113.103600
wwwA203.0.113.113600

This rotation does not replace real automatic failover. If one address is down some visitors can still receive it for a short time.

TTL explained in plain words

TTL (time to live) is the number of seconds a resolver keeps an answer in its cache before asking the authoritative servers again. While the timer runs every visitor receives the cached IPv4 address, so changes only appear after the countdown reaches zero.
A short TTL such as 60 or 300 seconds lets you adjust records quickly, but it increases the query load on your authoritative servers and can make outages more noticeable. A longer TTL such as 3600 seconds or more reduces traffic and keeps responses stable, yet it delays the effect of any update.
Before a planned migration lower the TTL at least a few hours in advance—ideally the previous day—so caches refresh with the shorter value. Perform the change once the old TTL has expired everywhere, monitor the switch, and raise the TTL again when the new setup is stable.

Good to know
Some resolvers ignore sudden TTL drops if they cached the old longer value. Plan ahead so caches have time to expire naturally before you rely on the shorter timer.

Where to use an A record

At the domain apex publish A records. Setting a CNAME there is not compliant.
For www you can use an A record when you control the IP address. Otherwise, choose a CNAME when pointing to another name managed by a provider.
For other subdomains like api cdn blog, you can use CNAME A or AAAA records. Each service can keep its own address. Changes then stay simple.

Avoid
Mixing A and CNAME on the same name which is not RFC compliant.
Publishing a private address in a public zone.
Leaving an old A record after a migration.

Check online

An online DNS lookup lets you enter a domain name. You get the list of IPv4 addresses for the A record and the TTL visible from the Internet. It is 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=a
www.example.com
Specific resolver
nslookup
set q=a
server 1.1.1.1
www.example.com

The first part queries an A record using the machine's network settings. The second part forces a third party resolver here Cloudflare.

Check on Linux and on Mac

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

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

Quick reading of the answers

Several IPv4 addresses mean simple traffic spreading.
A high remaining TTL can explain a delay after a change.
An empty answer or a resolution failure often points to a bad entry or an address removed too early.

Simple migration plan

  1. Prepare the new server with its new address.
  2. Lower TTL to 300 or even 60 seconds on the name a few hours before the switch.
  3. Replace the old address with the new one at the planned time.
  4. Check with nslookup or the dig command from several networks.
  5. Raise TTL to a comfortable value when everything is stable.

Practical tip
Keep a tracking sheet for each name. Note the owner the date the chosen TTL and the reason for the change. This trace prevents misses and speeds a rollback if needed.

Common cases

Site behind a content delivery network (CDN)

Use CNAME for www to follow provider changes and keep an A record on the root domain.

Multi region environment

Publish several addresses close to visitors. The local resolver picks one IPv4 address from the list. For precise location-based routing you need advanced DNS features or an application network.

Mail server

The A record publishes the IPv4 address of the mail server. The reverse PTR helps deliverability. Both should match. Updates do not sync in both directions by themselves.

Quick troubleshooting

  1. If the site does not respond check local resolution first.
  2. If the answer shows a private address fix the public zone.
  3. If answers rotate between two addresses and one is offline remove the failing address.
  4. If the answer stays old after an update wait for TTL to expire and clear the local resolver cache if possible.

To summarize, an A record maps a name to an IPv4 address. TTL controls cache time in the local resolver. Several addresses can spread traffic but do not create failover. CNAME does not live with an A record on the same name. The apex publishes A records. Verification starts with an online tool, then with nslookup on Windows and with dig on Linux and on Mac.
With these basics management stays simple. Changes happen without stress. Visitors reach the site without issues.