Mitigating QNAME minimization performance problems

Introduction defines QNAME minimization, a method to improve DNS privacy by truncating query names sent to authoritative name servers. In effect it probes the DNS one label at a time. If one looks up www.bigbank.example, minimization makes the DNS cache send a query for example to the root, a query for bigbank.example to a server for example, and the real query for www.bigbank.example to a server for bigbank.example. This works well when there is a zone cut between each label in a name, since the number of queries is the same as it would be without minimization. But when a zone includes more than one level of labels, it can cause multiple redundant queries to the same server, significantly increasing the load on that server without additional privacy benefits.

Query name explosions In the authors instrumented some popular name servers and found that minimization increased traffic to Unbound by 17-19% and to BIND by 15-26%. It does not appear that they tried to tell whether traffic to some zones increased more than others. DNSBLs turn IP addresses into domain names using the same octet or digit reversing technique that rDNS uses. Mail clients look up the domain name to see if the IP is listed. For example, a listing for IP 192.0.2.99 might be looed up at 99.2.0.192.bad.example.com. Similarly an IPv6 address 2001:db8:1:2:3:4:567:89ab would be looked up at b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.bad.example.com. Since DNSBL domain names have a lot of labels, they are unusually affected by QNAME minimization. In the absence of minimization, both of those domain names would usually be looked up with a single query. The base domain bad.example.com is likely to be cached from prior DNSBL lookups, and the DNSBL is a single zone. With minimization, it may be as many as 4 for the IPv4 address and 18 for the IPv6 address. suggests limiting the number of queries but the suggested limit is 10 which doesn't help much. Since mail comes from all over the IP address space, caches don't help much. The author did some simulations of DNSBL traffic using traces of IP addresses and found that a results were only used about once before being removed from the cache. A few very heavily used addresses remained in the cache indefinitely, but a long tail of queries for small senders (typically spambots) weren't reused at all.

Mitigations Several minor changes to QNAME minimization could significantly decrease the number of redundant queries with little or decrease in privacy.

Public Suffix List In the authors observe that it is rare for domains under a registered domain to be under different management. They suggest that caches use a Public Suffix List (PSL) and stop truncating after PSL+1, one label below a PSL entry. For example, since "com" is in the PSL, a lookup for a.b.example.com wouod query com, then example.com, then stop truncating and query a.b.example.com. This has two practical disadvantages. One is that the PSL is a large static file, currently about 300K, so periodically fetching it (it changes nearly every day) is a fair amount of added work. The other is that many of the PSL entries, particularly the longer ones in the "private" section in the PSL, are irrelevant to query minimization because the names below the PSL entry are all in the same zone.

Additional stop patterns suggests that labels that start with an underscore be treated as a special case, to stop truncation when one is encountered. To deal with the DNSBL situation, if the remaining labels are four groups of digits, or sixteen single hex digit labels, stop because it's probably a DNSBL. Depending on how one feels about leaking info to RIRs, one might want to special case the in-addr.arpa and ip6.arpa domains since rDNS has the same syntax, but the rDNS tree has a lot of zone cuts. Other names with the same problem, many labels in the same zone include TBD.

Stop at two or three In the authors found that Google's DNS stopped truncating after two labels, since this got most of the benefit of full minimization with no increase in the load. They discovered this by accident when doing minimization tests on four label names, and Google appeared to their test not to minimize. Most top-level domains have registered names at the second level, and nearly all at the second or third level. so stopping after three labels would likely get nearly all of the benefit at very low cost.

Security considerations Less minimizing means more leakage, but if done sensibly, not much. Depending on your point of view, quadrupling the load on servers based on the structure of their zones might or might not be a security issue.