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

An NS record indicates which servers are authoritative for a DNS zone. It lists the names of servers that hold the zone. Resolvers query these servers to obtain other records.
An NS record contains a name, a type, an NS target, and a TTL. The TTL indicates how long the response remains cached in the local resolver.

Example NS DNS record

NameTypeNS ServerTTL in seconds
@NSns1.example.net.3600

In this example, the name @ targets the zone's apex. The target is a hostname. This name must publish A or AAAA records and be reachable.

Example with multiple servers

A zone must publish multiple NS records. This provides redundancy and better availability.

NameTypeNS ServerTTL in seconds
@NSns1.example.net.3600
@NSns2.example.net.3600

Plan for two or more servers. They must respond consistently.

Subdomain delegation

To delegate sub.example.com, add NS records on this name in the parent zone. Each target must resolve to A or AAAA. If the server name is inside the subdomain, the parent zone can publish helper addresses called glue. The objective remains simple. Allow resolvers to quickly reach the subdomain's servers.

TTL explained clearly

A short TTL makes a server change more visible. Useful during a switchover phase.
A medium or long TTL reduces queries to authoritative servers. Suitable for a stable zone.
Reduce the TTL a few hours before a change, then increase it after validation.

Good to know
NS and SOA are published at a zone's apex. A CNAME must not appear on a name that carries NS records. An NS target is always a name, not an address.

Where to use an NS record

At the zone's apex to designate the authoritative servers for this zone.
On a subdomain when delegating this subdomain to dedicated servers.
Child zones have their own SOA and their own NS records.

To avoid
Pointing an NS record to a direct address.
Publishing only one NS on a zone.
Leaving an NS target without A or AAAA.
Having different NS sets between parent zone and child zone without reason.

Online verification

An online DNS lookup allows entering a domain name. The result displays the list of NS servers and the TTL visible from the Internet. It's a useful first check. Then perform a local test from your machine.

Verify on Windows

Windows provides nslookup. It can be used in interactive mode.

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

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

Verify on Linux and Mac

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

Local resolver
dig NS example.com
Specific resolver
dig NS example.com @1.1.1.1

Quick reading of responses

Multiple NS lines indicate multiple servers. Look for varied names and different networks for better resilience.
A high remaining TTL may explain a lag after a change.
A discrepancy between NS records seen from the parent zone and those seen in the zone itself reveals a lack of synchronization.

Simple migration procedure

  1. Prepare the new servers and their A or AAAA records.
  2. Reduce the NS TTL to 300 or even 60 seconds a few hours before the switchover.
  3. Update the zone with the new NS list.
  4. Update the delegation at the registry if necessary.
  5. Verify from multiple networks then increase the TTL when everything is stable.

Practical tip
Keep a record with the list of NS records published on the zone side and registry side. Note the date, TTL, and reason for change. This trace prevents discrepancies during updates.

Common cases

DNS provider change

Publish the new NS records in the zone. Update the delegation at the registrar. Verify consistency.

Subdomain delegation to a team

Add NS records on the subdomain in the parent zone. The team then manages its child zone with its own SOA.

Adding an additional server

Add one more NS. Verify it resolves to A or AAAA and serves the updated zone.

Quick troubleshooting

  1. If the zone sometimes responds with old records, verify the consistency of published NS records.
  2. If an NS server doesn't respond, temporarily remove its entry while repairing it.
  3. If delegation doesn't work, verify the presence of glue addresses when they are necessary.
  4. If the response remains old despite the update, wait for TTL expiration and purge the local resolver cache if possible.

In summary, an NS record designates the authoritative servers of a zone. It must point to reachable and consistent names. A zone publishes multiple NS records for availability. A well-adjusted TTL facilitates transitions. Verification goes through an online tool then through nslookup and dig.
With these markers, management remains clear. Changes proceed without stress. Resolvers find the zone without incident.