Internet-Draft | dns-upper-limit-value | July 2024 |
Fujiwara | Expires 9 January 2025 | [Page] |
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.¶
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 9 January 2025.¶
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.¶
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.¶
I 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.¶
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].¶
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 13.¶
Many resolver implementations can resolve over 10 CNAME aliases. 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, we recommend using up to one level of CNAME/DNAME, and CNAME/DNAME aliases with more than three levels MAY be treated as a name resolution error.¶
KeyTrap [KeyTrap] is a vulnerability caused by the fact that there is no upper limit on the number of DNSKEY RRs, DSs, or RRSIGs. 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. If that limit is exceeded, the validating resolvers may result in a name resolution error.¶
The number of RRSIG RRs for each owner name and type pair may be 6.¶
Name | Upper limit value |
---|---|
Number of CNAME chains | 1 ? 3 ? 9 ? 16 ? |
Number of DS | 3 |
Number of DNSKEY | 6 |
Number of RRSIG RRs for each name and type | 6 |
Number of levels of unrelated only | 1 |
Number of RRs in one RRSet | 13 |
Number of glue RRs in a delegation | 26 |
Recursive resolvers MAY return a name resolution error (Server Failure) if it receives a response from an authoritative server that exceeds these limits.¶
This document requests no IANA actions.¶