A recursive resolver usually does not need to disclose a user’s complete original query name to every authoritative server along the delegation path. QNAME minimisation reduces that exposure, but it should be deployed as one privacy control with compatibility monitoring—not described as private DNS by itself.
\nIETF RFC 9156 specifies DNS Query Name Minimisation. Instead of always sending the full original query name and type to each upstream server, a recursive resolver asks for only the portion needed to discover the next delegation. The resolver progressively learns the path and sends the full name to the authority that ultimately needs it.
\nThe standard updates earlier guidance and includes behavior intended to work with the deployed DNS. It discusses resolver algorithms, caching, handling unexpected replies, and implementation considerations. The privacy benefit is reduced disclosure of the complete name to unnecessary DNS servers; the RFC does not encrypt DNS packets or hide queries from the recursive resolver, the final authoritative service, or network observers who can infer information from unencrypted traffic.
\nQNAME minimisation is a resolver behavior, not an endpoint or authoritative-server guarantee. Compatibility can be affected by nonconforming DNS servers, unusual delegations, and product-specific fallback choices. DNS-over-TLS, DNS-over-HTTPS, logging minimisation, access controls, and retention policies address different exposure points. Enabling several controls does not establish anonymity.
\nDocument the privacy objective and the resolvers in scope. Check the exact product release’s implementation notes and default. In a representative test resolver, compare results with minimisation on and off across internal forwarding, common public names, deep delegations, aliases, DNSSEC-signed domains, negative answers, and business-critical partner services. Observe query traces at controlled authorities when possible to verify what name each layer receives.
\nRoll out by resolver pool with latency, SERVFAIL, fallback, and support-ticket monitoring. Keep a narrow, time-limited exception mechanism for a demonstrably incompatible domain rather than disabling the control globally. Align resolver query logging and retention with the same privacy objective so that reduced upstream disclosure is not offset by unnecessary local collection.
\nRetain the resolver/version matrix, configuration, official product guidance, representative query corpus, packet captures from a controlled test, DNS response comparisons, and exception approvals. Evidence should demonstrate successful resolution and validation where applicable, plus reduced name disclosure at an intermediate authority. Re-run the corpus after major resolver upgrades.
\n