Question and when it applies
This question appears in networking, security, backend, SRE, and sales-engineering interviews. A strong answer treats DNS over HTTPS (DoH) as a protocol boundary, not as “DNS with a certificate.” DoH carries a DNS query and response inside an HTTPS exchange. The transport hides the query from a normal on-path observer between the client and the DoH resolver, but the resolver still receives it and can log or filter it. The choice depends on who must see DNS, what policy controls are required, and whether the client can reach the resolver reliably.
What the interviewer is evaluating
- Whether you can separate DNS message semantics from HTTP status and transport behavior.
- Whether you state the privacy boundary: encryption to the chosen resolver is not anonymity.
- Whether you understand GET versus POST, content type, cache behavior, and bootstrap.
- Whether you compare DoH, DoT, and ordinary DNS by deployment owner, observability, latency, and policy.
- Whether you define fallback and tests instead of claiming that encryption automatically improves every outcome.
Questions to clarify first
Ask who controls clients and resolvers, whether a corporate filtering or audit policy must remain enforceable, whether the network blocks outbound HTTPS or UDP/TCP DNS, and whether the goal is confidentiality from the local network, application-level API access, or resistance to tampering. Clarify whether browsers, operating-system resolvers, or a managed agent will issue queries. Also ask about latency budget, captive portals, split-horizon names, DNSSEC validation, logging retention, and acceptable fallback when the selected resolver is unreachable. These answers can favor an enterprise-managed resolver, an application DoH client, DoT, or ordinary DNS.
A 30-second answer framework
DoH maps each DNS query-response pair to an HTTPS request and response, normally using the DNS wire format with the application/dns-message media type. It encrypts the client-to-resolver hop and can traverse networks that permit HTTPS, but the resolver still sees the query and policy may need an approved endpoint. GET can be cache-friendly; POST avoids putting the encoded query in the URL and is preferable for sensitive requests. I would choose DoH for an explicit privacy or API requirement, compare it with DoT when a managed resolver and clear transport separation matter, and define bootstrap, caching, split-DNS behavior, fallback, telemetry minimization, and tests before rollout.
Step-by-step deep dive
1. Map the protocol layers
The DNS question remains a DNS message. RFC 8484 maps one query-response pair to one HTTP exchange and defines application/dns-message for the binary representation. HTTPS supplies TLS confidentiality and integrity for the connection, while HTTP supplies methods, status codes, connection reuse, and cache controls. A DNS NXDOMAIN or SERVFAIL is still a DNS response code; it can arrive inside an HTTP 2xx response. An HTTP 4xx or 5xx means the HTTP exchange failed and does not contain the original DNS answer, so the client must apply HTTP failure handling separately.
2. Choose GET, POST, and caching deliberately
RFC 8484 requires a DoH server to support both GET and POST for the RFC media type. GET places a Base64URL-encoded DNS message in the dns query parameter, which can improve ordinary HTTP cache reuse but also makes the query visible to URL logs, intermediaries, and browser history unless those surfaces are controlled. POST carries the binary message in the body with the content type. For sensitive names, prefer POST or a carefully governed GET path, minimize headers, and ensure caches cannot invent freshness that conflicts with DNS TTL policy. Google exposes an RFC 8484 endpoint and a separate JSON endpoint; they are different API contracts.
3. Define privacy and policy boundaries
DoH prevents a local observer from reading plaintext DNS packets on the protected hop, but the resolver can still see the query, client metadata, timing, and chosen policy context. HTTPS does not validate the DNS answer itself; the resolver’s DNSSEC behavior and the client’s trust model remain relevant. A managed enterprise may need an approved resolver, category filtering, split-horizon zones, retention controls, and audit evidence. Allowing every application to select an arbitrary public resolver can bypass those controls, even if the traffic is encrypted.
4. Handle bootstrap, failures, and fallback
The client must discover the DoH server’s address before it can resolve that server through the same service. Bootstrap can use configured IPs, a trusted resolver, or another provisioning channel; each path needs certificate validation and rotation. Treat HTTP errors, DNS response errors, timeout, captive portal interception, and policy denial as distinct outcomes. A resolver outage may fall back to an approved transport, but silent fallback to an untrusted resolver can violate privacy or enterprise policy. Record which resolver and transport answered without retaining full query content by default.
5. Compare deployment choices and verify them
Traditional DNS is simple and visible to the network operator, but plaintext transport exposes queries on the path. DoT encrypts DNS in a dedicated TLS service and is often straightforward for an operating-system resolver. DoH blends DNS into HTTPS and can use existing HTTP infrastructure, browser APIs, and port 443 reachability, at the cost of more HTTP-layer policy and observability complexity. Verify the choice with packet captures from a controlled test, resolver-side DNS and HTTP status logs, cache hit and TTL behavior, split-DNS cases, DNSSEC failures, captive portals, resolver outage, certificate rotation, and fallback policy. Measure lookup p50/p95/p99, failure classes, and query leakage rather than only average latency.
Example of a strong answer
DoH is a protocol that places a DNS query and response inside an HTTPS exchange. The DNS message keeps its normal meaning; HTTPS protects the client-to-selected-resolver hop, and HTTP supplies methods, status codes, connection reuse, and cache behavior. A DNS NXDOMAIN can therefore be carried in an HTTP 2xx response, while an HTTP 5xx is a transport or service failure without a DNS answer. I would use DoH when I need application-level access or confidentiality from a local network and can name an approved resolver. I would prefer POST for sensitive names, minimize headers, and keep resolver policy, DNSSEC handling, split-horizon zones, and retention explicit. Bootstrap must happen through configured or trusted resolution, and fallback must stay within the approved policy. Before rollout I would test cache and TTL semantics, URL logging exposure for GET, captive portals, certificate rotation, resolver outage, DNSSEC errors, and whether packets or logs reveal queries outside the intended resolver.
Common mistakes
- Saying “HTTPS makes DNS anonymous” → the selected resolver still sees the query and metadata → state the exact protected hop and resolver trust boundary.
- Treating DNS
NXDOMAINas an HTTP error → DNS response codes can be inside HTTP 2xx → parse HTTP and DNS status layers separately. - Choosing GET for secrets without discussing URL logs → the encoded query can enter history or intermediary logs → use POST or a controlled cache and logging policy.
- Claiming DoH always beats DoT → deployment owner, policy, reachability, and observability differ → compare the concrete environment first.
- Bootstrapping the DoH hostname through the same unresolved resolver → the client has a circular dependency → provision an address or trusted bootstrap path.
- Falling back to any public resolver after timeout → confidentiality and enterprise filtering may be bypassed → restrict fallback to approved transports and endpoints.
- Measuring only average latency → outages, cache misses, and leakage remain hidden → segment p95/p99, failure classes, TTL behavior, and resolver identity.
Follow-up questions and answers
Does DoH validate that the DNS answer is authentic?
No. TLS authenticates the HTTPS server selected by the client. DNS answer authenticity depends on the resolver’s validation behavior and the client’s trust in that resolver; DNSSEC and HTTPS are separate concerns. A design should record whether validation is required and how a validation failure is surfaced.
Why can an HTTP 200 contain a failed DNS lookup?
The HTTP exchange succeeded and transported a valid DNS message. The DNS message may carry NXDOMAIN, SERVFAIL, or another DNS response code. The client must parse both layers and avoid retrying a valid DNS negative answer as if the HTTP request failed.
When is DoT a better choice?
DoT is a strong fit when an operating system or enterprise resolver controls the transport, wants a dedicated DNS port and straightforward network policy, and does not need browser-facing HTTP APIs. DoH is preferable when existing HTTPS reachability or application APIs are the requirement. The decision follows ownership and policy, not a blanket “encrypted is better” rule.
What should happen when the DoH resolver is unreachable on a captive portal?
Detect the portal or repeated TLS/HTTP failure, stop retry amplification, and follow the configured policy: use an approved fallback, pause resolution with a user-visible recovery path, or temporarily use network-provided DNS only when policy permits. Test this before rollout because a blind fallback can leak every query.