idnits 2.17.1 draft-jabley-dnsop-ordered-answers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2015) is 3122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Dyn, Inc. 4 Updates: 1034, 1035 (if approved) October 9, 2015 5 Intended status: Standards Track 6 Expires: April 11, 2016 8 Ordering of RRSets in DNS Messages 9 draft-jabley-dnsop-ordered-answers-00 11 Abstract 13 The existing Domain Name System (DNS) specifications lack some 14 clarity in their description of the process by which individual 15 sections of a DNS message are constructed. 17 This document updates RFC 1034 and RFC 1035 to provide a clearer 18 specification, consistent with deployed implementations. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 11, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Updates to RFC 1034 . . . . . . . . . . . . . . . . . . . . . 5 57 4. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 11 65 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 A.2. Change History . . . . . . . . . . . . . . . . . . . . . . 11 67 A.2.1. draft-jabley-dnsop-ordered-answers-00 . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Terminology 72 This document uses terminology specific to the Domain Name System 73 (DNS), descriptions of which can be found in 74 [I-D.ietf-dnsop-dns-terminology]. 76 In an exchange of DNS messages between two hosts, this document 77 refers to the host sending a DNS request as the initiator, and the 78 host sending a DNS response as the responder. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 [RFC1034] specifies an algorithm for use by responders when 87 constructing response to a DNS QUERY. This algorithm in some cases 88 can result in multiple RRSets being included in a single section of a 89 DNS message, e.g. when handling CNAME resource records. 91 Many responder implementations have interpreted the direction to copy 92 or store particular RRSets in the answer section of a DNS response to 93 mean "append", treating each section as an ordered list of RRSets. 94 Many initiators, in particular stub resolvers, are known to rely upon 95 that interpretation when processing DNS responses received from 96 responders. 98 Some DNS implementations employ algorithms in other sections that aim 99 to optimise processing of responses received by initiators, e.g. 100 NAPTR before SRV before A/AAAA in the additional section of a 101 response. This behaviour has not been observed to cause any 102 interoperability problems, and is explicitly permitted by this 103 document. 105 This document updates [RFC1035] to specify that the answer section in 106 a DNS message is an ordered list of RRSets, but that other sections 107 may be constructed differently, and clarifies the directions provided 108 in [RFC1034] to match the observed behaviour and expectations of 109 deployed software. 111 3. Updates to RFC 1034 113 [RFC1034] specifies the algorithms by which sections of a DNS 114 response are constructed by a responder. For example, step 3 of the 115 algorithm described in [RFC1034] section 4.3.2 contains the direction 116 "copy all RRs which match QTYPE into answer section". 118 In this case, and in all other cases where [RFC1034] specifies that 119 particular RRSets be included in the answer section of a DNS message, 120 the section MUST be treated as an ordered list of RRSets. When it is 121 necessary to include new RRSets in a section of a DNS message that is 122 under construction, those RRSets MUST be appended. The receiver of a 123 DNS message MAY refuse to process DNS messages that have been 124 constructed differently. 126 When constructing other sections of a DNS message, each section MAY 127 be treated as a non-ordered list, and a receiver of a DNS message 128 MUST NOT reject a DNS message on the basis of the order of RRSets in 129 those sections. 131 4. Updates to RFC 1035 133 In a DNS message, the answer section MUST be considered to be an 134 ordered set of RRSets; all other sections MUST be considered to be a 135 non-ordered set. 137 DNS implementations MUST construct each section in a DNS response 138 according to the algorithms specified in [RFC1034], as clarified in 139 Section 3 of this document. 141 5. Security Considerations 143 The recommendations contained in this document have no known security 144 implications. 146 6. IANA Considerations 148 This document has no IANA actions. 150 7. Acknowledgements 152 The contributions of Mark Andrews and Paul Vixie to this document are 153 acknowledged. 155 8. References 157 8.1. Normative References 159 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 160 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 161 . 163 [RFC1035] Mockapetris, P., "Domain names - implementation and 164 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 165 November 1987, . 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 169 RFC2119, March 1997, 170 . 172 8.2. Informative References 174 [I-D.ietf-dnsop-dns-terminology] 175 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 176 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 177 progress), September 2015. 179 Appendix A. Editorial Notes 181 This section (and sub-sections) to be removed prior to publication. 183 A.1. Venue 185 An appropriate forum for discussion of this draft is the dnsop 186 working group. 188 A.2. Change History 190 A.2.1. draft-jabley-dnsop-ordered-answers-00 192 Initial draft circulated for comment. 194 Author's Address 196 Joe Abley 197 Dyn, Inc. 198 103-186 Albert Street 199 London, ON N6A 1M1 200 Canada 202 Phone: +1 519 670 9327 203 Email: jabley@dyn.com