安全考虑

caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation.



The DoH protocol design allows applications to fully leverage the HTTP ecosystem, including features that are not enumerated here. Utilizing the full set of HTTP features enables DoH to be more than an HTTP tunnel, but it is at the cost of opening up implementations to the full set of privacy considerations of HTTP.

Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations are advised to expose the minimal set of data needed to achieve the desired feature set.

Determining whether or not a DoH implementation requires HTTP cookie [RFC6265] support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP. HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case.

9. Security Considerations

Running DNS over HTTPS relies on the security of the underlying HTTP transport. This mitigates classic amplification attacks for UDP- based DNS. Implementations utilizing HTTP/2 benefit from the TLS profile defined in Section 9.2 of [RFC7540].

Session-level encryption has well-known weaknesses with respect to traffic analysis, which might be particularly acute when dealing with DNS queries. HTTP/2 provides further advice about the use of compression (see Section 10.6 of [RFC7540]) and padding (see Section 10.7 of [RFC7540]). DoH servers can also add DNS padding [RFC7830] if the DoH client requests it in the DNS query. An experimental effort to offer guidance on choosing the padding length can be found in [RFC8467].

The HTTPS connection provides transport security for the interaction between the DoH server and client, but it does not provide the response integrity of DNS data provided by DNSSEC. DNSSEC and DoH are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other. It is the choice of a client to either perform full DNSSEC validation of answers or to trust the DoH server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not. As noted in Section 4.2, different response media types will provide more or less information from a DNS response, so this choice may be affected by the response media type.