Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. MUST: Enable DNSSEC validation.
  2. MUST: Enable QNAME minimization to minimize leakage of domain names.MAY
  3. SHOULD: Enable DoT (DNS-over-TLS)

    . DoT

    , or DoH (DNS-over-HTTPS). Deploying either is the easiest way to protect against eavesdropping and manipulation of DNS queries and man-in-the-middle attacks by encrypting DNS queries between stub and recursive resolvers

    . Footnote

    , or between a forwarding and recursive resolver.

    In the context of private networks, it is recommended that DoT or DoH be enabled between the resolver on the local network(s), and an external, trusted DoT/DoH enabled forwarding resolver. This ensures that DNS queries being forwarded from local clients are encrypted between the local resolver, and the external forwarder. While DoT and DoH may reduce the visibility that local administrators have into the queries being forwarded by the local recursive resolver to an upstream DoT/DoH service, it will still be possible to monitor queries between clients and the local DNS resolver, either using passive DNS analysis or query logging.

    Finally, DoT and DoH do not guarantee end-to-end privacy, only protection from third party eavesdropping between hops that use DoT/DoH: the resolver that queries are being forwarded to should also use DoT/DoH when performing resolution

    It is worth noting that, while DoH (DNS-over-HTTPS) improves end-user privacy, in the same way that DoT does, it is somewhat more complicated and its benefits to network operators are still being debated

    .

Note: Enabling DoT does reduce the visibility that local administrators have into the queries being forwarded by the local recursive resolver to an upstream DoT service. However, it will still be possible to analyze queries between clients and the local DNS resolver before they are forwarded to a DoT upstream service, or by logging queries.display-footnotes