Upper limit values for DNS
draft-fujiwara-dnsop-dns-upper-limit-values-01

Network Working Group                                        K. Fujiwara
Internet-Draft                                                      JPRS
Intended status: Best Current Practice                   21 October 2024
Expires: 24 April 2025

                       Upper limit values for DNS
             draft-fujiwara-dnsop-dns-upper-limit-values-01

Abstract

   There are parameters in the DNS protocol that do not have clear upper
   limit values.  If a protocol is implemented without considering the
   upper limit, it may become vulnerable to DoS attacks, and several
   attack methods have been proposed.  This draft proposes reasonable
   upper limit values for DNS protocols.

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 24 April 2025.

Copyright Notice

   Copyright (c) 2024 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.

Fujiwara                  Expires 24 April 2025                 [Page 1]
Internet-Draft           dns-upper-limit-values             October 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Recent upper limit values in implementations  . . . . . .   3
   4.  Possible upper limits . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Possible upper limit items  . . . . . . . . . . . . . . .   4
     4.2.  Packet size limits  . . . . . . . . . . . . . . . . . . .   4
     4.3.  Upper limit concept . . . . . . . . . . . . . . . . . . .   4
     4.4.  Number of Resource Records in a RRSet . . . . . . . . . .   4
     4.5.  Number of alias levels using CNAME/DNAME  . . . . . . . .   5
     4.6.  Number of RRSIGs/DNSKEYs/DSs in a RRSet . . . . . . . . .   5
     4.7.  Number of delegation levels using unrelated name server
           names . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Possible upper limit items  . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   There are parameters in the DNS protocol that do not have clear upper
   limits.  For example, the number of alias levels using CNAME Resource
   records, the number of name servers, the number of Resource Records
   in an RRSet, the number of delegation levels using unrelated name
   server names, and the number of DNSKEYs for each domain name.

   If a protocol is implemented without considering the upper limit, it
   may become vulnerable to DoS attacks, and several attack methods have
   been proposed.

   This draft proposes reasonable upper limits for DNS protocols.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Many of the specialized terms used in this document are defined in
   DNS Terminology [RFC9499].

Fujiwara                  Expires 24 April 2025                 [Page 2]
Internet-Draft           dns-upper-limit-values             October 2024

3.  Problem Statement

   There are parameters in the DNS protocol that do not have clear upper
   limits.  For example, the number of Resource Records in an RRSet, the
   number of alias levels using CNAME Resource records, the number of
   delegation levels using unrelated name server names.

   If a protocol is implemented without considering the upper limit, it
   may become vulnerable to DoS attacks.  In recent years, DNS
   vulnerabilities research have been actively progressed and many
   vulnerabilities have been made public.  Each time a vulnerability is
   discovered, upper limits on the execution time, number of attempts,
   and size are added to the implementation.

   If we set upper limits for some parameters in advance and treat
   anything that exceeds them as an error, we can reduce the need to
   respond reactively.

   This draft proposes aggressive upper limits in order to advance
   discussions on determining upper limit values in DNS protocol.

3.1.  Recent upper limit values in implementations

   *  Number of Resource Records in an RRSet

      BIND 9 introduced 'max-records-per-type' parameter and the default
      is 100.

      CVE-2024-1737 "BIND's database will be slow if a very large number
      of RRs exist at the same name" was reported and BIND 9.18.28
      implemented the limit.

   *  Number of RRSIGs/DNSKEYs/DSs in a RRSet

      KeyTrap [KeyTrap] is a vulnerability caused by the fact that there
      is no upper limit on the number of DNSKEY, DS, or RRSIG resource
      records.

      Unbound introduced the maximum number of RRSIG validations for an
      RRset (MAX_VALIDATE_RRSIGS) as 8 and the maximum allowed digest
      match failures per DS, for DNSKEYs with the same properties
      (MAX_DS_MATCH_FAILURES) as 4.

Fujiwara                  Expires 24 April 2025                 [Page 3]
Internet-Draft           dns-upper-limit-values             October 2024

4.  Possible upper limits

4.1.  Possible upper limit items

   *  Number of Resource Records in a RRSet

   *  Number of NS Resource Records in a delegation

   *  Number of DS Resource Records in a delegation

   *  Number of glue RRs in a delegation

   *  Number of DNSKEY Resource Records in a DNSKEY RRSet

   *  Number of RRSIG RRs for each name and type

   *  Number of levels of unrelated only delegations

   *  Number of CNAME/DNAME chains

4.2.  Packet size limits

   There were comments that there are size limitations even if no
   precise upper limit is set.

   The DNS packet format has an upper limit of 65535 octets, so an RRset
   cannot exceed that size.  Attackers use this upper limit to carry out
   resource-wasting attacks.

   Also, the size of a single resource record is 65535 octets minus DNS
   header size because RDLENGTH is 16 bits.

   The size of a DNS response that can be sent using unfragmented UDP is
   about 1400 octets.  [I-D.ietf-dnsop-avoid-fragmentation]

4.3.  Upper limit concept

   Best Current Practice documents should allow for values that are
   currently in widespread use.

   However, obvious anomalies may be excluded.

4.4.  Number of Resource Records in a RRSet

   Since there are 13 root name servers and 13 name servers for com and
   net TLDs, the maximum number of NS RR in an NS RRSet should be larger
   than or equal to 13.

Fujiwara                  Expires 24 April 2025                 [Page 4]
Internet-Draft           dns-upper-limit-values             October 2024

   Since there are 13 name servers for root, com, net and they have both
   IPv4 and IPv6 addresses, 26 glue records in a delegation should be
   allowed.

4.5.  Number of alias levels using CNAME/DNAME

   Many resolver implementations can resolve over 10 CNAME aliases.

   Unbound introduced 'max-query-restarts' parameter and the default is
   11.  (Hard limit on the number of times Unbound is allowed to restart
   a query upon encountering a CNAME record.)

   However, a stub resolver that receives a response containing multiple
   CNAME aliases must find the final A, AAAA Resource record that
   corresponds to the CNAME in each application.  In order to avoid this
   complexity, the recommend number of CNAME chains is 1.  CNAME/DNAME
   aliases with more than three levels are too complicated.

4.6.  Number of RRSIGs/DNSKEYs/DSs in a RRSet

   KeyTrap [KeyTrap] is a vulnerability caused by the fact that there is
   no upper limit on the number of DNSKEY, DS, or RRSIG resource
   records.  If there were upper limits on these, the damage could be
   mitigated.

   Therefore, considering the DNSKEY rollover and the multi-signer
   model, the maximum number of DNSKEYs for both KSK and ZSK may be 6.
   The maximum number of DS RRs in a DS RRSet may be 3.

   The number of RRSIG RRs for each owner name and type pair may be 6.

   Unbound introduced the maximum number of RRSIG validations for an
   RRset (MAX_VALIDATE_RRSIGS) as 8.

4.7.  Number of delegation levels using unrelated name server names

   [RFC9471] states that all in-domain glue records are attached to the
   delegation response.  Therefore, using in-domain name server names
   for DNS delegation minimizes name resolution costs.

   Unrelated (or, rarely sibling) name server names are used/required
   for DNS hosting services.

   However, using unrelated name server names increases the name
   resolution costs and may increase the likelihood of name resolution
   errors.

Fujiwara                  Expires 24 April 2025                 [Page 5]
Internet-Draft           dns-upper-limit-values             October 2024

   This section proposes to use in-domain name servers as much as
   possible for name resolution of unrelated name server names to reduce
   the name resolution costs.

   Unrelated(out-of-bailiwick) name server names are required for DNS
   hosting services.  However, using unrelated name server names
   increases the name resolution costs.  For some domain names, there
   are multiple layers of dependence on unrelated name server names when
   resolving the name.

   Furthermore, there are cases where cyclic dependencies in delegation
   occur, settings that depend on sibling glue, and cases where the
   sibling glue disappears or some name servers stop responding, making
   it impossible to resolve names.

   [Tsuname2021] pointed out attacks and countermeasures that use
   increased load due to cyclic dependencies.

   Many cyclic delegations are likely due to misconfigurations.

   To avoid complex name resolution and misconfigurations, it is better
   to avoid using unrelated name server names as much as possible.

   Unrelated name server names SHOULD be hosted by a domain name with at
   least one in-domain name server name.  In other words, DNS providers
   SHOULD have at least one in-domain nameserver for their domain names.

5.  Possible upper limit items

   +============================+==========+==========+================+
   | Name                       | proposal | current  | implementation |
   |                            |          | use      |                |
   +============================+==========+==========+================+
   | DNS message size (without  | <= 1400  |          | <= 1232 on UDP |
   | PQC)                       |          |          |                |
   +----------------------------+----------+----------+----------------+
   | Number of Resource         | <= 13    | ./com NS | 100 (BIND)     |
   | Records in a RRSet         |          |          |                |
   +----------------------------+----------+----------+----------------+
   | Number of NS Resource      | <= 13    | ./com NS |                |
   | Records in a delegation    |          |          |                |
   +----------------------------+----------+----------+----------------+
   | Number of glue RRs in a    | <= 26    | com glue |                |
   | delegation                 |          |          |                |
   +----------------------------+----------+----------+----------------+
   | Number of DS Resource      | <= 3     | need     |                |
   | Records in a delegation    |          | research |                |
   +----------------------------+----------+----------+----------------+

Fujiwara                  Expires 24 April 2025                 [Page 6]
Internet-Draft           dns-upper-limit-values             October 2024

   | Number of DNSKEY Resource  | <= 6     | need     |                |
   | Records in a DNSKEY RRSet  |          | research |                |
   +----------------------------+----------+----------+----------------+
   | Number of RRSIG RRs for    | <= 2     | need     | 8 (Unbound)    |
   | each name and type         |          | research |                |
   +----------------------------+----------+----------+----------------+
   | Number of levels of        | <= 2     | need     |                |
   | unrelated only             |          | research |                |
   | delegations                |          |          |                |
   +----------------------------+----------+----------+----------------+
   | Number of CNAME/DNAME      | <= 3     | 10       | 11 (Unbound)   |
   | chains                     |          |          |                |
   +----------------------------+----------+----------+----------------+

                                  Table 1

   Recursive resolvers MAY respond with a name resolution error (Server
   Failure) if it receives a response from an authoritative server that
   exceeds these limits.

6.  IANA Considerations

   This document requests no IANA actions.

7.  Security Considerations

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9471]  Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS
              Glue Requirements in Referral Responses", RFC 9471,
              DOI 10.17487/RFC9471, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9471>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

Fujiwara                  Expires 24 April 2025                 [Page 7]
Internet-Draft           dns-upper-limit-values             October 2024

8.2.  Informative References

   [I-D.ietf-dnsop-avoid-fragmentation]
              Fujiwara, K. and P. A. Vixie, "IP Fragmentation Avoidance
              in DNS over UDP", Work in Progress, Internet-Draft, draft-
              ietf-dnsop-avoid-fragmentation-20, 26 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              avoid-fragmentation-20>.

   [KeyTrap]  Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael
              Waidner, "The KeyTrap Denial-of-Service Algorithmic
              Complexity Attacks on DNS", 2024.

   [Tsuname2021]
              Moura, G. M., Sebastian Castro, John S Heidemann, and Wes
              Hardaker, "TsuNAME: exploiting misconfiguration and
              vulnerability to DDoS DNS", IMC '21: Proceedings of the
              21st ACM Internet Measurement Conference , 2021.

Author's Address

   Kazunori Fujiwara
   Japan Registry Services Co., Ltd.
   Japan
   Email: fujiwara@wide.ad.jp

Fujiwara                  Expires 24 April 2025                 [Page 8]