]> Cloudflare

jabley@cloudflare.com

Cloudflare

sebastiaan@cloudflare.com

Operations and Management Domain Name System Operations dns dns protocol dns message The existing Domain Name System (DNS) specifications lack some clarity in their description of the process by which individual sections of a DNS message are constructed. This document updates RFC 1034 and RFC 1035 to provide a clearer specification, consistent with deployed implementations. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction specifies an algorithm to follow when constructing a response to a DNS QUERY. This algorithm in some cases can result in multiple RRSets being included in a single section of a DNS message, e.g. when handling CNAME resource records. Most consumers of DNS responses, such as stub resolvers, have interpreted the direction to copy or store particular RRSets in sections of a DNS response to mean "append", treating each section as an ordered list of RRSets. In particular, many stub stub resolvers are known to rely upon that interpretation when processing DNS responses, e.g. see . Some DNS implementations employ algorithms in other sections that aim to optimise processing of responses received by initiators, e.g. NAPTR before SRV before A/AAAA in the additional section of a response. This behaviour has not been observed to cause any interoperability problems, and is explicitly permitted by this document. This document updates to specify that the answer section in a DNS message is an ordered list of RRSets, but that other sections may be ordered differently. This document clarifies the directions provided in to match the observed behaviour and expectations of deployed software.

Conventions and Definitions 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. This document assumes familiarity with terminology specific to the Domain Name System (DNS) as described in .

Updates to RFC 1034 specifies the algorithms by which sections of a DNS response are constructed. For example, step 3 of the algorithm described in section 4.3.2 contains the direction "copy all RRs which match QTYPE into answer section". In this case, and in all other cases where specifies that particular RRSets be included in the answer section of a DNS message, the section MUST be treated as an ordered list of RRSets. When it is necessary to include new RRSets in a section of a DNS message that is under construction, those RRSets MUST be appended. The receiver of a DNS message MAY refuse to process DNS messages that have been constructed differently. When constructing other sections of a DNS message, each section MAY be treated as a non-ordered list. A receiver of a DNS message MUST NOT reject a DNS message on the basis of the order of RRSets in those sections.

Updates to RFC 1035 In a DNS message, the answer section MUST be considered to be an ordered set of RRSets. All other sections in a DNS message MUST be considered to be a non-ordered set. DNS implementations MUST construct each section in a DNS response according to the algorithms specified in , as clarified in .

Security Considerations The recommendations contained in this document have no known security implications.

IANA Considerations This document has no IANA actions.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. 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. 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. Informative References Cloudflare Cisco

Events of 8 January 2026 Cloudflare operates a well-known public DNS resolver known as 1.1.1.1, after one of the IPv4 addresses associated with the service. On 8 January a software change in the 1.1.1.1 service had the unintential side-effect of changing the order in which RRSets were encoded in the answer section of DNS responses, in the case where constructing the responses involved CNAME processing. The previous ordering was as clarified in and . The change in behaviour was not detected by a corresponding failure in a regression test, since the ordering in the answer section was not considered to be significant. Following the software release, Cloudflare became aware of significant numbers of deployed DNS client implementations that were suffering from failure. In particular, the getanswer_r() function invoked by the getaddrinfo() function in glibc was found to fail to function, and some deployed ethernet switches were observed to reboot when trying to resolve the names of configured NTP servers . The impact associated with this event was particularly widespread because of the widespread use of the 1.1.1.1 resolver. However, the two examples of client implementations are also widely deployed in systems that may well be upgraded only infrequently (or never upgraded at all). See for additional information.

Editorial Notes (remove before publication)

draft-jabley-dnsop-ordered-sections-00 Initial draft circulated for comment in 2015; subsequently expired.

draft-jabley-dnsop-ordered-answer-section-00 Draft revitalised following some operational excitement. Added competent co-author.

Acknowledgments The contributions of Mark Andrews and Paul Vixie to the original revision of this document are acknowledged.