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

A CAA record defines which certificate authorities can issue certificates for a domain. It serves as a safeguard. An unlisted authority must refuse issuance. CAA works through inheritance. Without a rule on a subdomain, the apex rule applies.
A CAA record contains a name, a type, a flag, a tag, a value, and a TTL. The TTL indicates how long the response remains cached in the local resolver.

Example CAA DNS record

NameTypeFlagTagValueTTL in seconds
@CAA0issue"letsencrypt.org"3600

In this example, the zone authorizes Let's Encrypt to issue certificates for the domain. A flag of zero is suitable for common uses. A TTL of 3600 corresponds to one hour.

Common examples

NameTypeFlagTagValueRole
@CAA0issue"digicert.com"Authorize an authority
@CAA0issuewild"letsencrypt.org"Authorize wildcard certificates
@CAA0iodef"mailto:security@example.com"Receive incident reports
@CAA0issue";"Forbid all issuance

The issue tag authorizes the issuance of standard certificates. The issuewild tag targets wildcard certificates. The iodef tag indicates where to send a report in case of unauthorized attempts.

Essential rules

Publish the CAA at the apex to cover the entire domain. Define exceptions at the subdomain level if needed.
The target of an MX or other service does not affect the CAA. The issuance decision is made on the name of the targeted certificate.
The critical flag exists for advanced uses. A value of one hundred twenty-eight requires the authority to understand the tag or it refuses.

TTL explained clearly

A short TTL makes an adjustment visible faster. Useful during an authority change.
A medium or long TTL reduces queries to authoritative servers. Suitable for a stable policy.
Reduce the TTL a few hours before switching, then increase it after validation.

Good to know
Inheritance is key. A rule set on shop.example.com replaces that of the apex for this subdomain. Without a local rule, the parent rule applies.

Where to use a CAA record

At the apex to define the general policy. On a subdomain to grant a controlled exception like a service managed by a third party. Then test actual issuance with the targeted authority.

To avoid
Forgetting the iodef which facilitates reporting.
Authorizing too many authorities which complicates control.
Leaving an old CAA active after a provider change.

Online verification

An online DNS lookup allows entering a domain name. The result displays the CAA tags and 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=caa
example.com
Specific resolver
nslookup
set q=caa
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 CAA example.com
Specific resolver
dig CAA example.com @1.1.1.1

Quick reading of responses

The presence of an issue or issuewild tag indicates the authorized authority. A value with semicolon alone forbids issuance.
A high remaining TTL may explain a lag after a change.
Total absence of CAA means no restriction. Authorities can issue according to their usual controls.

Simple migration procedure

  1. List the chosen authority and any wildcard need.
  2. Publish CAA at the apex with a reduced TTL.
  3. Add iodef to a functional contact address.
  4. Test issuance of a test certificate with the authority.
  5. Increase the TTL when everything is validated.

Practical tip
Keep a record with the list of published CAAs. Note the date, TTL, and reason for change. Keep proof of successful issuance tests.

Common cases

Limit to a single provider

Publish a single issue tag. Verify that all services go through this authority.

Authorize wildcard

Add issuewild for the same authority. Keep issue for non-wildcard certificates.

Receive alerts

Add iodef with a dedicated email or https reception address.

Quick troubleshooting

  1. If issuance fails, verify that the issue or issuewild tag properly mentions the targeted authority.
  2. If the authority requests a correction, verify inheritance up to the apex.
  3. If the change is not taken into account, wait for TTL expiration and purge the local resolver cache if possible.

In summary, a CAA record defines who can issue certificates for a domain. The issue, issuewild, and iodef tags cover most needs. Inheritance guides the decision. An adjusted TTL facilitates transition. Verification goes through an online tool then through nslookup and dig.
With these markers, management remains clear. Changes proceed without stress. Certificates are issued according to your policy.