Internet-Draft | dns-upper-limit-values | October 2024 |
Fujiwara | Expires 24 April 2025 | [Page] |
- Workgroup:
- Network Working Group
- Internet-Draft:
- draft-fujiwara-dnsop-dns-upper-limit-values-01
- Published:
- Intended Status:
- Best Current Practice
- Expires:
Upper limit values for DNS
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.¶
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].¶
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.¶
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.¶
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.¶
5. Possible upper limit items
Name | proposal | current use | implementation |
---|---|---|---|
DNS message size (without PQC) | <= 1400 | <= 1232 on UDP | |
Number of Resource Records in a RRSet | <= 13 | ./com NS | 100 (BIND) |
Number of NS Resource Records in a delegation | <= 13 | ./com NS | |
Number of glue RRs in a delegation | <= 26 | com glue | |
Number of DS Resource Records in a delegation | <= 3 | need research | |
Number of DNSKEY Resource Records in a DNSKEY RRSet | <= 6 | need research | |
Number of RRSIG RRs for each name and type | <= 2 | need research | 8 (Unbound) |
Number of levels of unrelated only delegations | <= 2 | need research | |
Number of CNAME/DNAME chains | <= 3 | 10 | 11 (Unbound) |
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.¶
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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9471>.
- [RFC9499]
- Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/rfc/rfc9499>.
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, , <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", .
- [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 , .