| Internet-Draft | DNSSEC NOTIFY | November 2023 |
| Levine | Expires 16 May 2024 | [Page] |
QNAME minimization improves DNS privacy by truncating query names sent to authoritative name servers. While it works well when there is a zone cut between each label in a name, 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. This document describes some situations where minimization causes load problems and potential ways to fix the problem.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 May 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC9156] 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.¶
In [firstlook] 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 [RFC5782] 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. Section 2.3 of [RFC9156] 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.¶
Several minor changes to QNAME minimization could significantly decrease the number of redundant queries with little or decrease in privacy.¶
In [secondlook] 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.¶
Section 2.3 of [RFC9156] 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.¶
In [secondlook] 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.¶
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.¶