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

An HTTPS record describes how to connect to a website. It's the dedicated variant of SVCB for the web. It can designate a target and announce parameters like protocols, port, and ECH data. Browsers use it to choose the best connection.
An HTTPS record contains a name, a type, a priority, a target, parameters, and a TTL. The TTL indicates how long the response remains cached in the local resolver.

Example HTTPS DNS record

NameTypePriorityTargetParametersTTL in seconds
test.captaindns.comHTTPS1cdn.example.net.alpn=h3,h2 port=443 ipv4hint=203.0.113.103600

In this example, the name targets the website. The target is another hostname. The parameters indicate protocols, the entry port, and a fallback address. A TTL of 3600 corresponds to one hour.

Example in alias mode

A priority of zero activates alias mode. The name then behaves like an alias to the target.

NameTypePriorityTargetParametersTTL in seconds
captaindns.comHTTPS0cdn.example.net.(no parameters)3600

This mode is used to target another zone while remaining compliant at the apex where a CNAME is not desired.

Common parameters

Parameter nameRole
alpnAnnounces protocols like h2 or h3
portIndicates the service entry port
ipv4hintProvides indicative v4 addresses
ipv6hintProvides indicative v6 addresses
echPublishes ECH data to encrypt ClientHello

These parameters guide the client. They do not replace A and AAAA records which remain the source of addresses.

TTL explained clearly

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

Good to know
Clients that don't understand HTTPS records use A and AAAA. Publishing HTTPS doesn't remove the need to keep these addresses.

Where to use an HTTPS record

On www to announce h3 or a distribution target. At the apex in alias mode to target a name while remaining compliant. On an application subdomain if the web service resides there.
HTTPS can coexist with A and AAAA. Browsers choose IPv6 when possible and fall back to IPv4 if needed.

To avoid
Publishing HTTPS without A or AAAA on the target.
Chaining multiple targets without reason.
Declaring parameters that don't match the actual service.

Online verification

An online DNS lookup allows entering a name. You can see the priority, target, parameters, and TTL as perceived 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=https
example.com
Specific resolver
nslookup
set q=https
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 HTTPS example.com
Specific resolver
dig HTTPS example.com @1.1.1.1

Quick reading of responses

A priority of zero indicates an alias. A value greater than zero describes a service with parameters.
The presence of alpn guides the h3 or h2 choice. The ipv4hint and ipv6hint fields are only hints.
A high remaining TTL may explain a lag after a change.

Simple setup

  1. Choose the objective. Alias at the apex or parameter publication on www.
  2. Reduce the TTL to 300 or even 60 seconds before setup.
  3. Publish the HTTPS record with the chosen priority, target, and parameters.
  4. Verify with nslookup or dig command from multiple networks.
  5. Increase the TTL when everything is stable.

Practical tip
Document the priority, target, and each parameter. Keep the date and reason for the change. This trace facilitates checks.

Common cases

Accelerate HTTP version three adoption

Publish alpn h3 on www. Keep h2 for compatibility.

Site behind a provider

Use alias mode to target the name provided by the service. Keep A and AAAA on the target.

Enable ECH

Publish ech when the platform offers it. Verify browser-side support.

Quick troubleshooting

  1. If the site doesn't benefit from h3, check the presence of alpn and server-side support.
  2. If clients ignore HTTPS, check A and AAAA on the target.
  3. If a loop appears, verify that the target doesn't redirect back to the origin name.
  4. If the response remains old despite the update, wait for TTL expiration and purge the local resolver cache if possible.

In summary, an HTTPS record announces the optimal way to connect to a website. It can serve as a controlled alias and publish useful parameters like alpn, port, and ech. 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. Users access the site without incident.