General interview: explaining DNS SVCB and HTTPS records

Prompt and scope

A team wants DNS to publish service-binding data so clients can discover alternate hosts, ports, protocols, and TLS hints, preferring HTTP/3 when available. Explain SVCB and HTTPS records, priority, AliasMode, caching, and security boundaries. RFC 9460 defines SVCB and its HTTP variant, but DNS hints do not replace certificate validation, HTTP semantics, or authorization.

What the interviewer evaluates

• Knowing that HTTPS is the HTTP-specific SVCB variant.
• Distinguishing AliasMode and ServiceMode and their priority rules.
• Understanding that alpn, port, and address hints are connection hints.
• Explaining DNSSEC, DoH/DoT, and ordinary DNS trust boundaries.
• Designing TTLs, fallback, monitoring, and revocation.

Clarifications to ask first

Confirm client and resolver versions, whether the goal is aliasing or protocol selection, DNSSEC and encrypted-DNS deployment, HTTP/3 fallback requirements, and certificate and availability goals. If unspecified, assume some resolvers do not understand HTTPS records.

Thirty-second answer framework

Treat an HTTPS record as HTTP service discovery. Priority 0 AliasMode points to another name and requires another lookup; nonzero ServiceMode records describe services. alpn and port help select a connection but do not grant authorization or replace TLS validation. On lookup failure or unsupported protocols, fall back to A/AAAA, the default port, and a supported protocol, with TTLs and monitoring controlling rollout.

Step-by-step deep dive

1. Distinguish the record types

SVCB is a generic service-binding record; HTTPS is its HTTP-oriented variant. Both carry priority, target name, and key-value parameters. They do not create a proxy layer; HTTP still follows RFC 9110 semantics.

2. Explain AliasMode and ServiceMode

AliasMode uses priority 0 to alias the current name to a target name, so the client must query the target. ServiceMode uses nonzero priority to describe a service. Clients try lower priorities first but skip unsupported candidates.

3. Read hints without over-trusting them

alpn can advertise h2 or h3, port can advertise a non-default port, and address hints can reduce extra lookups. Hints can be stale or blocked, so clients still resolve A/AAAA, complete QUIC/TLS, and confirm the negotiated protocol.

4. Design fallback

Within an error budget, try the lowest-priority usable service, then try the next candidate after a connection error or timeout. If the HTTPS lookup fails, use traditional A/AAAA and the default HTTPS port. Unknown keys must not become authorization policy.

5. Manage caching and changes

TTL controls how long recursive resolvers and clients retain hints. Make the new host or port ready before a gradual TTL and record change. Removing an authoritative record does not immediately remove cached answers; urgent incidents need server-side blocking or certificate controls.

6. Explain DNS and TLS security

DNSSEC authenticates record integrity; DoH/DoT protects query transport. Neither replaces TLS identity verification. RFC 9460 limits trust in DNS hints to no more than a cleartext HTTP 307 signal. Clients still validate the certificate, SNI, ALPN, and TLS version, and cannot authorize an uncovered cross-origin target.

7. Validate and roll back

Test old clients, AliasMode chains, multiple priorities, unknown keys, stale caches, DNSSEC failure, unavailable h3, certificate mismatch, and IPv4/IPv6-only networks. Monitor handshake time, protocol success, fallbacks, errors, and privacy signals. Roll back by restoring old records and waiting for TTL; use server-side blocking for identity emergencies.

High-quality sample answer

I would position HTTPS records as service-discovery hints. AliasMode makes the client query the target name, while ServiceMode lists candidates by priority. alpn, port, and address hints assist selection but grant no access. If h3 fails, fall back within a budget to h2 or the traditional A/AAAA path, and keep the old path available when the DNS query fails.

DNSSEC protects record integrity and DoH/DoT protects query transport, but certificate, SNI, ALPN, and TLS-version checks remain independent. Use TTL-aware rollout and monitor protocol success, fallbacks, certificate errors, and cache behavior. Test old resolvers, unknown keys, AliasMode, DNSSEC failure, and IPv6-only networks. For an emergency identity problem, server-side blocking and certificate controls are required; waiting for DNS cache expiry is insufficient.

Common mistakes

• Treating HTTPS as a CNAME or redirect replacement.
• Confusing AliasMode, ServiceMode, and priority.
• Treating address hints as authoritative and skipping A/AAAA.
• Assuming alpn=h3 bypasses QUIC/TLS negotiation.
• Calling ordinary DNS trustworthy without integrity protection.
• Ignoring cached answers after deleting an authoritative record.
• Pointing to a target not covered by a verifiable certificate.

Follow-up questions and responses

Follow-up 1: Why does AliasMode require another lookup?

It expresses only a name-level alias and carries no final service parameters, so the client must query the target for ServiceMode data.

Follow-up 2: Can HTTPS records bypass a certificate for a CDN host?

No. The client still validates the certificate and TLS configuration for the connection name; the CDN must present a verifiable certificate.

Follow-up 3: How do DNSSEC and DoH/DoT differ?

DNSSEC validates record origin and integrity. DoH/DoT protects query transport privacy. Neither substitutes for TLS identity validation.

Follow-up 4: How do you revoke a leaked target?

Block it or revoke its certificate server-side first, then update records and reduce TTL; cached answers will not disappear immediately.