DNS over HTTPS, standardized in RFC 8484, carries DNS messages in HTTPS requests and responses, normally using port 443. Traditional DNS commonly uses unencrypted UDP or TCP on port 53, which allows devices along the network path to observe queried names and potentially interfere with responses. DoH protects the connection to the selected resolver with TLS, provided that the client correctly validates the resolver's certificate and identity.
A DoH client can be a browser, an operating-system resolver, an application, or a local DNS proxy. Standard DoH supports HTTP GET and POST with DNS messages encoded according to the protocol. Persistent HTTPS connections can amortize connection establishment costs, but initial TLS negotiation, network distance to the resolver, and resolver cache behavior still affect latency. Using port 443 does not make DoH ordinary web browsing from an operational perspective; it remains a DNS dependency that needs explicit availability, policy, and monitoring decisions.
In cloud architectures, workloads can use an approved public DoH resolver or an organization-controlled endpoint that preserves private DNS resolution. For example, a hybrid environment can send queries from an on-premises DoH-capable resolver to a compatible Amazon Route 53 Resolver inbound endpoint. The endpoint must be configured for DoH, reachable through the intended network path, and permitted by applicable security controls. Do not assume that a VPC's built-in DNS address automatically accepts DoH simply because Route 53 Resolver supports it on compatible inbound endpoints.
Resolver selection directly affects correctness and confidentiality. A public resolver generally cannot resolve private hosted zones or internal split-horizon records. Sending an internal service name to that resolver can both fail and disclose naming information outside the organization. Configure clients or forwarding proxies so that private namespaces reach the appropriate internal resolver, and ensure browser-specific DoH settings do not bypass enterprise DNS routing.
DoH and DNSSEC address different threats. DoH encrypts and authenticates a transport connection to a resolver; DNSSEC allows validation of signed DNS data through a chain of trust. A resolver can provide DoH without validating DNSSEC, and a DNSSEC-validating resolver can communicate with clients over plaintext DNS. For signed zones, combining DoH with DNSSEC validation protects the client-to-resolver channel while enabling detection of forged or modified DNS data. DNSSEC does not conceal queried names, and unsigned zones do not gain signed-data authenticity merely because DoH is used.
DoH is not end-to-end encryption between a client and every authoritative DNS server. The selected resolver can see the queries it processes, and its upstream communications may still use plaintext DNS. Network observers may also see the resolver's IP address and traffic timing. Evaluate resolver logging, retention, access controls, and upstream behavior rather than treating encryption as anonymity.
Operationally, unmanaged DoH can bypass centralized DNS filtering and query logging. Blocking port 53 alone does not prevent applications from using external DoH over HTTPS. Use managed client settings, approved resolver destinations, and appropriate egress controls together. Test certificate validation, resolver bootstrap, private-name resolution, endpoint failure, and fallback behavior; silent fallback to plaintext DNS can defeat a confidentiality requirement. For exam scenarios, distinguish encrypted DNS transport, DNS data authenticity, and centralized DNS governance before selecting a solution.