idnits 2.17.00 (12 Aug 2021) /tmp/idnits27054/draft-lenders-dns-over-coap-03.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 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) == Missing Reference: 'TBD-this-spec' is mentioned on line 439, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-ietf-add-dnr-05 == Outdated reference: A later version (-10) exists of draft-ietf-core-href-09 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: draft-ietf-dprive-dnsoquic has been published as RFC 9250 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE M. S. Lenders 3 Internet-Draft FU Berlin 4 Intended status: Standards Track C. Amsüss 5 Expires: 8 September 2022 6 C. Gündoğan 7 T. C. Schmidt 8 HAW Hamburg 9 M. Wählisch 10 FU Berlin 11 7 March 2022 13 DNS Queries over CoAP (DoC) 14 draft-lenders-dns-over-coap-03 16 Abstract 18 This document defines a protocol for sending DNS messages over the 19 Constrained Application Protocol (CoAP). These CoAP messages are 20 protected by DTLS-Secured CoAP (CoAPS) or Object Security for 21 Constrained RESTful Environments (OSCORE) to provide encrypted DNS 22 message exchange for constrained devices in the Internet of Things 23 (IoT). 25 Discussion Venues 27 This note is to be removed before publishing as an RFC. 29 Discussion of this document takes place on TODO 31 Source for this draft and an issue tracker can be found at 32 https://github.com/anr-bmbf-pivot/draft-dns-over-coap. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 8 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Selection of a DoC Server . . . . . . . . . . . . . . . . . . 4 69 4. Basic Message Exchange . . . . . . . . . . . . . . . . . . . 4 70 4.1. The "application/dns-message" Content-Format . . . . . . 5 71 4.2. DNS Queries in CoAP Requests . . . . . . . . . . . . . . 5 72 4.2.1. Request Format . . . . . . . . . . . . . . . . . . . 5 73 4.2.2. Support of CoAP Caching . . . . . . . . . . . . . . . 5 74 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 6 75 4.3. DNS Responses in CoAP Responses . . . . . . . . . . . . . 6 76 4.3.1. Response Codes and Handling DNS and CoAP errors . . . 6 77 4.3.2. Support of CoAP Caching . . . . . . . . . . . . . . . 7 78 4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 7 79 5. CoAP/CoRE Integration . . . . . . . . . . . . . . . . . . . . 8 80 5.1. DoC server considerations . . . . . . . . . . . . . . . . 8 81 5.2. Proxies and caching . . . . . . . . . . . . . . . . . . . 8 82 5.3. OBSERVE (modifications)? . . . . . . . . . . . . . . . . 9 83 5.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6. Considerations for Unencrypted Use . . . . . . . . . . . . . 9 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. New "application/dns-message" Content-Format . . . . . . 10 88 8.2. New "core.dns" Resource Type . . . . . . . . . . . . . . 10 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 9.2. Informative References . . . . . . . . . . . . . . . . . 11 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 93 A.1. Since draft-lenders-dns-over-coap-02 . . . . . . . . . . 13 94 A.2. Since draft-lenders-dns-over-coap-01 . . . . . . . . . . 13 95 A.3. Since draft-lenders-dns-over-coap-00 . . . . . . . . . . 13 96 A.4. Since draft-lenders-dns-over-coaps-00 . . . . . . . . . . 13 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 This document defines DNS over CoAP (DoC), a protocol to send DNS 103 [RFC1035] queries and get DNS responses over the Constrained 104 Application Protocol (CoAP) [RFC7252]. Each DNS query-response pair 105 is mapped into a CoAP message exchange. Each CoAP message is secured 106 by DTLS [RFC6347] or Object Security for Constrained RESTful 107 Environments (OSCORE) [RFC8613] to ensure message integrity and 108 confidentiality. 110 The application use case of DoC is inspired by DNS over HTTPS 111 [RFC8484] (DoH). DoC, however, aims for the deployment in the 112 constrained Internet of Things (IoT), which usually conflicts with 113 the requirements introduced by HTTPS. 115 To prevent TCP and HTTPS resource requirements, constrained IoT 116 devices could use DNS over DTLS [RFC8094]. In contrast to DNS over 117 DTLS, DoC utilizes CoAP features to mitigate drawbacks of datagram- 118 based communication. These features include: block-wise transfer, 119 which solves the Path MTU problem of DNS over DTLS (see [RFC8094], 120 section 5); CoAP proxies, which provide an additional level of 121 caching; re-use of data structures for application traffic and DNS 122 information, which saves memory on constrained devices. 124 To prevent resource requirements of DTLS or TLS on top of UDP (e.g., 125 introduced by DNS over QUIC [I-D.ietf-dprive-dnsoquic]), DoC allows 126 for lightweight end-to-end payload encryption based on OSCORE. 128 - FETCH coaps://[2001:db8::1]/ 129 / 130 / 131 CoAP request 132 +--------+ [DNS query] +--------+ DNS query +--------+ 133 | DoC |---------------->| DoC |...............>| DNS | 134 | Client |<----------------| Server |<...............| Server | 135 +--------+ CoAP response +--------+ DNS response +--------+ 136 [DNS response] 138 Figure 1: Basic DoC architecture 140 The most important components of DoC can be seen in Figure 1: A DoC 141 client tries to resolve DNS information by sending DNS queries 142 carried within CoAP requests to a DoC server. That DoC server may or 143 may not resolve that DNS information itself by using other DNS 144 transports with an upstream DNS server. The DoC server then replies 145 to the DNS queries with DNS responses carried within CoAP responses. 147 TBD: additional feature sets of CoAP/CoRE 149 * resource directory for DoC service discovery, 151 * ... 153 2. Terminology 155 A server that provides the service specified in this document is 156 called a "DoC server" to differentiate it from a classic "DNS 157 server". Correspondingly, a client using this protocol to retrieve 158 the DNS information is called a "DoC client". 160 The term "constrained nodes" is used as defined in [RFC7228]. 162 The terms "CoAP payload" and "CoAP body" are used as defined in 163 [RFC7959]. 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in 168 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 3. Selection of a DoC Server 173 In this document, it is assumed that the DoC client knows the DoC 174 server and the DNS resource at the DoC server. Possible options 175 could be manual configuration of a URI [RFC3986] or CRI 176 [I-D.ietf-core-href], or automatic configuration, e.g., using a CoRE 177 resource directory [I-D.ietf-core-resource-directory], DHCP or Router 178 Advertisement options [I-D.ietf-add-dnr]. Automatic configuration 179 SHOULD only be done from a trusted source. 181 When discovering the DNS resource through a link mechanism that 182 allows describing a resource type (e.g., the Resource Type Attribute 183 in [RFC6690]), the resource type "core.dns" can be used to identify a 184 generic DNS resolver that is available to the client. 186 4. Basic Message Exchange 187 4.1. The "application/dns-message" Content-Format 189 This document defines the Internet media type "application/dns- 190 message" for the CoAP Content-Format. This media type is defined as 191 in [RFC8484] Section 6, i.e., a single DNS message encoded in the DNS 192 on-the-wire format [RFC1035]. 194 4.2. DNS Queries in CoAP Requests 196 A DoC client encodes a single DNS query in one or more CoAP request 197 messages the CoAP FETCH [RFC8132] method. Requests SHOULD include an 198 Accept option to indicate the type of content that can be parsed in 199 the response. 201 To enable reliable message exchange, the CoAP request SHOULD be 202 carried in a Confirmable (CON) message. 204 4.2.1. Request Format 206 When sending a CoAP request, a DoC client MUST include the DNS query 207 in the body (i.e. the payload, or the concatenated payloads) of the 208 CoAP request. As specified in [RFC8132] Section 2.3.1, the type of 209 content of the body MUST be indicated using the Content-Format 210 option. This document specifies the usage of Content-Format 211 "application/dns-message" (details see Section 4.1). 213 If block-wise transfer [RFC7959] is supported by the client, more 214 than one CoAP request message MAY be used. If more than one CoAP 215 request message is used to encode the DNS query, it must be chained 216 together using the Block1 option in those CoAP requests. 218 The FETCH request is sent to the URI specified in Section 3. 220 A DoC server MUST be able to parse requests of Content-Format 221 "application/dns-message". 223 4.2.2. Support of CoAP Caching 225 The DoC client SHOULD set the ID field of the DNS header always to 0 226 to enable a CoAP cache (e.g., a CoAP proxy en-route) to respond to 227 the same DNS queries with a cache entry. This ensures that the CoAP 228 Cache-Key (see [RFC8132] Section 2) does not change when multiple DNS 229 queries for the same DNS data, carried in CoAP requests, are issued. 231 4.2.3. Examples 233 The following example illustrates the usage of a CoAP message to 234 resolve "example.org. IN AAAA" based on the URI 235 "coaps://[2001:db8::1]/". The CoAP body is encoded in "application/ 236 dns-message" Content Format. 238 FETCH coaps://[2001:db8::1]/ 239 Content-Format: application/dns-message 240 Accept: application/dns-message 241 Payload: 00 00 01 20 00 02 00 00 00 00 00 00 07 65 78 61 [binary] 242 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 243 01 00 01 [binary] 245 4.3. DNS Responses in CoAP Responses 247 Each DNS query-response pair is mapped to a CoAP REST request- 248 response operation, which may consist of several CoAP request- 249 response pairs if block-wise transfer is involved. DNS responses are 250 provided in the body (i.e. the payload, or the concatenated payloads) 251 of the CoAP response. A DoC server MUST indicate the type of content 252 of the body using the Content-Format option, and MUST be able to 253 produce responses in the "application/dns-message" Content-Format 254 (details see Section 4.1) when requested. A DoC client MUST 255 understand responses in "application/dns-message" format when it does 256 not send an Accept option. 258 If supported, a DoC server MAY transfer the DNS response in more than 259 one CoAP responses using the Block2 option [RFC7959]. 261 4.3.1. Response Codes and Handling DNS and CoAP errors 263 A DNS response indicates either success or failure in the Response 264 code of the DNS header (see [RFC1035] Section 4.1.1). It is 265 RECOMMENDED that CoAP responses that carry any valid DNS response use 266 a "2.05 Content" response code. 268 CoAP responses use non-successful response codes MUST NOT contain any 269 payload and may only be used on errors in the CoAP layer or when a 270 request does not fulfill the requirements of the DoC protocol. 272 Communication errors with a DNS server (e.g., timeouts) SHOULD be 273 indicated by including a SERVFAIL DNS response in a successful CoAP 274 response. 276 A DoC client might try to repeat a non-successful exchange unless 277 otherwise prohibited. The DoC client might also decide to repeat a 278 non-successful exchange with a different URI, for instance, when the 279 response indicates an unsupported Content-Format. 281 4.3.2. Support of CoAP Caching 283 It is RECOMMENDED to set the Max-Age option of a response to the 284 minimum TTL in the Answer section of a DNS response. This prevents 285 expired records unintentionally being served from a CoAP cache. 287 It is RECOMMENDED that DoC servers set an ETag option on large 288 responses (TBD: more concrete guidance) that have a short Max-Age 289 relative to the expected clients' caching time. Thus, clients that 290 need to revalidate a response can do so using the established ETag 291 mechanism. With responses large enough to be fragmented, it's best 292 practice for servers to set an ETag anyway. As specified in 293 [RFC7252] and [RFC8132], if the response associated with the ETag is 294 still valid, the response uses the "2.03 Valid" code and consequently 295 carries no payload. 297 4.3.3. Examples 299 The following examples illustrate the replies to the query 300 "example.org. IN AAAA record", recursion turned on. Successful 301 responses carry one answer record including address 302 2001:db8:1::1:2:3:4 and TTL 58719. 304 A successful response: 306 2.05 Content 307 Content-Format: application/dns-message 308 Max-Age: 58719 309 Payload: 00 00 81 a0 00 01 00 01 00 00 00 00 07 65 78 61 [binary] 310 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 311 1c 00 01 00 01 37 49 00 10 20 01 0d b8 00 01 00 [binary] 312 00 00 01 00 02 00 03 00 04 [binary] 314 When a DNS error (SERVFAIL in this case) is noted in the DNS 315 response, the CoAP response still indicates success: 317 2.05 Content 318 Content-Format: application/dns-message 319 Payload: 00 00 81 a2 00 01 00 00 00 00 00 00 07 65 78 61 [binary] 320 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 [binary] 322 When an error occurs on the CoAP layer, the DoC server SHOULD respond 323 with an appropriate CoAP error, for instance "4.15 Unsupported 324 Content-Format" if the Content-Format option in the request was not 325 set to "application/dns-message" and the Content-Format is not 326 otherwise supported by the server. 328 5. CoAP/CoRE Integration 330 5.1. DoC server considerations 332 In the case of CNAME records in a DNS response, a DoC server SHOULD 333 follow common DNS resolver behavior [RFC1034] by resolving a CNAME 334 until the originally requested resource record type is reached. This 335 reduces the number of message exchanges within an LLN. 337 The DoC server SHOULD send compact answers, i.e., additional or 338 authority sections in the DNS response should only be sent if needed 339 or if it is anticipated that they help the DoC client to reduce 340 additional queries. 342 5.2. Proxies and caching 344 TBD: 346 * TTL vs. Max-Age (https://github.com/anr-bmbf-pivot/draft-dns-over- 347 coap/issues/5) 349 * Responses that are not globally valid 351 * General CoAP proxy problem, but what to do when DoC server is a 352 DNS proxy, response came not yet in but retransmission by DoC 353 client was received (see Figure 2) 355 - send empty ACK (maybe move to best practices appendix 356 (https://github.com/anr-bmbf-pivot/draft-dns-over-coap/ 357 issues/6#issuecomment-895880206)) 359 DoC client DoC proxy DNS server 360 | CoAP req [rt 1] | | 361 |------------------>| DNS query [rt 1] | 362 | |------------------->| 363 | CoAP req [rt 2] | | 364 |------------------>| DNS resp | 365 | CoAP resp |<-------------------| 366 |<------------------| | 367 | | | 369 Figure 2: CoAP retransmission (rt) is received before DNS 370 query could have been fulfilled. 372 5.3. OBSERVE (modifications)? 374 * TBD 376 * DoH has considerations on Server Push to deliver additional, 377 potentially outstanding requests + response to the DoC client for 378 caching 380 * OBSERVE does not include the request it would have been generated 381 from ==> cannot be cached without corresponding request having 382 been send over the wire. 384 * If use case exists: extend OBSERVE with option that contains 385 "promised" request (see [RFC7540], section 8.2)? 387 * Other caveat: clients can't cache, only proxys so value needs to 388 be evaluated 390 * Potential use case: [RFC8490] Section 4.1.2 392 5.4. OSCORE 394 * TBD 396 * With OSCORE DTLS might not be required 398 6. Considerations for Unencrypted Use 400 While not recommended, DoC can be used without any encryption (e.g., 401 in very constrained environments where encryption is not possible or 402 necessary). It can also be used when lower layers provide secure 403 communication between client and server. In both cases, potential 404 benefits of unencrypted DoC usage over classic DNS are e.g. block- 405 wise transfer or alternative CoAP Content-Formats to overcome link- 406 layer constraints. 408 7. Security Considerations 410 TODO Security 412 8. IANA Considerations 413 8.1. New "application/dns-message" Content-Format 415 IANA is requested to assign CoAP Content-Format ID for the DNS 416 message media type in the "CoAP Content-Formats" sub-registry, within 417 the "CoRE Parameters" registry [RFC7252], corresponding the 418 "application/dns-message" media type from the "Media Types" registry: 420 Media-Type: application/dns-message 422 Encoding: - 424 Id: TBD 426 Reference: [TBD-this-spec] 428 8.2. New "core.dns" Resource Type 430 IANA is requested to assign a new Resource Type (rt=) Link Target 431 Attribute, "core.dns" in the "Resource Type (rt=) Link Target 432 Attribute Values" sub-registry, within the "CoRE Parameters" register 433 [RFC6690]. 435 Attribute Value: core.dns 437 Description: DNS over CoAP resource. 439 Reference: [TBD-this-spec] Section 3 441 9. References 443 9.1. Normative References 445 [RFC1035] Mockapetris, P., "Domain names - implementation and 446 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 447 November 1987, . 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 455 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 456 January 2012, . 458 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 459 Application Protocol (CoAP)", RFC 7252, 460 DOI 10.17487/RFC7252, June 2014, 461 . 463 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 464 the Constrained Application Protocol (CoAP)", RFC 7959, 465 DOI 10.17487/RFC7959, August 2016, 466 . 468 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 469 FETCH Methods for the Constrained Application Protocol 470 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 471 . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 478 "Object Security for Constrained RESTful Environments 479 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 480 . 482 9.2. Informative References 484 [I-D.ietf-add-dnr] 485 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 486 Jensen, "DHCP and Router Advertisement Options for the 487 Discovery of Network-designated Resolvers (DNR)", Work in 488 Progress, Internet-Draft, draft-ietf-add-dnr-05, 13 489 December 2021, . 492 [I-D.ietf-core-href] 493 Bormann, C. and H. Birkholz, "Constrained Resource 494 Identifiers", Work in Progress, Internet-Draft, draft- 495 ietf-core-href-09, 15 January 2022, 496 . 499 [I-D.ietf-core-resource-directory] 500 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 501 D. Stok, "CoRE Resource Directory", Work in Progress, 502 Internet-Draft, draft-ietf-core-resource-directory-28, 7 503 March 2021, . 506 [I-D.ietf-dprive-dnsoquic] 507 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 508 Dedicated QUIC Connections", Work in Progress, Internet- 509 Draft, draft-ietf-dprive-dnsoquic-10, 28 February 2022, 510 . 513 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 514 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 515 . 517 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 518 Resource Identifier (URI): Generic Syntax", STD 66, 519 RFC 3986, DOI 10.17487/RFC3986, January 2005, 520 . 522 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 523 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 524 . 526 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 527 Constrained-Node Networks", RFC 7228, 528 DOI 10.17487/RFC7228, May 2014, 529 . 531 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 532 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 533 DOI 10.17487/RFC7540, May 2015, 534 . 536 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 537 Transport Layer Security (DTLS)", RFC 8094, 538 DOI 10.17487/RFC8094, February 2017, 539 . 541 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 542 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 543 . 545 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 546 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 547 RFC 8490, DOI 10.17487/RFC8490, March 2019, 548 . 550 Appendix A. Change Log 552 TBD: 554 * Request text duplication (https://github.com/anr-bmbf-pivot/draft- 555 dns-over-coap/issues/4) 557 A.1. Since draft-lenders-dns-over-coap-02 558 (https://datatracker.ietf.org/doc/html/draft-lenders-dns-over- 559 coap-02) 561 * Clarify server selection to be out-of-band and define "core.dns" 562 resource type in Section 3 and Section 8.2 564 * Add message manipulation considerations for DoC servers in 565 Section 5.1 567 * Update Considerations for Unencrypted Use in Section 6 569 A.2. Since draft-lenders-dns-over-coap-01 570 (https://datatracker.ietf.org/doc/html/draft-lenders-dns-over- 571 coap-01) 573 * Remove GET and POST methods 575 * Add note on ETag and response codes 577 * Provide requirement conflict for DNS over QUIC 579 * Clarify Content-Format / Accept handling 581 A.3. Since draft-lenders-dns-over-coap-00 582 (https://datatracker.ietf.org/doc/html/draft-lenders-dns-over- 583 coap-00) 585 * Soften Content-Format requirements in Section 4.2.1 and 586 Section 4.3 588 * Clarify "CoAP payload"/"CoAP body" terminology 590 * Fix nits and typos 592 A.4. Since draft-lenders-dns-over-coaps-00 593 (https://datatracker.ietf.org/doc/html/draft-lenders-dns-over- 594 coaps-00) 596 * Clarification in abstract that both DTLS and OSCORE can be used as 597 secure transport 599 * Restructuring of Section 4: 601 - Add dedicated Section 4.1 on Content-Format 602 - Add overview table about usable and required features for 603 request method types to Section 4.2 605 - Add dedicated Section 4.2.2 and Section 4.3.2 on caching 606 requirements for CoAP requests and responses 608 * Fix nits and typos 610 Acknowledgments 612 TODO acknowledge. 614 Authors' Addresses 616 Martine Sophie Lenders 617 Freie Universität Berlin 618 Email: m.lenders@fu-berlin.de 620 Christian Amsüss 621 Email: christian@amsuess.com 623 Cenk Gündoğan 624 HAW Hamburg 625 Email: cenk.guendogan@haw-hamburg.de 627 Thomas C. Schmidt 628 HAW Hamburg 629 Email: t.schmidt@haw-hamburg.de 631 Matthias Wählisch 632 Freie Universität Berlin 633 Email: m.waehlisch@fu-berlin.de