Upper limit value for DNS
draft-fujiwara-dnsop-dns-upper-limit-values-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Kazunori Fujiwara | ||
| Last updated | 2024-07-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fujiwara-dnsop-dns-upper-limit-values-00
Network Working Group K. Fujiwara
Internet-Draft JPRS
Intended status: Best Current Practice 8 July 2024
Expires: 9 January 2025
Upper limit value for DNS
draft-fujiwara-dnsop-dns-upper-limit-values-00
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 9 January 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 9 January 2025 [Page 1]
Internet-Draft dns-upper-limit-value July 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Possible upper limits . . . . . . . . . . . . . . . . . . . . 2
3.1. Number of A, AAAA, NS RRs in a RRSet . . . . . . . . . . 3
3.2. Number of alias levels using CNAME/DNAME . . . . . . . . 3
3.3. Number of RRSIGs/DNSKEYs/DSs in a RRSet . . . . . . . . . 3
3.4. Number of delegation levels using unrelated name server
names . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Possible upper limit values . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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.
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.
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. Possible upper limits
Fujiwara Expires 9 January 2025 [Page 2]
Internet-Draft dns-upper-limit-value July 2024
3.1. Number of A, AAAA, NS RRs 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 13.
3.2. Number of alias levels using CNAME/DNAME
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.
3.3. 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 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.
3.4. 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.
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.
Fujiwara Expires 9 January 2025 [Page 3]
Internet-Draft dns-upper-limit-value July 2024
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.
Then, 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.
4. Possible upper limit values
+============================================+===================+
| 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 |
+--------------------------------------------+-------------------+
Table 1
Fujiwara Expires 9 January 2025 [Page 4]
Internet-Draft dns-upper-limit-value July 2024
Recursive resolvers MAY return a name resolution error (Server
Failure) if it receives a response from an authoritative server that
exceeds these limits.
5. IANA Considerations
This document requests no IANA actions.
6. Security Considerations
7. References
7.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>.
7.2. Informative References
[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.
Fujiwara Expires 9 January 2025 [Page 5]
Internet-Draft dns-upper-limit-value July 2024
Email: fujiwara@wide.ad.jp
Fujiwara Expires 9 January 2025 [Page 6]