How to Test DNS HTTPS and SVCB Records Through a Proxy

Modern connection setup may use more than A and AAAA records. DNS HTTPS and SVCB records can advertise alternative endpoints and parameters such as supported application protocols, ports, and address hints. A proxy workflow can therefore appear healthy while the client and proxy path make different discovery decisions.

This guide builds a reproducible test for authorized proxy evaluation. It does not assume every client implements HTTPS or SVCB records, and it does not treat lack of support as a defect unless support is part of the written requirement.

Public source note: RFC Editor, RFC 9460 “Service Binding and Parameter Specification via the DNS,” November 2023. Current work was also reviewed in the IETF Internet-Draft “HTTP Header Fields for Proxying DNS SVCB Information,” July 2026; an Internet-Draft is work in progress, not a standard.

Start with the resolution owner

Before testing, identify which component resolves the origin and which component selects an alternative endpoint:

Do not infer the owner from the product label. Capture it. A command-line flag, browser policy, library version, PAC rule, or container resolver can change the path.

Build an authorized fixture

Use a domain and endpoints you control. Publish a simple HTTPS or SVCB record set with two service-mode choices and a safe fallback. Each endpoint should return the same harmless test object plus a distinct endpoint marker.

Record the complete fixture state:

fixture_revision
owner_name
record_type
ttl
priority
target_name
svc_params
address_records
certificate_names
endpoint_marker
published_at_utc

Keep certificates valid for the original origin. Alternative endpoints do not change the HTTPS origin identity. Avoid production hosts because a failed experiment can disrupt real traffic.

Create a route matrix

Run the same client build through:

1. a direct control;
2. HTTP CONNECT with a domain authority;
3. SOCKS with verified local resolution;
4. SOCKS with verified remote resolution;
5. each required region using the same proxy product and session policy.

Hold URL, method, headers, browser profile, account state, time window, and retry budget constant. The request-header integrity test helps prove that a content difference did not come from a changed request profile.

For every attempt capture:

observed_at_utc
route_type
exit_region
resolver_identity
query_types_observed
https_svcb_answer_digest
answer_ttl
selected_target
selected_port
offered_alpn
negotiated_alpn
connected_ip_hash
certificate_result
http_status
endpoint_marker
fallback_reason
duration_ms

Hash addresses if the raw value is unnecessary. Never store proxy credentials, authentication headers, cookies, tokens, or personal data.

Test four controlled phases

1. Baseline without a service-binding answer

Confirm every route reaches the default authority using ordinary address records. This proves that later failures are tied to discovery behavior rather than basic authentication, routing, or TLS.

2. Publish a compatible HTTPS or SVCB answer

Add one supported alternative. Wait for the documented TTL boundary, then repeat. A supporting client should select the advertised endpoint according to its algorithm; a non-supporting client should continue safely through the default endpoint.

3. Add an unsupported mandatory parameter

In the controlled zone, publish a record whose mandatory parameter is intentionally unsupported by the test client. The record should be ignored rather than partially applied. Verify fallback behavior and preserve the reason.

4. Change priority and expire the old answer

Move the preferred service to the second endpoint. Test before and after TTL expiry. This separates legitimate DNS caching from a stuck resolver or a proxy path that never refreshes. Use the negative DNS cache recovery guide for adjacent failure-recovery checks.

Validate the connection, not only the DNS answer

A correct DNS response does not prove that the resulting connection is correct. Confirm:

• the selected target and port match a usable service-mode record;
• the negotiated ALPN is one the endpoint actually supports;
• TLS validates for the original origin name;
• the endpoint marker matches the selected target;
• fallback does not silently change region or account context;
• redirects and application content remain valid.

If the route negotiates a different protocol, repeat the TLS session-resumption test separately. Do not mix discovery compatibility with connection-reuse performance in one pass/fail score.

Classify results precisely

Use explicit outcomes:

• supported and selected: compatible record used and connection validated;
• supported but fallback used: record understood, alternative failed, documented fallback succeeded;
• safely ignored: client lacks support or record is incompatible, default route succeeds;
• stale selection: old target persists beyond the permitted cache window;
• parameter loss: answer is visible but required target, port, or protocol data is not applied;
• identity failure: alternative connection does not validate for the original origin;
• route mismatch: direct and proxy paths use different resolution owners or policies;
• inconclusive: insufficient DNS, proxy, TLS, or endpoint evidence.

“Different” is not automatically “broken.” A remote resolver can legitimately receive a different regional answer. Compare behavior with the requirement and the endpoint marker.

Common diagnostic mistakes

Looking only at A and AAAA

Address answers cannot show whether the client considered HTTPS or SVCB parameters. Capture query types and selection behavior.

Assuming HTTP CONNECT guarantees remote DNS semantics

The client sends an authority to the proxy, but browser and library behavior around service discovery can differ. Verify the actual owner and final endpoint.

Using a public domain with unknown deployment changes

Without a controlled revision and endpoint marker, regional CDN variation is indistinguishable from proxy incompatibility.

Treating address hints as authoritative addresses

Hints accelerate setup but do not replace the protocol’s resolution and validation rules. Record what the client actually connected to.

Flushing every cache before every test

That hides real TTL behavior. Run both clean-start and warm-cache phases, labeling each one.

Acceptance checklist

• Resolution ownership is documented for every route.
• The fixture uses valid certificates and harmless endpoint markers.
• Direct, CONNECT, local-DNS SOCKS, and remote-DNS SOCKS routes are separated.
• Query types, answer digest, TTL, selected target, port, ALPN, TLS result, and fallback are recorded.
• Compatible records work or fall back according to the requirement.
• Unsupported mandatory parameters are ignored safely.
• Old selections disappear within the permitted cache window.
• Regional differences are explained rather than averaged away.
• Credentials, cookies, tokens, raw user data, and unnecessary IP addresses are redacted.

FAQ

Must every residential proxy support HTTPS and SVCB records?

No. The requirement depends on which component owns DNS and service selection. Test the complete client–resolver–proxy path against your application requirement.

Does a different negotiated ALPN prove the proxy changed the DNS result?

No. Client capabilities, endpoint availability, TLS policy, and fallback can also change protocol negotiation. Preserve evidence from each layer.

Can this test use a third-party production website?

It should not. Use an authorized fixture so record revisions, endpoint markers, certificates, and failure phases are controlled.

Is an Internet-Draft safe to treat as a finished standard?

No. It can change or expire. Use it to track emerging implementation work, while basing normative expectations on published standards and the products’ documented behavior.

Compliance note

Test only domains, resolvers, proxy accounts, endpoints, and regions you are authorized to use. Respect contracts, access controls, privacy requirements, DNS and HTTP rate limits, and provider policies. Do not manipulate third-party DNS, bypass restrictions, or direct experimental traffic toward infrastructure you do not control.