The recommendations in this section go above and beyond what we have considered in the context of KINDNS.

For *all* type of operators

  1. Bonus Practice: Enabling stateful packet filtering / reflexive access-lists in front of a DNS server SHOULD be avoided.

Rationale: Very active DNS servers can easily overwhelm stateful packet filters and load balancers.

For Shared Private (ISP) DNS Operators

  1. Bonus Practice (Privacy consideration): DoT (DNS-over-TLS) or DoH (DNS-over-HTTPS) SHOULD be enabled. 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, or between a forwarding and recursive resolver.

Rationale: In the context of shared private resolvers, 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. Additionally, a DoT and/or DoH service should be offered to local clients and resolvers. 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 (if using unencrypted DNS) 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.

For operators offering customer-facing services

  1. Bonus Practice: Customers/registrants SHOULD be strongly encouraged to enable two-factor authentication on their accounts.

Rationale: This reduces the likelihood of their accounts being compromised.