]> Japan Registry Services Co., Ltd.

Japan fujiwara@wide.ad.jp

operations Internet-Draft 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.

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.

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

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.

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

Possible upper limits

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

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.

Upper limit concept Best Current Practice documents should allow for values that are currently in widespread use. However, obvious anomalies may be excluded.

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.

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.

Number of RRSIGs/DNSKEYs/DSs in a RRSet 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.

Number of delegation levels using unrelated name server names 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. 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.

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.

IANA Considerations This document requests no IANA actions.

Security Considerations

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. SIDN Labs InternetNZ USC/ISI USC/ISI ATHENE ATHENE TU Darmstadt Fraunhofer SIT Japan Registry Services Co., Ltd. AWS Security The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS.