idnits 2.17.1 draft-ietf-dnsop-rrserial-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 April 2022) is 749 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Salgado 3 Internet-Draft NIC Chile 4 Intended status: Informational M. Vergara Ereche 5 Expires: 8 October 2022 ICANN 6 6 April 2022 8 The "RRSERIAL" EDNS option for the SOA serial of a RR's zone 9 draft-ietf-dnsop-rrserial-01 11 Abstract 13 The "RRSERIAL" EDNS option allows a DNS querier to request a DNS 14 authoritative server to add an EDNS option in the answer of such 15 query with the SOA serial number field of the origin zone which 16 contains the answered Resource Record. 18 This "RRSERIAL" data allows to debug and diagnose problems by helping 19 to recognize the data source of an answer in an atomic single query, 20 by associating the response with a respective zone version. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 8 October 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. The RRSERIAL Option . . . . . . . . . . . . . . . . . . . . . 3 58 3. RRSERIAL Processing . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Responder . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Example usage . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6.1. DNS EDNS0 Option Code Registration . . . . . . . . . . . 4 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 9. Informative References . . . . . . . . . . . . . . . . . . . 5 68 Appendix A. Implementation References . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The "RRSERIAL" EDNS option [RFC6891] allows a DNS querier to request 74 to a DNS authoritative server to add an EDNS option in the answer of 75 such query with the SOA serial number field of the zone associated to 76 the answered Resource Record. 78 This "RRSERIAL" data allows to help debug by recognizing the data 79 source of an answer, associating this answer with a respective zone 80 version. 82 DNS data is of loose coherent nature, meaning that a record obtained 83 by a response could be out-of-sync with other authoritative sources 84 of the same data. This makes it difficult to debug responses, 85 because you'd need to couple an answer with the same version of the 86 zone used to obtain such data. Even when you could use a separate 87 query to ask for the SOA RR of the zone and therefore know its SOA 88 serial, such separate query is performed in a different time and 89 could arrive from another authoritative source (for example, in the 90 case the server is anycasted as described in Section 4.9 of 91 [RFC4786]), so it's not directly correlated with the original query. 93 This EDNS option is aimed to be used only on authoritative servers 94 for a zone. It's intended for hop-to-hop communication (not 95 transitive). Resolver and forwarder behavior is undefined. 97 The RRSERIAL EDNS extension doesn't offer much relevance for zones 98 served by an Authoritative server that don't use the SOA serial 99 versioning as a meaning to its content. There are cases where 100 nameservers use different backends for its data sources, like 101 relational databases or by using a different off-DNS synchronicity. 102 In such cases this extension has no benefit or utility to use in 103 debugging or analysis of a response. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. The RRSERIAL Option 113 The OPTION-CODE for the RRSERIAL option is . 115 The OPTION-DATA for the RRSERIAL option is an unsigned 32 bit version 116 number as defined in the SERIAL field of the "SOA RDATA Format" in 117 Section 3.3.13 of [RFC1035]. 119 The OPTION-LENGTH for the RRSERIAL option MUST have a value of 0 for 120 queries, and MUST have a value of 4 for responses. 122 3. RRSERIAL Processing 124 3.1. Initiator 126 The EDNS RRSERIAL option MAY be included on any QUERY, by adding a 127 zero-length EDNS RRSERIAL option to the options field of the OPT 128 record when the query is made. 130 3.2. Responder 132 If an EDNS RRSERIAL option is sent to a server that is Authoritative 133 for the zone queried, and the RCODE for the answer is NOERROR, a name 134 server that understands the RRSERIAL option and chooses to honor a 135 particular RRSERIAL request, MUST put in the OPTION-DATA a copy of 136 the serial field from the SOA Resource Record of the zone which 137 contains the original QNAME of the reply (as per Section 4 of 138 [RFC8499]). 140 In the case of a SERVFAIL RCODE the responder MAY include the 141 RRSERIAL EDNS option if the QNAME still belongs to an authoritative 142 zone of the server, in which case that serial MUST be the one 143 included in the answer. 145 Otherwise, the answer MUST NOT add an EDNS RRSERIAL option to the 146 response. 148 Note that a NODATA response code as defined in Section 3 of [RFC8499] 149 MUST also include the RRSERIAL answer as declared before even when 150 there's no ANSWER data for the QNAME, as the RCODE corresponds to 151 NOERROR. 153 4. Example usage 155 $ dig @ns.example.com www.example.com AAAA +rrserial +norec +nocmd 157 ; (1 server found) 158 ;; global options: +cmd 159 ;; Got answer: 160 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16429 161 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 163 ;; OPT PSEUDOSECTION: 164 ; EDNS: version: 0, flags:; udp: 4096 165 ; RRSERIAL: 2019073001 166 ;; QUESTION SECTION: 167 ;www.example.com. IN AAAA 169 ;; ANSWER SECTION: 170 www.example.com. 900 IN AAAA 172 ;; Query time: 53 msec 173 ;; SERVER: ns.example.com#53(2001:DB8::53) 174 ;; WHEN: Tue Aug 07 16:54:05 -04 2018 175 ;; MSG SIZE rcvd: 71 177 Figure 1 179 5. Acknowledgements 181 The authors thanks all the comments and support made in the DNSOPS 182 mailing list, chats and discussions. 184 6. IANA Considerations 186 6.1. DNS EDNS0 Option Code Registration 188 Request to IANA for a code point registration for "RRSERIAL" option. 190 7. Security Considerations 192 The EDNS extension data it's not covered by RRSIG records, so there's 193 no way to verify its authenticity nor integrity using DNSSEC and 194 could theoricatelly be tampered by a person-in-the-middle if the 195 transport is made by unsecure means. Caution should be taken to use 196 the EDNS RRSERIAL data for any means besides troubleshooting and 197 debugging. If there's a need to certify the RRSERIAL trustwortiness, 198 it will be necessary to use an encrypted and authenticated DNS 199 transport. If there's a need to authenticate data origin for the 200 RRSERIAL value, it should be compared to a separate regular SOA query 201 with DO flag, whose answer shall be DNSSEC signed, with the cautions 202 about Anycast and others as already stated in Introduction. 204 There's no risk on disclosure of private information, as the SERIAL 205 of the SOA record is already publicly available. 207 8. Normative References 209 [RFC1035] Mockapetris, P., "Domain names - implementation and 210 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 211 November 1987, . 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, 216 . 218 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 219 for DNS (EDNS(0))", STD 75, RFC 6891, 220 DOI 10.17487/RFC6891, April 2013, 221 . 223 9. Informative References 225 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 226 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 227 December 2006, . 229 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 230 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 231 January 2019, . 233 Appendix A. Implementation References 235 There's a patched NSD server 4.1.23 with support for RRSERIAL with 236 the experimental opcode 65024 maintained in 237 https://github.com/huguei/nsd/tree/rrserial , and installed for live 238 testing in 200.1.122.30 address with configured zones 239 dateserial.example.com. and incserial.example.com.; with MX, TXT and 240 AAAA apex records. 242 Authors' Addresses 244 Hugo Salgado 245 NIC Chile 246 Miraflores 222, piso 14 247 CP 8320198 Santiago 248 Chile 249 Phone: +56 2 29407700 250 Email: hsalgado@nic.cl 252 Mauricio Vergara Ereche 253 ICANN 254 Email: mauricio.vergara@icann.org