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

A PTR record associates an IP address with a hostname. This is called reverse resolution. Systems use it for logs, network controls, and messaging. To go to an address, we rely on A or AAAA. To return to a name, we rely on PTR.
A PTR 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 PTR DNS record for IPv4

NameTypeTargetTTL in seconds
10.113.0.203.in-addr.arpa.PTRmail.example.net.3600

In this example, the name corresponds to address 203.0.113.10 written in reverse in the in-addr.arpa zone. The target is the expected hostname. A TTL of 3600 corresponds to one hour.

Example PTR DNS record for IPv6

NameTypeTargetTTL in seconds
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.PTRhost.example.net.3600

Here the name takes each hexadecimal digit of 2001:db8::10 in reverse in the ip6.arpa zone. The target is the expected hostname.

Forward and reverse consistency

A good setup matches PTR with A or AAAA. The name returned by PTR must itself resolve to the original address. This consistency helps messaging and diagnostics.

TTL explained clearly

A short TTL makes a change visible faster. Useful during an address switchover.
A medium or long TTL reduces queries to authoritative servers. Useful for a stable configuration.
Reduce the TTL a few hours before a modification, then increase it after validation.

Good to know
An address can publish only one useful PTR. Multiplying PTRs for the same address creates ambiguity. A clear name that then resolves to A or AAAA is better.

Where to use a PTR record

In the reverse zone provided by the address holder. For IPv4, this is done under in-addr.arpa. For IPv6, this is done under ip6.arpa. On blocks provided by an operator, PTR management is often handled in their dashboard.

To avoid
Pointing a PTR to a name that doesn't have A or AAAA records.
Leaving an old target after an address change.
Publishing a generic name that doesn't reflect the actual service.

Online verification

An online DNS lookup allows entering an address. The result displays the name returned by PTR 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=ptr
10.113.0.203.in-addr.arpa

Or simply

nslookup 203.0.113.10
Specific resolver
nslookup
set q=ptr
server 1.1.1.1
10.113.0.203.in-addr.arpa

The first method follows 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 PTR 10.113.0.203.in-addr.arpa
Specific resolver
dig PTR 10.113.0.203.in-addr.arpa @1.1.1.1

For IPv6, we query the ip6.arpa form of the same name.

Quick reading of responses

A response with NXDOMAIN indicates the absence of PTR. Add the entry in the reverse zone.
A returned name that doesn't resolve to A or AAAA signals an inconsistency. Correct the forward zone.
A high TTL may explain a lag after a change.

Simple setup procedure

  1. Verify control of the reverse zone with the ISP or cloud provider.
  2. Choose a clear hostname that resolves to A or AAAA to the address.
  3. Create the PTR with a reduced TTL.
  4. Test with nslookup or dig command from multiple networks.
  5. Increase the TTL when everything is stable.

Practical tip
For messaging, match the PTR record, the name used by the SMTP server, and the associated A or AAAA record. This consistency improves deliverability.

Common cases

Mail server

Require a PTR that returns a dedicated name. The name must resolve to the server's address.

Address range at an operator

Request delegation of the reverse zone or use the provided interface to manage PTRs.

Ephemeral cloud machines

Automate PTR creation and deletion when instances arrive and depart.

Quick troubleshooting

  1. If a service refuses connection, verify the presence of a PTR and consistency with A or AAAA.
  2. If the response remains old, wait for TTL expiration and purge the local resolver cache if possible.
  3. If the provider manages the reverse zone, open a ticket and provide the address and desired name.

In summary, a PTR record provides the name associated with an address. It complements A and AAAA records. An appropriate TTL and forward-reverse consistency simplify checks. Verification goes through an online tool then through nslookup and dig.
With these markers, management remains clear. Changes proceed without stress. Services identify correctly in reverse resolution.