Skip to main content

运营考虑

Section 5.1 describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect that client's view of the DNS. This is no different than the security implications of HTTP caching for other protocols that use HTTP.

In the absence of DNSSEC information, a DoH server can give a client invalid data in response to a DNS query. Section 3 disallows the use of DoH DNS responses that do not originate from configured servers. This prohibition does not guarantee protection against invalid data, but it does reduce the risk.

  1. Operational Considerations

Local policy considerations and similar factors mean different DNS servers may provide different results to the same query, for instance, in split DNS configurations [RFC6950]. It logically follows that the server that is queried can influence the end result. Therefore, a client's choice of DNS server may affect the responses it gets to its queries. For example, in the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all.

The HTTPS channel used by this specification establishes secure two- party communication between the DoH client and the DoH server. Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS.

Some HTTPS client implementations perform real time third-party checks of the revocation status of the certificates being used by TLS. If this check is done as part of the DoH server connection procedure and the check itself requires DNS resolution to connect to the third party, a deadlock can occur. The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers or Authority Information Access (AIA) for Certificate Revocation List (CRL) fetching (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen. To mitigate the possibility of deadlock, the authentication given DoH servers SHOULD NOT rely on DNS-based references to external resources in the TLS handshake. For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using Section 4.4.2.1 of [RFC8446] for TLS version 1.3. AIA deadlocks can be avoided by providing intermediate certificates that might otherwise be obtained through additional requests. Note that these deadlocks also need to be considered for servers that a DoH server might redirect to.

A DoH client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be originally determined from that same server, a DoH client cannot use its DoH