Internet-Draft dns-upper-limit-value July 2024
Fujiwara Expires 9 January 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-fujiwara-dnsop-dns-upper-limit-values-00
Published:
Intended Status:
Best Current Practice
Expires:
Author:
K. Fujiwara
JPRS

Upper limit value 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 9 January 2025.

▲

Table of Contents

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

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.

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

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

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

7.2. Informative References

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

Author's Address

Kazunori Fujiwara
Japan Registry Services Co., Ltd.