]> Japan Registry Services Co., Ltd.

Japan fujiwara@wide.ad.jp

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 proposes reasonable upper-limit values for DNS protocols as a Best Current Practice.

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 and the number of resource records in an RRSet. 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 document introduces some upper limits to the DNS protocol as a best current practice, to allow secure use of the DNS while preserving the flexibility that the DNS protocol was designed to provide.

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 . Gluelessness is the term used to describe delegation without glue.

Background 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. 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. 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 DNS software implementations. 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 '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.) 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 'max-records-per-type' parameter that limits the number of resource records in an RRSet, and the default is 100. 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.

Problem Statement DNS was designed to have as few upper limits as possible to allow for future extensibility. However, in reality, DoS attacks using large responses and the use of excessively long CNAME chains has been reported, and resource-wasting attacks using many DNSKEY/DS/RRSIG combinations have been reported. To mitigate these attacks, it is possible to set realistic upper limits on some parameters, and to cause a name resolution error if those limits are exceeded. In order to avoid breaking existing mechanisms, widely used values should not be treated as errors. Secondary authoritative servers simply provide copies from the primary servers, so they should not cause errors due to the upper limit. Primary authoritative servers are expected to report errors when they read zone files, or receive dynamic updates that contains RRsets that exceed the upper limit. Full-service resolvers may prevent malfunction by treating a name resolution error as responses from authoritative servers that exceed the upper limit. Since restrictions due to datagram size are possible, it seems reasonable to propose an upper limit on data size, etc., as a best current practice. Best Current Practice documents should allow for values that are currently in widespread use. However, apparent anomalies may be excluded. It is desirable to determine the upper limit values by conducting extensive measurements on the Internet and excluding obvious errors or malicious errors, and to set the value that has the least impact.

Possible upper limits

Possible upper limit items Packet size 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 gluelessness delegations Number of alias levels using CNAME Resource records

Packet size There were comments that there are size limitations even if there are 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 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. The size 65535 is large, and attackers use this upper limit to carry out resource-wasting attacks.

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. 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. Therefore, the practical upper limit for the number of name servers is 13. In recent years, there have been cases where many TXT resource records have been set at the zone apex. Many services seem to request their designated authentication tokens written as TXT records at the zone apex to verify domain name registrants. However, there seem to be cases where authentication tokens are only added, as there seems to be no procedure for deleting them once they have been set. It is necessary to standardize and deploy , and to write TXT records not at the zone apex, but application-specific undercore prefix labels. The number of zone apex TXT records will have to remain as is until will be standardized, and the upper limit of the number of resource records in an RRSet may be 100, as the BIND 9 limits by default.

Number of alias levels using CNAME/DNAME Many resolver implementations can resolve over 10 CNAME aliases. Unbound and BIND 9 introduced 'max-query-restarts' parameter, and the default is 11. Each application interprets complex CNAME chains. To avoid complexity in applications, it is recommended to use as few CNAME chains as possible. A maximum of 9 CNAME chains were observed for the top 1 million popular domain names and domain names observed by a university's resolvers. Therefore, a realistic upper limit for CNAME chains is thought to be 9 or 11.

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. Unbound introduced the maximum number of RRSIG validations for an RRset (MAX_VALIDATE_RRSIGS) as 8. There are no good values to base the number of DS resource records or DNSKEY resource records, but having 8 DS records and 8 DNSKEY resource records will be sufficient to handle key rollovers and multi-signers.

Number of delegation levels of gluelessness delegations 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. 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. To avoid complex name resolutions 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.

Recommendation of DNS upper limit values Name upper limit number of RRs in an RRSet 100 number of NS RRs in a delegation 13 number of glue RRs in a delegation 26 number of DS RRs in a delegation 8 number of DNSKEY RRs in an RRSet 8 number of RRSIG RRs for each name and type 8 number of CNAME/DNAME chains 9 number of levels of gluelessness delegations 3 DNS software is expected to make these items configurable parameters that operators can control. Recursive resolvers SHOULD respond with a name resolution error (Server Failure) with Extended DNS Errors if it receives a response from an authoritative server that exceeds the upper limit value. Primary authoritative servers SHOULD be in an error state if they find RRSets that exceed the hard limits when they load zone files, receive zone data by zone transfers, or receive DNS Updates.

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 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. 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. 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. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. SIDN Labs InternetNZ USC/ISI USC/ISI ATHENE ATHENE TU Darmstadt Fraunhofer SIT 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. Brave Software Salesforce Aiven Akamai Technologies Cox Communications Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems.