]> Cloudflare

jabley@cloudflare.com

Cloudflare

sebastiaan@cloudflare.com

Operations and Management Domain Name System Operations dns dns protocol dns message cname In the DNS, recursive resolvers receive queries and formulate corresponding responses by reference to data obtained from authoritative servers. In the case where the query name (QNAME) and class (QCLASS) in the query matches an owner name in the DNS where a canonical name (CNAME) resource record is published, the response includes both the CNAME record and the resource record set corresponding to the request's query type (QTYPE) published at the CNAME target. The ordering of these two different RRSets has not previously been clearly specified, but operational experience based on real-world client implementations confirms that the order is important. This document updates RFC 1034 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 The DNS specification includes some ambiguity around the processing of queries that require the processing of CNAME resource records, as discussed in . Different assumptions about the way that corresponding DNS responses are constructed are known to have caused widespread negative impact, as described in . This document updates the DNS specification to resolve the ambiguity. The clarification to the specification can be found in .

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 .

Ambiguity in the DNS Specification introduces the CNAME RRType to be one that "identifies the canonical name of an alias". The implementation of the CNAME resource record is further described in section 3.6 as follows:

• CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. For example, suppose a name server was processing a query with for USC- ISIC.ARPA, asking for type A information, and had the following resource records: Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME.

The required processing of requests that require CNAME processing is further described in section 4.3.2, in particular in the step labelled 3 (a) of the recursive algorithm, as follows:

Some implementations behave as though the direction "copy all RRs which match QTYPE into the answer section" implies a required or expected ordering, in the sense that resource records added first should be at the beginning of the section and subsequent RRs should be appended (see for an example). However, the various sections of a DNS message are not defined in the specification as being ordered lists. For example, the "answer section of the response" is described in section 3.7 as follows:

• DNS queries and responses are carried in a standard message format. The message format has a header containing a number of fixed fields which are always present, and four sections which carry query parameters and RRs. [...] Answer Carries RRs which directly answer the query.

The confusion on CNAME ordering stems from section 4.3.1, which describes recursive responses as follows:

• If recursive service is requested and available, the recursive response to a query will be one of the following:

While the word "preface" suggests that CNAME RRs should precede other records, this language is descriptive rather than normative, lacking the explicit requirement keywords that would later be defined in . This ambiguity has led to varying interpretations among implementers and contributed to interoperability issues as described in . This document aims to resolve this ambiguity with a clear specification for the ordering of RRSets in the answer section of a DNS message for CNAME responses (see ).

Consequences of Ambiguity A recursive server performing CNAME preocessing without interpreting the direction in that "copy" means "append" might reasonably generate response messages with arbitrary ordering of RRSets within the answer section. A client of a recursive server that interprets the direction in the other way, that "copy" does indeed mean "append", might potentially react badly to receiving a response where the answer section has been constructed differently. A real-world example of such a consequence is described in . Since it is known that at least some widely-deployed clients of resolver servers expect the "copy" direction in to be interpreted as "append", and react badly when they receive responses that do not meet this expectation, this document updates the DNS standard to choose and require the interpretation of that promotes the greatest operational stability as described in . This is a pragmatic measure undertaken in recognition of the significant installed base of software that have this expectation, and in particular the degree to which such software is deployed in unmanaged devices that might never be updated.

Updates to RFC 1034 A DNS implementation following the algorithm described in MUST interpret any direction to "copy RRs into the answer section" when processing CNAMEs to mean that the RRs concerned should be appended to any existing records that have already been accumulated in an earlier step of the algorithm. The ordering of individual RRs within an RRSet is not significant. In the case where one or more CNAME RRs are processed in order to construct a DNS response, the answer section MUST include a CNAME RRSet whose owner name matches the QNAME in the query first, and subsequent RRSets whose owner name matches the preceding CNAME RDATA, in order. For example, consider a query for www.example.com with QTYPE A where the following CNAME chain exists:

The answer section MUST be ordered the same. The CNAME records MUST NOT appear after the records they alias to:

The CNAME records MUST NOT appear out of order in their chain:

Client implementations SHOULD accept responses where CNAME RRSets appear in any order, but server implementations MUST NOT rely on this capability when generating responses.

Security Considerations The ambiguity described in is known to have led to widespread instability in at least one case, as described in . The clarification provided by this document does not present additional security concerns for the DNS.

IANA Considerations This document has no IANA actions.

References Normative References 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 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. 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 described in . 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.

draft-jabley-dnsop-ordered-answer-section-01 Bumped version number while we wait patiently for wg time.

draft-jabley-dnsop-ordered-answer-section-02 Following feedback from the working group, made the clarification more narrow. The document now provides advice for the construction of answer sections that involve CNAME processing; earlier revisions of this document provided more general ordering prescription that was considered by the working group to be unnecessary.

Acknowledgments Mark Andrews and Paul Vixie contributed to the original revision of this document in 2015, triggered by a similar event to that described in . This revision benefited from advice from Petr Špaček, Robert Edmonds, Paul Wouters, Peter Thomassen, Florian Weimer, Dave Lawrence, Mark Andrews (again), Libor Peltan, Warren Kumari, Philip Homburg, Ondřej Surý, John Levine, Manu Bretelle, Kevin Fleming and Xiang Li.