]> Japan Registry Services Co., Ltd.

Japan fujiwara@wide.ad.jp

NLnet Labs

Netherlands yorgos@nlnetlabs.nl

operations Internet-Draft DNS was designed to have as few hard upper limits as possible to allow for future extensibility. However, the lack of a clear upper limit leads to vulnerabilities, and several attack methods have been reported. This document collects upper limit values implemented by DNS software to avoid vulnerabilities.

Introduction DNS was designed to have as few upper limits as possible to allow for future extensibility described in the paper "Development of the Domain Name System" . If a protocol is implemented without considering the upper limit, it may become vulnerable to DoS attacks. 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 and the number of resource records in an RRSet. This document collects upper limit values implemented by DNS software to avoid vulnerabilities. This document is intended to serve as a basis for discussions that will lead to the creation of a future Best Current Practice document.

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 BCP 14 when, and only when, they appear in all capitals, as shown here. The specialized terms used in this document are defined in DNS Terminology . Glueless delegation (Gluelessness) is the term used to describe delegation without glue.

Implemented upper limits

Packet size There were comments that there are size limitations even if no precise upper limits are set. The DNS packet format has an upper limit of 65535 octets, so an RRset cannot exceed that size. Also, the upper limit size of a single resource record is 65535 octets minus the DNS header size because RDLENGTH is 16 bits. Section 4.2.1 UDP usage of limits the UDP message size to 512. The size of a DNS response that can be sent using unfragmented UDP is about 1400 octets. proposed 1232 octets and is used as the default value in most DNS software.

DNS Response Rate Limiting describes DNS Reflector Attacks and how to prevent the use of default configured recursive nameservers. Simply preparing a large RRSet can increase the amplification factor of DNS Reflector Attacks. Countermeasures for recursive resolvers were described in , however, countermeasures for authoritative servers have not been standardized as an RFC and are implemented in various software as DNS Response Rate Limiting.

Number of alias levels using CNAME/DNAME CNAME aliases are widely used; however, when there are multiple levels of CNAME aliases, full-service resolvers have to redo the name resolution, which increases the load. And more, each 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. Unbound and BIND 9 introduced the 'max-query-restarts' parameter, and their default value is 11.

Number of Resource Records in a RRSet Currently, many web services that use domain names require that a TXT record containing a token of their choosing be placed at the zone apex to verify the registrant domain name. A large enterprise set 74 TXT records at its zone apex. 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. BIND 9 introduced the 'max-records-per-type' parameter that limits the number of resource records in an RRSet, and the default value is 100. Unbound has the 'iter-scrub-ns' parameter that limits the number of RRs explicitly for the NS RRSet and the default value is 20. Unbound has the 'iter-scrub-cname' parameter that limits the number of CNAME/DNAME records in an upstream reply by clipping off the remainder of the reply. The default value is 11.

Number of NS records in a delegation Although we could not find a clear explanation, the upper limit value of the number of name server names that can be registered for gTLDs and ccTLDs is 13.

Number of RRSIGs/DNSKEYs/DSs in a RRSet is a vulnerability caused by the fact that there is no upper limit on the number of DNSKEY, DS, or RRSIG resource records which could result in CPU exhaustion during DNSSSEC validation attempts. Unbound introduced, as hard-coded values, 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 8.

Number of NSEC3 hash calculations is a vulnerability that exploits the amount of NSEC3 hash iterations needed when proving negative responses which could result in CPU exhaustion during DNSSEC validation attempts. Unbound introduced, as a hard-coded value, the maximum number of NSEC3 hash calculations with a default value of 8.

Number of outgoing queries per incoming query Unbound limits the number of outgoing queries per incoming query with the 'max-sent-count' parameter with a default value of 32. This counter is reset on query restarts (e.g., delagation points or CNAME/DNAME redirections). Unbound limits the number of outgoing queries per incoming query with the 'max-global-quota' parameter with a default value of 200. This counter is not reset on query restarts (e.g., delagation points or CNAME/DNAME redirections) and it persists on any internal subqueries spawned.

Number of NS resolution queries Unbound limits the number of NS resolution queries needed per incoming query to a hard-coded value of 64. Unbound limits the number of NS resolution queries neeeded per delegation point to a hard-coded value of 16, in response to . Unbound limits the number of acceptable NXDOMAIN replies for NS queries (for a query and its subqueries) to a hard-coded value of 5 in response to .

Number of delegation levels of glueless delegations Unrelated (or, rarely sibling) name server names are used/required for DNS hosting services. 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. For some domain names, there are multiple layers of dependence on unrelated name server names when resolving the name. If information on unrelated name server names is not in the cache, the recursive resolver must perform A/AAAA name resolution for the unrelated name server names. Frequent use of unrelated name server names can cause unstable name resolution. 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. allows three levels of gluelessness. Unbound limits the maximum number of referral responses accepted per resolution attempt to a hard-coded value of 130.

Discussions on future upper limits Evaluation is necessary before setting common upper limit values. Implementing possible upper limits as configurable parameters that operators can control is useful. If we set upper limits on authoritative servers in the future, errors should be detected on the primary servers. Secondary servers should not detect errors because they only receive zone transfers.

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. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 ISC Tel Aviv University Tel Aviv University The Interdisciplinary Center USC/ISI Digital Equipment Corp. University of ILLINOIS CHICAGO The widely deployed Extension Mechanisms for DNS (EDNS(0)) 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.