Simple = one query to the resolver · Trace = descent from the root
optionsAdvanced options
Key features
CAA answer for the queried name
See the CAA records returned for the name you entered, with their values (Let's Encrypt, DigiCert, etc.) and their TTL.
Multi-resolver
Compare responses from Google, Cloudflare, and Quad9 to detect propagation issues.
Issue and issuewild tags
The sections below explain what each tag does. The tool shows the values exactly as returned, without interpreting them.
Iodef tag
Read the iodef notification address if the domain publishes one. The tool does not test whether it is reachable and cannot guarantee any notification.
Free and unlimited
Test as many domains as needed. No signup required.
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. Root
Discovery of the TLD servers for the requested name.
2. TLD
Reference to the zone's NS (delegation).
3. Authoritative
Final answer (or error) with TTL and latency.
What is it for?
Compare answers across resolvers
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. Chosen resolver
Uses the preset or custom configuration to run the query exactly like your service would.
2. Protocol preserved
Respects the selected transport (UDP, TCP, or DoH) so you reproduce the real behavior.
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 DNS Propagation Test is a dedicated tool: it queries a set of public resolvers (Google, Cloudflare, Quad9, AdGuard, CleanBrowsing, DNS4EU, NextDNS, Surfshark) in parallel and groups the answers by value and RCODE. You instantly see which resolvers have already picked up your change.
1. Multiple resolvers
Queries the public resolvers in the catalog in a single run from our servers in Europe, with no manual switching.
2. Automatic comparison
Groups identical answers and highlights divergences or resolver-specific errors.
3. Actionable summary
Gives a clear overview: the resolver list, their latencies, and the status of each answer group.
When to use it?
Track how a DNS change reaches the main public resolvers
Spot stale caches and decide on a targeted flush
Share a propagation snapshot in a ticket or post-mortem
Tip: propagation is a dedicated tool. Use DNS Lookup in Simple or iterative Trace mode when you need to focus on a single resolver.
A CAA (Certificate Authority Authorization) record defines which certificate authorities (CAs) are authorized to issue SSL/TLS certificates for a domain. It's a security measure that prevents unauthorized certificate issuance.
A name's policy does not necessarily come from the apex. The lookup follows aliases. If resolution succeeds without returning CAA, it resumes at the parent of the requested name, then at the first ancestor that returns a CAA set, up to and including the TLD. It does not climb the parents of the alias target and never queries the root. A lookup error leaves the result unknown.
The CA refuses to issue. Often, the applicable CAA set contains issue tags, or issuewild for a wildcard, that do not authorize this CA. That is not the only cause: an accounturi or validationmethods parameter can also block issuance, and a CA may refuse while the CAA lookup fails.
Find the applicable CAA set: requested name, aliases, then parents
Query the subdomain itself: a CAA at that name, or a CNAME whose target returns a CAA, replaces the parents' policy
With no set at that level, look for the first ancestor that returns one: it is not always the apex
A name that carries a CNAME cannot carry a CAA. Its policy comes from the target or, if the target returns none, from the parents of the requested name
If you add a CAA to the subdomain, list every CA it needs: it replaces the parent policy instead of adding to it
Each command queries a single name and does not climb to the parents. Check the status first: SERVFAIL, REFUSED or a timeout allow no conclusion. If the status is NOERROR with no CAA line and the answer shows only an alias chain, also query its last target name, without climbing that target's parents. With no CAA set, then query the parent of the requested name, and the next ones up to the TLD. The complete guide to CAA records details this procedure, aliases included.