idnits 2.17.1 draft-lenders-dns-over-coap-01.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 -(561): 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (1 September 2021) is 965 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 492, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-15) exists of draft-ietf-core-href-06 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: 5 March 2022 6 C. Gündoğan 7 T.C. Schmidt 8 HAW Hamburg 9 M. Wählisch 10 FU Berlin 11 1 September 2021 13 DNS Queries over CoAP (DoC) 14 draft-lenders-dns-over-coap-01 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 5 March 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Selection of a DoC Server . . . . . . . . . . . . . . . . . . 4 69 3.1. URI Template Alternatives . . . . . . . . . . . . . . . . 4 70 4. Basic Message Exchange . . . . . . . . . . . . . . . . . . . 4 71 4.1. The "application/dns-message" Content-Format . . . . . . 4 72 4.2. DNS Queries in CoAP Requests . . . . . . . . . . . . . . 5 73 4.2.1. CoAP Methods . . . . . . . . . . . . . . . . . . . . 5 74 4.2.2. Support of CoAP Caching . . . . . . . . . . . . . . . 6 75 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 6 76 4.3. DNS Responses in CoAP Responses . . . . . . . . . . . . . 7 77 4.3.1. Response Codes and Handling DNS and CoAP errors . . . 7 78 4.3.2. Support of CoAP Caching . . . . . . . . . . . . . . . 8 79 4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 8 80 5. CoAP/CoRE Integration . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Proxies and caching . . . . . . . . . . . . . . . . . . . 9 82 5.2. OBSERVE (modifications)? . . . . . . . . . . . . . . . . 10 83 5.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 6. URI template configuration . . . . . . . . . . . . . . . . . 10 85 7. Considerations for Unencrypted Use . . . . . . . . . . . . . 11 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 10.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 92 A.1. Since draft-lenders-dns-over-coap-00 . . . . . . . . . . 14 93 A.2. Since draft-lenders-dns-over-coaps-00 . . . . . . . . . . 14 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 This document defines DNS over CoAP (DoC), a protocol to send DNS 100 [RFC1035] queries and get DNS responses over the Constrained 101 Application Protocol (CoAP) [RFC7252]. Each DNS query-response pair 102 is mapped into a CoAP message exchange. Each CoAP message is secured 103 by DTLS [RFC6347] or Object Security for Constrained RESTful 104 Environments (OSCORE) [RFC8613] to ensure message integrity and 105 confidentiality. 107 The application use case of DoC is inspired by DNS over HTTPS 108 [RFC8484] (DoH). DoC, however, aims for the deployment in the 109 constrained Internet of Things (IoT), which usually conflicts with 110 the requirements introduced by HTTPS. 112 To prevent TCP and HTTPS resource requirements, constrained IoT 113 devices could use DNS over DTLS [RFC8094]. In contrast to DNS over 114 DTLS, DoC utilizes CoAP features to mitigate drawbacks of datagram- 115 based communication. These features include: block-wise transfer, 116 which solves the Path MTU problem of DNS over DTLS (see [RFC8094], 117 section 5); CoAP proxies, which provide an additional level of 118 caching; re-use of data structures for application traffic and DNS 119 information, which saves memory on constrained devices. 121 - GET coaps://[2001:db8::1]/?dns=example.org 122 /- POST/FETCH coaps://[2001:db8::1]/ 123 / 124 CoAP request 125 +--------+ [DNS query] +--------+ DNS query +--------+ 126 | DoC |---------------->| DoC |...............>| DNS | 127 | Client |<----------------| Server |<...............| Server | 128 +--------+ CoAP response +--------+ DNS response +--------+ 129 [DNS response] 131 Figure 1: Basic DoC architecture 133 The most important components of DoC can be seen in Figure 1: A DoC 134 client tries to resolve DNS information by sending DNS queries 135 carried within CoAP requests to a DoC server. That DoC server may or 136 may not resolve that DNS information itself by using other DNS 137 transports with an upstream DNS server. The DoC server then replies 138 to the DNS queries with DNS responses carried within CoAP responses. 140 TBD: additional feature sets of CoAP/CoRE 142 * resource directory for DoC service discovery, 144 * ... 146 2. Terminology 148 A server that provides the service specified in this document is 149 called a "DoC server" to differentiate it from a classic "DNS 150 server". Correspondingly, a client using this protocol to retrieve 151 the DNS information is called a "DoC client". 153 The term "constrained nodes" is used as defined in [RFC7228]. 155 The terms "CoAP payload" and "CoAP body" are used as defined in 156 [RFC7959]. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 3. Selection of a DoC Server 166 A DoC client is configured with a URI Template [RFC6570]. This 167 allows us to reuse configuration mechanisms provided for DoH. 169 The URI Template SHOULD provide a variable "dns" so that GET requests 170 can be used to retrieve the DNS information. If the "dns" variable 171 is not provided in the URI Template, GET requests can not be used for 172 DoC exchanges. 174 TBD: 176 * Support for more than one URI Template by DoC server. 178 * DoC server identity, key exchange, ... 180 3.1. URI Template Alternatives 182 TBD: 184 * CRI [I-D.ietf-core-href] or CoRAL [I-D.ietf-core-coral] 186 4. Basic Message Exchange 188 4.1. The "application/dns-message" Content-Format 190 This document defines the Internet media type "application/dns- 191 message" for the CoAP Content-Format. This media type is defined as 192 in [RFC8484] Section 6, i.e., a single DNS message encoded in the DNS 193 on-the-wire format [RFC1035]. 195 4.2. DNS Queries in CoAP Requests 197 A DoC client encodes a single DNS query in one or more CoAP request 198 messages using either the CoAP GET [RFC7252], POST [RFC7252], or 199 FETCH [RFC8132] methods. Requests of either method type SHOULD 200 include an Accept option to indicate the type of content that can be 201 parsed in the response. A client MUST be able to parse messages of 202 Content-Format "application/dns-message" regardless of the provided 203 Accept option. 205 To enable reliable message exchange, the CoAP request SHOULD be 206 carried in a Confirmable (CON) message. 208 4.2.1. CoAP Methods 210 When sending a CoAP request using the POST or FETCH method, a DoC 211 client MUST include the DNS query in the body (i.e. the payload, or 212 the concatenated payloads) of the CoAP request. The type of content 213 of the body MUST be indicated using the Content-Format option. This 214 document specifies the usage of Content-Format "application/dns- 215 message" (details see Section 4.1). 217 If the FETCH or POST method are used and block-wise transfer 218 [RFC7959] is supported by the client, more than one CoAP request 219 message MAY be used. If more than one CoAP request message is used 220 to encode the DNS query, it must be chained together using the Block1 221 option in those CoAP requests. 223 For a POST or FETCH request the URI Template specified in Section 3 224 is processed without any variables set. 226 When sending a CoAP request using the GET method, the URI Template 227 specified in Section 3 is extended by the variable "dns". A DoC 228 client MUST use the "dns" variable in the URI-Query followed by the 229 DNS query encoded with "base64url" (details see [RFC8484] Section 6). 230 If new Content-Formats are specified in the future, the specification 231 MUST define the variable used in the URI Template with that new 232 format. 234 A DoC client must implement the GET, POST, or FETCH method. Due to 235 the lack of "base64url" encoding requirements, both FETCH and POST 236 methods are generally smaller than GET requests. Using the FETCH 237 method is RECOMMENDED because this method provides caching and block- 238 wise transfer without introducing the overhead of URI templates (see 239 Table 1). 241 +========+===========+=========================+=================+ 242 | Method | Cacheable | Block-wise transferable | No URI Template | 243 | | | | variable needed | 244 +========+===========+=========================+=================+ 245 | GET | Y | N | N | 246 +--------+-----------+-------------------------+-----------------+ 247 | POST | N | Y | Y | 248 +--------+-----------+-------------------------+-----------------+ 249 | FETCH | Y | Y | Y | 250 +--------+-----------+-------------------------+-----------------+ 252 Table 1: Comparison of CoAP method features (Y: Yes, N: No) 254 A DoC server MUST implement the GET, POST, and FETCH method. A DoC 255 server MUST be able to parse requests of Content-Format "application/ 256 dns-message". 258 4.2.2. Support of CoAP Caching 260 The DoC client SHOULD set the ID field of the DNS header always to 0 261 to enable a CoAP cache (e.g., a CoAP proxy en-route) to respond to 262 the same DNS queries with a cache entry. This ensures that the CoAP 263 Cache-Key (for GET see [RFC7252] Section 5.6, for FETCH see [RFC8132] 264 Section 2) does not change when multiple DNS queries for the same DNS 265 data, carried in CoAP requests, are issued. Technically, using the 266 POST method does not require the DNS ID set to 0 because the payload 267 of a POST message is not part of the Cache-Key. For consistency 268 reasons, however, it is RECOMMENDED to use the same constant DNS ID. 270 4.2.3. Examples 272 The following examples illustrate the usage of different CoAP 273 messages to resolve "example.org. IN AAAA" based on the URI template 274 "coaps://[2001:db8::1]/{?dns}". The CoAP body is encoded in 275 "application/dns-message" Content-Format. 277 GET request: 279 GET coaps://[2001:db8::1]/ 280 URI-Query: dns=AAABIAABAAAAAAAAB2V4YW1wbGUDb3JnAAAcAAE 281 Accept: application/dns-message 283 POST request: 285 POST coaps://[2001:db8::1]/ 286 Content-Format: application/dns-message 287 Accept: application/dns-message 288 Payload: 00 00 01 20 00 02 00 00 00 00 00 00 07 65 78 61 [binary] 289 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 290 01 00 01 [binary] 292 FETCH request: 294 FETCH coaps://[2001:db8::1]/ 295 Content-Format: application/dns-message 296 Accept: application/dns-message 297 Payload: 00 00 01 20 00 02 00 00 00 00 00 00 07 65 78 61 [binary] 298 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 299 01 00 01 [binary] 301 4.3. DNS Responses in CoAP Responses 303 Each DNS query-response pair is mapped to a CoAP REST request- 304 response operation, which may consist of several CoAP request- 305 response pairs if block-wise transfer is involved. DNS responses are 306 provided in the body (i.e. the payload, or the concatenated payloads) 307 of the CoAP response. A DoC server MUST indicate the type of content 308 of the body using the Content-Format option. This document specifies 309 the usage of Content-Format "application/dns-message" (details see 310 Section 4.1). 312 If supported, a DoC server MAY transfer the DNS response in more than 313 one CoAP responses using the Block2 option [RFC7959]. 315 4.3.1. Response Codes and Handling DNS and CoAP errors 317 A DNS response indicates either success or failure in the Response 318 code of the DNS header (see [RFC1035] Section 4.1.1). It is 319 RECOMMENDED that CoAP responses that carry any valid DNS response use 320 a "2.xx Success" response code. A response to a GET or FETCH request 321 SHOULD use the "2.05 Content" code. A response to a POST request 322 SHOULD use the "2.01 Created" code. 324 CoAP responses use non-successful response codes MUST NOT contain any 325 payload and may only be used on errors in the CoAP layer or when a 326 request does not fulfill the requirements of the DoC protocol. 328 Communication errors with a DNS server (e.g., timeouts) SHOULD be 329 indicated by including a SERVFAIL DNS response in a successful CoAP 330 response. 332 A DoC client might try to repeat a non-successful exchange unless 333 otherwise prohibited. For instance, a FETCH request MUST NOT be 334 repeated with a URI Template for which the DoC server already 335 responded with "4.05 Method Not Allowed" since the server might only 336 implement legacy CoAP and does not support the FETCH method. The DoC 337 client might also decide to repeat a non-successful exchange with a 338 different URI Template, for instance, when the response indicates an 339 unsupported Content-Format. 341 4.3.2. Support of CoAP Caching 343 It is RECOMMENDED to set the Max-Age option of a response to the 344 minimum TTL in the Answer section of a DNS response. This prevents 345 expired records unintentionally being served from a CoAP cache. 347 It is RECOMMENDED that DoC servers set an ETag option on large 348 responses (TBD: more concrete guidance) that have a short Max-Age 349 relative to the expected clients' caching time. Thus, clients that 350 need to revalidate a response can do so using the established ETag 351 mechanism. With responses large enough to be fragmented, it's best 352 practice for servers to set an ETag anyway. 354 4.3.3. Examples 356 The following examples illustrate the replies to the query 357 "example.org. IN AAAA record", recursion turned on. Successful 358 responses carry one answer record including address 359 2001:db8:1::1:2:3:4 and TTL 58719. 361 A successful response to a GET or FETCH request: 363 2.05 Content 364 Content-Format: application/dns-message 365 Max-Age: 58719 366 Payload: 00 00 81 a0 00 01 00 01 00 00 00 00 07 65 78 61 [binary] 367 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 368 1c 00 01 00 01 37 49 00 10 20 01 0d b8 00 01 00 [binary] 369 00 00 01 00 02 00 03 00 04 [binary] 371 A successful response to a POST request uses a different response 372 code: 374 2.03 Created 375 Content-Format: application/dns-message 376 Max-Age: 58719 377 Payload: 00 00 81 a0 00 01 00 01 00 00 00 00 07 65 78 61 [binary] 378 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 379 1c 00 01 00 01 37 49 00 10 20 01 0d b8 00 01 00 [binary] 380 00 00 01 00 02 00 03 00 04 [binary] 382 When a DNS error (SERVFAIL in this case) is noted in the DNS 383 response, the CoAP request still indicates success: 385 2.05 Content 386 Content-Format: application/dns-message 387 Payload: 00 00 81 a2 00 01 00 00 00 00 00 00 07 65 78 61 [binary] 388 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 [binary] 390 When an error occurs on the CoAP layer, the DoC server SHOULD respond 391 with an appropriate CoAP error, for instance "4.15 Unsupported 392 Content-Format" if the Content-Format option in the request was not 393 set to "application/dns-message" and the Content-Format is not 394 otherwise supported by the server. 396 5. CoAP/CoRE Integration 398 5.1. Proxies and caching 400 TBD: 402 * TTL vs. Max-Age (https://github.com/anr-bmbf-pivot/draft-dns-over- 403 coap/issues/5) 405 * Responses that are not globally valid 407 * General CoAP proxy problem, but what to do when DoC server is a 408 DNS proxy, response came not yet in but retransmission by DoC 409 client was received (see Figure 2) 411 - send empty ACK (maybe move to best practices appendix 412 (https://github.com/anr-bmbf-pivot/draft-dns-over-coap/ 413 issues/6#issuecomment-895880206)) 414 DoC client DoC proxy DNS server 415 | CoAP req [rt 1] | | 416 |------------------>| DNS query [rt 1] | 417 | |------------------->| 418 | CoAP req [rt 2] | | 419 |------------------>| DNS resp | 420 | CoAP resp |<-------------------| 421 |<------------------| | 422 | | | 424 Figure 2: CoAP retransmission (rt) is received before DNS 425 query could have been fulfilled. 427 5.2. OBSERVE (modifications)? 429 * TBD 431 * DoH has considerations on Server Push to deliver additional, 432 potentially outstanding requests + response to the DoC client for 433 caching 435 * OBSERVE does not include the request it would have been generated 436 from ==> cannot be cached without corresponding request having 437 been send over the wire. 439 * If use case exists: extend OBSERVE with option that contains 440 "promised" request (see [RFC7540], section 8.2)? 442 * Other caveat: clients can't cache, only proxys so value needs to 443 be evaluated 445 * Potential use case: [RFC8490] Section 4.1.2 447 5.3. OSCORE 449 * TBD 451 * With OSCORE DTLS might not be required 453 6. URI template configuration 455 * TBD 457 * Maybe out-of-scope? 459 * DHCP and RA options to deliver? [I-D.peterson-doh-dhcp] 460 * CoRE-RD [I-D.ietf-core-resource-directory] (...; can not express 461 URI templates) 463 * When no actual templating is involved: regular resource discovery 464 ("rt=core.dns"?) through .well-known/core 466 7. Considerations for Unencrypted Use 468 * TBD 470 * DTLS-transport should be used 472 * Non-DTLS can have benefits: Blockwise-transfer for IEEE 802.15.4, 473 additional layer of caching, ... 475 8. Security Considerations 477 TODO Security 479 9. IANA Considerations 481 IANA is requested to assign CoAP Content-Format ID for the DNS 482 message media type in the "CoAP Content-Formats" sub-registry, within 483 the "CoRE Parameters" registry [RFC7252], corresponding the 484 "application/dns-message" media type from the "Media Types" registry: 486 Media-Type: application/dns-message 488 Encoding: - 490 Id: TBD 492 Reference: [TBD-this-spec] 494 10. References 496 10.1. Normative References 498 [RFC1035] Mockapetris, P., "Domain names - implementation and 499 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 500 November 1987, . 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 508 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 509 January 2012, . 511 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 512 and D. Orchard, "URI Template", RFC 6570, 513 DOI 10.17487/RFC6570, March 2012, 514 . 516 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 517 Application Protocol (CoAP)", RFC 7252, 518 DOI 10.17487/RFC7252, June 2014, 519 . 521 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 522 the Constrained Application Protocol (CoAP)", RFC 7959, 523 DOI 10.17487/RFC7959, August 2016, 524 . 526 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 527 FETCH Methods for the Constrained Application Protocol 528 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 529 . 531 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 532 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 533 May 2017, . 535 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 536 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 537 . 539 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 540 "Object Security for Constrained RESTful Environments 541 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 542 . 544 10.2. Informative References 546 [I-D.ietf-core-coral] 547 Hartke, K., "The Constrained RESTful Application Language 548 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 549 core-coral-03, 9 March 2020, 550 . 553 [I-D.ietf-core-href] 554 Bormann, C. and H. Birkholz, "Constrained Resource 555 Identifiers", Work in Progress, Internet-Draft, draft- 556 ietf-core-href-06, 25 July 2021, 557 . 560 [I-D.ietf-core-resource-directory] 561 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 562 D. Stok, "CoRE Resource Directory", Work in Progress, 563 Internet-Draft, draft-ietf-core-resource-directory-28, 7 564 March 2021, . 567 [I-D.peterson-doh-dhcp] 568 Peterson, T., "DNS over HTTP resolver announcement Using 569 DHCP or Router Advertisements", Work in Progress, 570 Internet-Draft, draft-peterson-doh-dhcp-01, 21 October 571 2019, . 574 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 575 Constrained-Node Networks", RFC 7228, 576 DOI 10.17487/RFC7228, May 2014, 577 . 579 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 580 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 581 DOI 10.17487/RFC7540, May 2015, 582 . 584 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 585 Transport Layer Security (DTLS)", RFC 8094, 586 DOI 10.17487/RFC8094, February 2017, 587 . 589 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 590 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 591 RFC 8490, DOI 10.17487/RFC8490, March 2019, 592 . 594 Appendix A. Change Log 596 TBD: 598 * Reconsider usage of GET/POST (https://github.com/anr-bmbf-pivot/ 599 draft-dns-over-coap/issues/2)? 601 * Request text duplication (https://github.com/anr-bmbf-pivot/draft- 602 dns-over-coap/issues/4) 604 A.1. Since draft-lenders-dns-over-coap-00 605 (https://datatracker.ietf.org/doc/html/draft-lenders-dns-over- 606 coap-00) 608 * Soften Content-Format requirements in Section 4.2.1 and 609 Section 4.3 611 * Clarify "CoAP payload"/"CoAP body" terminology 613 * Fix nits and typos 615 A.2. Since draft-lenders-dns-over-coaps-00 616 (https://datatracker.ietf.org/doc/html/draft-lenders-dns-over- 617 coaps-00) 619 * Clarification in abstract that both DTLS and OSCORE can be used as 620 secure transport 622 * Restructuring of Section 4: 624 - Add dedicated Section 4.1 on Content-Format 626 - Add overview table about usable and required features for 627 request method types to Section 4.2 629 - Add dedicated Section 4.2.2 and Section 4.3.2 on caching 630 requirements for CoAP requests and responses 632 * Fix nits and typos 634 Acknowledgments 636 TODO acknowledge. 638 Authors' Addresses 640 Martine Sophie Lenders 641 Freie Universität Berlin 643 Email: m.lenders@fu-berlin.de 645 Christian Amsüss 647 Email: christian@amsuess.com 648 Cenk Gündoğan 649 HAW Hamburg 651 Email: cenk.guendogan@haw-hamburg.de 653 Thomas C. Schmidt 654 HAW Hamburg 656 Email: t.schmidt@haw-hamburg.de 658 Matthias Wählisch 659 Freie Universität Berlin 661 Email: m.waehlisch@fu-berlin.de