Skip to main content

SVCB Record Lookup (Service Binding)

Describe your services and their connection parameters

Configure service discovery via DNS. Verify that your SVCB records correctly announce protocols and connection parameters.

In iterative trace mode, the resolver is ignored.
Query multiple public resolvers to compare answers.

Service description

Announce how to connect to a service: supported protocols, port, and fallback addresses.

Multi-resolver

Compare responses from Google, Cloudflare, and Quad9 to detect propagation issues.

Alias mode

Use priority 0 to create an alias to a target without using a CNAME.

Advanced parameters

Publish alpn, port, ipv4hint, ipv6hint, and ech to guide clients to the right configuration.

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. 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.

What is an SVCB record?

An SVCB (Service Binding) record describes how to reach a service. It can designate a target and publish parameters like protocol, port, and fallback addresses.

SVCB record structure:

FieldDescriptionExample
Priority0 = alias, 1+ = service1
TargetService hostnamemail.provider.com.
alpnSupported protocolsimap
portService port993
ipv4hintIndicative IPv4 addresses203.0.113.10

Operating modes

Service mode (priority > 0)

Announces connection parameters:

_imap._tcp.captaindns.com.  3600  IN  SVCB  1 mail.provider.com. alpn=imap port=993

Alias mode (priority = 0)

Redirects to another target without parameters:

apex.captaindns.com.  3600  IN  SVCB  0 cdn.provider.com.

Common parameters

ParameterDescriptionExample
alpnSupported protocolsimap, h2, h3
portService port993, 443
ipv4hintIndicative IPv4 addresses203.0.113.10
ipv6hintIndicative IPv6 addresses2001:db8::1
echECH configuration(base64 encoded)

Use cases

IMAP service

_imap._tcp.captaindns.com.  3600  IN  SVCB  1 mail.provider.com. alpn=imap port=993

Apex alias

captaindns.com.  3600  IN  SVCB  0 cdn.provider.com.

Application service

_api._tcp.captaindns.com.  300  IN  SVCB  1 . alpn=h2 port=8443

Important rules

Compatibility

RuleExplanation
Keep A/AAAALegacy clients don't use SVCB
Valid targetTarget must have A/AAAA records
Consistent priority0 = alias only, > 0 = service

Best practices

PracticeWhy
Prefer HTTPS for webDedicated variant with adapted semantics
Short TTL initiallyMakes corrections easier
Document parametersTraceability of modifications

Command line verification

Linux/Mac

dig SVCB _imap._tcp.captaindns.com

Windows

nslookup -type=svcb _imap._tcp.captaindns.com

ToolPurpose
HTTPS Record LookupCheck web records
A Record LookupCheck IPv4 addresses
DNS Propagation CheckCheck worldwide propagation

Useful resources