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

An SVCB record describes how to connect to a service. It can designate another name and provide parameters like protocol, fallback address, and port. For a website, we often publish an HTTPS record which is the dedicated variant of SVCB.
An SVCB 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 SVCB DNS record

NameTypePriorityTargetParametersTTL in seconds
_imap._tcp.example.comSVCB1mail.example.net.alpn=imap port=993 ipv4hint=203.0.113.103600

In this example, the name targets the imap service over tcp. The target is another hostname. The parameters indicate the protocol, 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
apex.example.comSVCB0cdn.example.net.(no parameters)3600

This mode serves as a bridge. It avoids using a CNAME where it's not desired.

Common parameters

Parameter nameRole
alpnAnnounces supported 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 don't 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
For the web, favor an HTTPS record. It follows the same rules as SVCB and adds fields useful to browsers.

Where to use an SVCB record

On a dedicated service name like _imap._tcp or _smtp._tcp when the protocol provides for it.
At the apex in alias mode if you need to target another name while avoiding a CNAME.
SVCB can coexist with A and AAAA. Clients that don't understand SVCB use classic addresses.

To avoid
Chaining targets without reason. Get to the point.
Publishing parameters inconsistent with the actual service.
Forgetting A or AAAA on the target when the client needs to reach it.

Online verification

An online DNS lookup allows entering a domain 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=svcb
example.com
Specific resolver
nslookup
set q=svcb
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 SVCB example.com
Specific resolver
dig SVCB example.com @1.1.1.1

Quick reading of responses

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

Simple setup

  1. Define the need. Alias to a target or parameter publication.
  2. Reduce the TTL to 300 or even 60 seconds a few hours before setup.
  3. Publish the SVCB with the chosen priority 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 change. This trace facilitates checks.

Common cases

Application service

Publish an SVCB on _api._tcp to announce alpn and port. The application knows how to connect.

Site behind a provider

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

Transition to HTTP version three

On a website, publish a dedicated HTTPS record with alpn h3. Add ech if the service offers it.

Quick troubleshooting

  1. If clients ignore SVCB, verify that A and AAAA exist on the target.
  2. If the wrong protocol is chosen, verify alpn.
  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 SVCB record describes a service and can serve as a controlled alias. Parameters guide the client without replacing A and AAAA. 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 service without incident.