You want to see whether a resolver hostname publishes HTTPS or SVCB records that look relevant to designated resolver discovery.
DDR / Designated Resolver Check
Inspect HTTPS and SVCB records that may be used for designated resolver discovery.
Use DDR / Designated Resolver Check to inspect the discovery records published for a resolver hostname, review the returned HTTPS and SVCB values, and decide what encrypted resolver check to run next.
Check the resolver hostname first, then move to the matching DoH, DoT, or DoQ validation.
Resolver discovery result
resolver.example.net
READY
Type Value TTL
No HTTPS or SVCB discovery records were returned for this resolver hostname.
What this DDR tool does
DDR / Designated Resolver Check queries HTTPS and SVCB records for a resolver hostname and shows the discovery values currently visible from a public recursive resolver.
Use it to confirm whether a resolver publishes structured discovery records and to review what those records advertise before you move to a protocol-specific encrypted resolver test.
It does not prove that a client will actually adopt the resolver automatically. It only inspects the published DNS discovery layer.
When to use this tool
A client is expected to discover encrypted resolvers automatically and you need to inspect the published DDR-related DNS records first.
You are comparing resolver discovery behavior between providers and want a quick look at the advertised DDR signals.
A resolver hostname looks correct, but automatic encrypted resolver discovery is not happening as expected.
You need a browser-safe first pass before moving to packet capture, CLI tools, or client-specific debugging.
You want to verify whether the resolver hostname publishes no discovery records at all before chasing a client bug.
How to use DDR / Designated Resolver Check
- Enter the resolver hostname you want to inspect.
- Run the check to query HTTPS and SVCB records for that hostname.
- Review the returned records, TTL values, and DNS response status.
- Compare the discovery values with the encrypted resolver hostnames you expected.
- If the records are missing or unexpected, continue to the related DoH, DoT, DoQ, or DNS checks.
How to interpret DDR results
HTTPS or SVCB records found
Likely meaning: The resolver hostname returned HTTPS and/or SVCB records that may be relevant to designated resolver discovery.
Common causes: This usually means the resolver publishes structured service discovery data that a supporting client could use.
Next action: Review the returned values closely, then compare them with the DoH, DoT, or DoQ hostnames you expect.
No DDR records found
Likely meaning: The hostname returned no HTTPS or SVCB records for this query.
Common causes: The resolver may not publish DDR-related records, the hostname may be wrong, or discovery may be implemented differently.
Next action: Verify the exact resolver hostname, then compare with provider documentation and other resolver checks.
Unexpected service parameters
Likely meaning: HTTPS or SVCB records exist, but the returned values do not match the resolver setup you expected.
Common causes: Old discovery records, wrong hostname, stale DNS, or provider-side misconfiguration are common causes.
Next action: Compare the returned values with the intended encrypted resolver configuration.
SERVFAIL or NXDOMAIN
Likely meaning: The recursive resolver could not return usable discovery records for the hostname.
Common causes: The hostname may be wrong, unpublished, or affected by delegation or DNSSEC problems.
Next action: Run DNS Lookup, NS Lookup, and DNSSEC Check next.
Browser-safe limitation
Likely meaning: This page only inspects published DNS discovery records. It does not prove that a client will adopt the resolver automatically.
Common causes: Actual DDR behavior depends on client support, network provisioning, and policy beyond the raw DNS records alone.
Next action: Use this page to inspect the published DNS layer, then move to client or network-level validation.
Common issues this tool helps uncover
The resolver hostname publishes no HTTPS or SVCB records
Discovery records exist, but they reference unexpected encrypted resolver endpoints
The wrong resolver hostname is being checked
Clients do not use DDR even though records exist because the client or network path does not support it
Old or partial DDR-related records remain after a resolver migration
DNSSEC or delegation issues prevent the discovery records from being returned cleanly
Next steps after DDR / Designated Resolver Check
Check DoH endpoint
If DDR-related records point to a DoH resolver, validate that endpoint directly.
Check DoT hostname
If DDR points to a DoT resolver, confirm the DoT hostname resolves as expected.
Check DoQ hostname
If DDR points to a DoQ resolver, review the published hostname before deeper QUIC testing.
Inspect broader DNS
If the discovery records look wrong or missing, compare with general DNS and DNSSEC checks.
Related tools
DoH Endpoint Check
Test a DNS-over-HTTPS endpoint with a live JSON query and inspect the response.
DoT Endpoint Check
Review a DNS-over-TLS endpoint target and browser-safe preflight signals before deeper validation.
DoQ Endpoint Check
Review a DNS-over-QUIC resolver hostname with browser-safe preflight signals before deeper validation.
DNS Lookup
Query A, AAAA, CNAME, TXT, and other DNS records for a domain.
DNSSEC Check
Validate whether a domain has DNSSEC configured correctly.
DDR / Designated Resolver Check FAQ
What does DDR / Designated Resolver Check inspect?
It inspects HTTPS and SVCB DNS records on a resolver hostname so you can review whether designated resolver discovery signals are being published.
Does this prove that a client will use the discovered resolver?
No. It only checks the published DNS discovery records. Actual DDR adoption depends on client support, network configuration, and policy.
What hostname should I enter?
Enter the resolver hostname you expect to publish designated resolver discovery records for.
What should I do if no records are returned?
Verify the resolver hostname first, then compare with provider documentation and run the related DoH, DoT, or DoQ checks if needed.
Why would records exist but discovery still fail?
Clients may not support DDR, the published values may be incomplete, or other network and policy signals may prevent automatic adoption.