idnits 2.17.1 draft-ietf-opsawg-mud-iot-dns-considerations-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (26 January 2021) is 1185 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BEHAVE-BCP-REF' is mentioned on line 289, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Akamai' -- Possible downref: Non-RFC (?) normative reference: ref. 'AmazonS3' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dnsop-terminology-ter' == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-15 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') -- Possible downref: Normative reference to a draft: ref. 'I-D.peterson-doh-dhcp' ** Downref: Normative reference to an Informational RFC: RFC 1794 ** Downref: Normative reference to an Experimental RFC: RFC 8094 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice 26 January 2021 5 Expires: 30 July 2021 7 Operational Considerations for use of DNS in IoT devices 8 draft-ietf-opsawg-mud-iot-dns-considerations-00 10 Abstract 12 This document details concerns about how Internet of Things devices 13 use IP addresses and DNS names. The issue becomes acute as network 14 operators begin deploying RFC8520 Manufacturer Usage Description 15 (MUD) definitions to control device access. 17 This document explains the problem through a series of examples of 18 what can go wrong, and then provides some advice on how a device 19 manufacturer can best make deal with these issues. The 20 recommendations have an impact upon device and network protocol 21 design. 23 {RFC-EDITOR, please remove. Markdown and issue tracker for this 24 document is at https://github.com/mcr/iot-mud-dns-considerations.git 25 } 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 30 July 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4 63 4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6 64 4.1. Use of IP address literals in-protocol . . . . . . . . . 6 65 4.2. Use of non-deterministic DNS names in-protocol . . . . . 7 66 4.3. Use of a too inclusive DNS name . . . . . . . . . . . . . 7 67 5. DNS privacy and outsourcing vs MUD controllers . . . . . . . 7 68 6. Recommendations to IoT device manufacturer on MUD and DNS 69 usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 8 71 6.2. Use primary DNS names controlled by the manufacturer . . 8 72 6.3. Use Content-Distribution Network with stable names . . . 9 73 6.4. Prefer DNS servers learnt from DHCP/Route 74 Advertisements . . . . . . . . . . . . . . . . . . . . . 9 75 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 [RFC8520] provides a standardized way to describe how a specific 86 purpose device makes use of Internet resources. Access Control Lists 87 (ACLs) can be defined in an RFC8520 Manufacturer Usage Description 88 (MUD) file that permit a device to access Internet resources by DNS 89 name. 91 Use of a DNS name rather than IP address in the ACL has many 92 advantages: not only does the layer of indirection permit the mapping 93 of name to IP address to be changed over time, it also generalizes 94 automatically to IPv4 and IPv6 addresses, as well as permitting 95 loading balancing of traffic by many different common ways, including 96 geography. 98 At the MUD policy enforcement point - the firewall - there is a 99 problem. The firewall has only access to the layer-3 headers of the 100 packet. This includes the source and destination IP address, and if 101 not encrypted by IPsec, the destination UDP or TCP port number 102 present in the transport header. The DNS name is not present! 104 In theory, on TLS 1.2 connections the MUD policy enforcement point 105 might observe the Server Name Identifier (SNI), in practice it 106 involves active termination of the TCP connection (a forced circuit 107 proxy) in order to see enough of the traffic. And to what end? TLS 108 1.3 provides options to encrypt it (ESNI). 110 So in order to implement these name based ACLs, there must be a 111 mapping between the names in the ACLs and layer-3 IP addresses. The 112 first section of this document details a few strategies that are 113 used. 115 The second section of this document details how common manufacturer 116 anti-patterns get in the way this mapping. 118 The third section of this document details how current trends in DNS 119 presolution such as public DNS servers, DNS over TLS (DoT), and DNS 120 over HTTPS (DoH) cause problems for the strategies employed. Poor 121 interactions with content-distribution networks is a frequent 122 pathology that can result. 124 The fourth section of this document makes a series of recommendations 125 ("best current practices") for manufacturers on how to use DNS, and 126 IP addresses with specific purpose IoT devices. 128 The Privacy Considerations section concerns itself with issues that 129 DNS-over-TLS and DNS-over-HTTPS are frequently used to deal with. 130 How these concerns apply to IoT devices located within a residence or 131 enterprise is a key concern. 133 The Security Considerations section covers some of the negative 134 outcomes should MUD/firewall managers and IoT manufacturers choose 135 not to cooperate. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 This document is a Best Current Practices (BCP) document. It uses 146 the above language where it needs to make a normative requirement on 147 implementations. 149 3. Strategies to map names 151 The most naive method is to try to map IP addresses to names using 152 the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings. This fails 153 for a number of reasons: 1) it can not be done fast enough, 2) it 154 reveals usage patterns of the devices, 3) the mapping are often 155 incomplete, 4) even if the mapping is present, due to virtual 156 hosting, it may not map back to the name used in the ACL. This is 157 not a successful strategy, and it is not used. 159 The simplest successful strategy for translating names is for a MUD 160 controller to take is to do a DNS lookup on the name (a forward 161 lookup), and then use the resulting IP addresses to populate the 162 physical ACLs. 164 There are still a number of failures possible. 166 The most important one is in the mapping of the names to IP addresses 167 may be non-deterministic. [RFC1794] describes the very common 168 mechanism that returns DNS A (or reasonably AAAA) records in a 169 permutted order. This is known as Round Robin DNS, and it has been 170 used for many decades. The device is intended to use the first IP 171 address that is returned, and each query returns addresses in a 172 different ordering, splitting the load among many servers. 174 This situation does not result in failures as long as all possible A/ 175 AAAA records are returned. The MUD controller and the device get a 176 matching set, and the ACLs that are setup cover all possibilities. 178 There are a number of circumstances in which the list is not 179 exhaustive. The simplest is when the round robin does not return all 180 addresses. This is routinely done by geographical DNS load balancing 181 system. It can also happen if there are more addresses than will 182 conveniently fit into a DNS reply. The reply will be marked as 183 truncated. (If DNSSEC resolution will be done, then the entire RR 184 must be retrieved over TCP (or using a larger EDNS(0) size) before 185 being validated) 187 However, in a geographical DNS load balancing system, different 188 answers are given based upon the locality of the system asking. 189 There may also be further layers of round-robin indirection. 191 Aside from the list of records being incomplete, the list may have 192 changed between the time that the MUD controller did the lookup and 193 the time that the IoT device does the lookup, and this change can 194 result in a failure for the ACL to match. 196 In order to compensate for this, the MUD controller SHOULD regularly 197 do DNS lookups. These lookups need to be rate limited in order to 198 avoid load. It may be necessary to avoid recursive DNS servers in 199 order to avoid receiving cached data. Properly designed recursive 200 servers should cache data for many minutes to days, while the 201 underlying DNS data can change at a higher frequency, providing 202 different answers to different queries! 204 A MUD controller that is aware of which recursive DNS server that the 205 IoT device will use can instead query that server on a periodic 206 basis. Doing so provides three advantages: 208 1. any geographic load balancing will base the decision on the 209 geolocation of the recursive DNS server, and the recursive name 210 server will provide the same answer to the MUD controller as to 211 the IoT device. 213 2. the resulting name to IP address mapping in the recursive name 214 server will be cached, and will remain the same for the entire 215 advertised Time-To-Live reported in the DNS query return. This 216 also allows the MUD controller to avoid doing unnecessary 217 queries. 219 3. if any addresses have been omitted in a round-robin DNS process, 220 the cache will have the set of addresses that were returned. 222 The solution of using the same caching recursive resolver as the 223 target device is very simple when the MUD controllers is located in a 224 residential CPE device. The device is usually also the policy 225 enforcement point for the ACLs, and a caching resolver is typically 226 located on the same device. In addition the convenience, there is a 227 shared fate advantage: as all three components are running on the 228 same device, if the device is rebooted, clearing the cache, then all 229 three components will get restarted when the device is restarted. 231 Where the solution is more complex is when the MUD controller is 232 located elsewhere in an Enteprise, or remotely in a cloud such as 233 when a Software Defines Network (SDN) is used to manage the ACLs. 234 The DNS servers for a particular device may not be known to the MUD 235 controller, nor the MUD controller be even permitted to make recusive 236 queries that server if it is known. In this case, additional 237 installation specific mechanisms are probably needed to get the right 238 view of DNS. 240 4. DNS and IP Anti-Patterns for IoT device Manufacturers 242 This section describes a number of things with IoT manufacturers have 243 been observed to do in the field, each of which presents difficulties 244 for MUD enforcement points. 246 4.1. Use of IP address literals in-protocol 248 A common pattern for a number of devices is to look for firmware 249 updates in a two step process. An initial query is made (often over 250 HTTPS, sometimes with a POST, but the method is immaterial) to an 251 authoritatve server. The current firmware model of the device is 252 sometimes provided and then the authoritative server provides a 253 determination if a new version is required, and if so, what version. 254 In simpler cases, an HTTPS end point is queried which provides the 255 name and URL of the most recent firmware. 257 The more complex case supports situations in which the device needs 258 to be running the latest patch release before it can apply the next 259 major release. For instance, a device running 1.4 must upgrade to at 260 least version 1.9 before it is able to download version 2.0 of the 261 firmware. 263 The authoritative upgrade server then responds with a URL of a 264 firmware blob that the device should download and install. Best 265 practice is that firmware is either signed internally 266 ([I-D.ietf-suit-architecture]) so that it can be verified, or a hash 267 of the blob is provided. 269 The challenge for a MUD controller is in the details of the URL that 270 is provided. An authoritative server might be tempted to provided an 271 IP address literal inside the protocol: there are two arguments for 272 doing this. 274 One is that it eliminates problems to firmware updates that might be 275 caused by lack of DNS, or incompatibilities with DNS. For instance 276 the bug that causes interoperability issues with some recursive 277 servers would become unpatchable for devices that were forced to use 278 that recursive resolver type. 280 A second reason to avoid a DNS in the URL is when an inhouse content- 281 distribution system is involved that involves on-demand instances 282 being added (or removed) from a cloud computing architecture. This 283 model is typical of on-demand video systems including Netflix (see 284 [LOOKING FOR NETFLIX REF], [WINDOWS UPDATE REF]), but this can occur 285 in quite a number of other situations. Third-party content- 286 distribution networks (CDN) tend to use DNS names in order to isolate 287 the content-owner from changes to the distribution network. 289 [BEHAVE-BCP-REF] gives other good reasons why IP address literals are 290 bad ideas; in particular they work very poorly when devices have IPv6 291 capabilities, and are on IPv6-only networks with NAT64 (see 292 [RFC6146]). 294 4.2. Use of non-deterministic DNS names in-protocol 296 A second pattern is for a control protocol to connect to a known HTTP 297 end point. This is easily described in MUD. Within that control 298 protocol references are made to additional content at other URLs. 299 The values of those URLs do not fit any easily described pattern and 300 may point at arbitrary names. 302 Those names are often within some third-party Content-Distribution- 303 Network (CDN) system, or may be arbitrary names in a cloud-provider 304 storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). 306 *INSERT* examples of non-deterministic CDN content. 308 Since it is not possible to predict a name for where the content will 309 be, it is not possible to include that into the MUD file. 311 This applies to the firmware update situation as well. 313 4.3. Use of a too inclusive DNS name 315 Some CDNs make all customer content at a single URL (such as 316 s3.amazonaws.com). This seems to be ideal from a MUD point of view: 317 a completely predictable URL. The problem is that a compromised 318 device could then connect to any S3 bucket, potentially attacking 319 other buckets. 321 The MUD ACLs provide only for permitting end points and do not filter 322 URLs (nor could filtering be enforced within HTTPS). 324 5. DNS privacy and outsourcing vs MUD controllers 326 [RFC7858] and [RFC8094] provide for DNS over TLS and DTLS. 327 [I-D.ietf-dnsop-terminology-ter] details the terms. But, even with 328 traditional DNS over Port-53 (Do53), it is possible to oursource DNS 329 queries to other public services, such as those operated by Google, 330 CloudFlare, Verisign, etc. 332 There are significant privacy issues with having IoT devices sending 333 their DNS queries to an outside entity. Doing it over a secure 334 transport (DoT/DoH) is clearly better than doing so on port 53. The 335 providers of the secure resolver service will, however, still see the 336 IoT device queries. 338 A described above in Section 3 the MUD controller needs to have 339 access to the same resolver(s) as the IoT device. Use of the QuadX 340 resolvers at first seems to present less of a problem than use of 341 some other less well known resolver. While any system may use QuadX, 342 in most cases those services are massively replicated via anycast: 343 there is no guarantee that a MUD controller will speak to the same 344 instance, or get the same geographic anycast result. 346 6. Recommendations to IoT device manufacturer on MUD and DNS usage 348 Inclusion of a MUD file with IoT devices is operationally quite 349 simple. It requires only a few small changes to the DHCP client code 350 to express the MUD URL. It can even be done without code changes via 351 the use of a QR code affixed to the packaging (see 352 [I-D.richardson-opsawg-securehomegateway-mud]). 354 The difficult part is determining what to put into the MUD file 355 itself. There are currently tools that help with the definition and 356 analysis of MUD files, see [mudmaker]. The remaining difficulty is 357 now the semantic contents of what is in the MUD file. An IoT 358 manufacturer must now spend some time reviewing what the network 359 communications that their device does. 361 This document has discussed a number of challenges that occur 362 relating to how DNS requests are made and resolved, and it is the 363 goal of this section to make recommendations on how to modify IoT 364 systems to work well with MUD. 366 6.1. Consistently use DNS 368 The first recommendation is to avoid using IP address literals in any 369 protocol. Names should always be used. 371 6.2. Use primary DNS names controlled by the manufacturer 373 The second recommendation is to allocate and use names within zones 374 controlled by the manufacturer. These names can be populated with an 375 alias (see [RFC8499] section 2) that points to the production system. 376 Ideally, a different name is used for each logical function, allowing 377 for different rules in the MUD file to be enabled and disabled. 379 While it used to be costly to have a large number of aliases in a web 380 server certificate, this is no longer the case. Wildcard 381 certificates are also commonly available which allowed for an 382 infinite number of possible names. 384 6.3. Use Content-Distribution Network with stable names 386 When aliases point to a Content-Distribution Network (CDN), prefer to 387 use stable names that point to appropriately load balanced targets. 388 CDNs that employ very low time-to-live (TTL) values for DNS make it 389 harder for the MUD controller to get the same answer as the IoT 390 Device. A CDN that always returns the same set of A and AAAA 391 records, but permutes them to provide the best one first provides a 392 more reliable answer. 394 6.4. Prefer DNS servers learnt from DHCP/Route Advertisements 396 IoT Devices should prefer doing DNS to the network provided DNS 397 servers. Whether this is restricted to Classic DNS (Do53) or also 398 includes using DoT/DoH is a local decision, but a locally provided 399 DoT server SHOULD be used, as recommended by 400 [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp]. 402 Use of public QuadX resolver instead of the provided DNS resolver, 403 whether Do53, DoT or DoH is discouraged. Should the network provide 404 such a resolver for use, then there is no reason not to use it, as 405 the network operator has clearly thought about this. 407 Some manufacturers would like to have a fallback to using a public 408 resolver to mitigate against local misconfiguration. There are a 409 number of reasons to avoid this, or at least do this very carefully. 410 The recommendation here is to do this only when the provided 411 resolvers provide no answers to any queries at all, and do so 412 repeatedly. The use of the operator provided resolvers SHOULD be 413 retried on a periodic basis, and once they answer, there should be no 414 further attempts to contact public resolvers. 416 Finally, the list of public resolvers that might be contacted MUST be 417 listed in the MUD file as destinations that are to be permitted! 418 This should include the port numbers (53, 853 for DoT, 443 for DoH) 419 that will be used as well. 421 7. Privacy Considerations 423 The use of non-local DNS servers exposes the list of names resolved 424 to a third parties, including passive eavesdroppers. 426 The use of DoT and DoH eliminates the minimizes threat from passive 427 eavesdropped, but still exposes the list to the operator of the DoT 428 or DoH server. 430 The use of unencrypted (Do53) requests to a local DNS server exposes 431 the list to any internal passive eavesdroppers, and for some 432 situations that may be significant, particularly if unencrypted WiFi 433 is used. Use of DoT to a local DNS recursive resolver is a preferred 434 choice, assuming that the trust anchor for the local DNS server can 435 be obtained, such as via [I-D.reddy-dprive-bootstrap-dns-server]. 437 IoT devices that reach out to the manufacturer at regular intervals 438 to check for firmware updates are informing passive eavesdroppers of 439 the existence of a specific manufacturer's device being present at 440 the origin location. While possession of a Large (Kitchen) Appliance 441 at a residence may be uninteresting to most, possession of intimate 442 personal devices (e.g., "sex toys") may be a cause for embarassment. 444 IoT device manufacturers are encouraged to anonymizing ways to do 445 update queries. For instance, contracting out the update 446 notification service to a third party that deals with a large variety 447 of devices would provide a level of defense against passive 448 eavesdropping. Other update mechanisms should be investigated, 449 including use of DNSSEC signed TXT records with current version 450 information. This would permit DoT or DoH to provide the update 451 notification. This is particularly powerful if a local recursive DoT 452 server is used, which then communicates using DoT over the Internet. 454 The more complex case of section Section 4.1 postulates that the 455 version number needs to be provided to an intelligent agent that can 456 decided the correct route to do upgrades. The current 457 [I-D.ietf-suit-architecture] specification provides a wide variety of 458 ways to accomplish the same thing without having to divulge the 459 current version number. 461 The use of a publically specified firmware update protocol would also 462 enhance privacy of IoT devices. In such a system the IoT device 463 would never contact the manufacturer for version information or for 464 firmware itself. Instead, details of how to query and where to get 465 the firmware would be provided as a MUD extension, and a Enterprise- 466 wide mechanism would retrieve firmware, and then distribute it 467 internally. Aside from the bandwidth savings of downloading the 468 firmware only once, this also makes the number of devices active 469 confidential, and provides some evidence about which devices have 470 been upgraded and which ones might still be vulnerable. (The 471 unpatched devices might be lurking, powered off, lost in a closet) 473 8. Security Considerations 475 This document deals with conflicting Security requirements: devices 476 which an operator wants to manage using [RFC8520] vs requirements for 477 the devices to get access to network resources that may be critical 478 to their continued safe operation. 480 This document takes the view that the two requirements do not need to 481 be in conflict, but resolving the conflict requires some advance 482 planning by all parties. 484 9. References 486 9.1. Normative References 488 [Akamai] "Akamai", 2019, 489 . 491 [AmazonS3] "Amazon S3", 2019, 492 . 494 [I-D.ietf-dnsop-terminology-ter] 495 Hoffman, P., "Terminology for DNS Transports and 496 Location", Work in Progress, Internet-Draft, draft-ietf- 497 dnsop-terminology-ter-02, 3 August 2020, 498 . 501 [I-D.ietf-suit-architecture] 502 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 503 Firmware Update Architecture for Internet of Things", Work 504 in Progress, Internet-Draft, draft-ietf-suit-architecture- 505 15, 17 January 2021, . 508 [I-D.peterson-doh-dhcp] 509 Peterson, T., "DNS over HTTP resolver announcement Using 510 DHCP or Router Advertisements", Work in Progress, 511 Internet-Draft, draft-peterson-doh-dhcp-01, 21 October 512 2019, . 515 [I-D.reddy-dprive-bootstrap-dns-server] 516 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 517 "A Bootstrapping Procedure to Discover and Authenticate 518 DNS-over-TLS and DNS-over-HTTPS Servers", Work in 519 Progress, Internet-Draft, draft-reddy-dprive-bootstrap- 520 dns-server-08, 6 March 2020, . 524 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 525 DOI 10.17487/RFC1794, April 1995, 526 . 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 533 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 534 NAT64: Network Address and Protocol Translation from IPv6 535 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 536 April 2011, . 538 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 539 and P. Hoffman, "Specification for DNS over Transport 540 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 541 2016, . 543 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 544 Transport Layer Security (DTLS)", RFC 8094, 545 DOI 10.17487/RFC8094, February 2017, 546 . 548 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 549 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 550 May 2017, . 552 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 553 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 554 January 2019, . 556 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 557 Description Specification", RFC 8520, 558 DOI 10.17487/RFC8520, March 2019, 559 . 561 9.2. Informative References 563 [I-D.richardson-opsawg-securehomegateway-mud] 564 Richardson, M., Latour, J., and H. Gharakheili, "On 565 loading MUD URLs from QR codes", Work in Progress, 566 Internet-Draft, draft-richardson-opsawg-securehomegateway- 567 mud-05, 8 September 2020, . 571 [mudmaker] "Mud Maker", 2019, . 573 Appendix A. Appendices 575 Author's Address 577 Michael Richardson 578 Sandelman Software Works 580 Email: mcr+ietf@sandelman.ca