Internet-Draft DNSSEC NOTIFY May 2024
Levine Expires 6 November 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-levine-qmin-performance-01
Updates:
9156 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
J. Levine
Standcore LLC

Mitigating QNAME minimization performance problems

Abstract

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,

Status of This Memo

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 6 November 2024.

Table of Contents

1. Introduction

[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.

2. Query name explosions

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 looked 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.

3. Mitigations

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

3.1. Public Suffix List

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 would 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.

3.2. Additional stop patterns

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 recognize DNSBLs and avoid excess queries, 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 treat the in-addr.arpa and ip6.arpa domains as special cases, since rDNS has the same syntax as DNSBLs, but the rDNS tree has a lot of zone cuts reflecting its delegations.

Other names with many labels in the same zone include TBD.

3.3. Stop at two or three

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.

4. 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.

5. Normative References

[RFC9156]
Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, , <https://www.rfc-editor.org/info/rfc9156>.

6. Informative References

[RFC5782]
Levine, J., "DNS Blacklists and Whitelists", RFC 5782, DOI 10.17487/RFC5782, , <https://www.rfc-editor.org/info/rfc5782>.
[firstlook]
de Vries, W., Müller, M., van Rijswijk-Deij, R., and W. Wilem, "A First Look at DNS QNAME Minimization", , <https://www.researchgate.net/publication/331690595_A_First_Look_at_QNAME_Minimization_in_the_Domain_Name_System>.
[secondlook]
Magnusson, J., Müller, M., Brunstrom, A., and T. Pulls, "A Second Look at DNS QNAME Minimization", , <https://link.springer.com/chapter/10.1007/978-3-031-28486-1_21>.

Author's Address

John Levine
Standcore LLC