Mitigating QNAME minimization performance problems
draft-levine-qmin-performance-00

Network Working Group                                          J. Levine
Internet-Draft                                             Standcore LLC
Updates: 9156 (if approved)                             13 November 2023
Intended status: Standards Track                                        
Expires: 16 May 2024

           Mitigating QNAME minimization performance problems
                    draft-levine-qmin-performance-00

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 16 May 2024.

Copyright Notice

   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

Levine                     Expires 16 May 2024                  [Page 1]
Internet-Draft                DNSSEC NOTIFY                November 2023

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Query name explosions . . . . . . . . . . . . . . . . . . . .   2
   3.  Mitigations . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Public Suffix List  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Additional stop patterns  . . . . . . . . . . . . . . . .   3
     3.3.  Stop at two or three  . . . . . . . . . . . . . . . . . .   4
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   4
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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

Levine                     Expires 16 May 2024                  [Page 2]
Internet-Draft                DNSSEC NOTIFY                November 2023

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

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.

Levine                     Expires 16 May 2024                  [Page 3]
Internet-Draft                DNSSEC NOTIFY                November 2023

   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.

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, November 2021,
              <https://www.rfc-editor.org/info/rfc9156>.

6.  Informative References

   [RFC5782]  Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
              DOI 10.17487/RFC5782, February 2010,
              <https://www.rfc-editor.org/info/rfc5782>.

Levine                     Expires 16 May 2024                  [Page 4]
Internet-Draft                DNSSEC NOTIFY                November 2023

   [firstlook]
              de Vries, W., Müller, M., van Rijswijk-Deij, R., and W.
              Wilem, "A First Look at DNS QNAME Minimization", March
              2019, <https://www.researchgate.net/publication/331690595_
              A_First_Look_at_QNAME_Minimization_in_the_Domain_Name_Syst
              em>.

   [secondlook]
              Magnusson, J., Müller, M., Brunstrom, A., and T. Pulls, "A
              Second Look at DNS QNAME Minimization", March 2023,
              <https://link.springer.com/
              chapter/10.1007/978-3-031-28486-1_21>.

Author's Address

   John Levine
   Standcore LLC
   Email: standards@standcore.com

Levine                     Expires 16 May 2024                  [Page 5]