| rfc9726v3.txt | rfc9726.txt | |||
|---|---|---|---|---|
| skipping to change at line 70 ¶ | skipping to change at line 70 ¶ | |||
| 4.3. Use of a Too Generic DNS Name | 4.3. Use of a Too Generic DNS Name | |||
| 5. DNS Privacy and Outsourcing versus MUD Controllers | 5. DNS Privacy and Outsourcing versus MUD Controllers | |||
| 6. Recommendations to IoT Device Manufacturers on MUD and DNS | 6. Recommendations to IoT Device Manufacturers on MUD and DNS | |||
| Usage | Usage | |||
| 6.1. Consistently Use DNS | 6.1. Consistently Use DNS | |||
| 6.2. Use Primary DNS Names Controlled by the Manufacturer | 6.2. Use Primary DNS Names Controlled by the Manufacturer | |||
| 6.3. Use a Content Distribution Network with Stable DNS Names | 6.3. Use a Content Distribution Network with Stable DNS Names | |||
| 6.4. Do Not Use Tailored Responses to Answer DNS Names | 6.4. Do Not Use Tailored Responses to Answer DNS Names | |||
| 6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements | 6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements | |||
| 7. Interactions with mDNS and DNS-SD | 7. Interactions with mDNS and DNS-SD | |||
| 8. Privacy Considerations | 8. IANA Considerations | |||
| 9. Security Considerations | 9. Privacy Considerations | |||
| 10. References | 10. Security Considerations | |||
| 10.1. Normative References | 11. References | |||
| 10.2. Informative References | 11.1. Normative References | |||
| 11.2. Informative References | ||||
| Appendix A. A Failing Strategy: Anti-Patterns | Appendix A. A Failing Strategy: Anti-Patterns | |||
| A.1. Too Slow | A.1. Too Slow | |||
| A.2. Reveals Patterns of Usage | A.2. Reveals Patterns of Usage | |||
| A.3. Mappings Are Often Incomplete | A.3. Mappings Are Often Incomplete | |||
| A.4. Forward DNS Names Can Have Wildcards | A.4. Forward DNS Names Can Have Wildcards | |||
| Contributors | Contributors | |||
| Authors' Addresses | Authors' Addresses | |||
| 1. Introduction | 1. Introduction | |||
| skipping to change at line 130 ¶ | skipping to change at line 131 ¶ | |||
| Section 5 details how current trends in DNS resolution such as public | Section 5 details how current trends in DNS resolution such as public | |||
| DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) | DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) | |||
| [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with | [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with | |||
| the strategies employed. | the strategies employed. | |||
| The core of this document is Section 6, which makes a series of | The core of this document is Section 6, which makes a series of | |||
| recommendations ("best current practices") for manufacturers on how | recommendations ("best current practices") for manufacturers on how | |||
| to use DNS and IP addresses with IoT devices described by MUD. | to use DNS and IP addresses with IoT devices described by MUD. | |||
| Section 8 discusses a set of privacy issues that encrypted DNS (for | Section 9 discusses a set of privacy issues that encrypted DNS (for | |||
| example, DoT and DoH) are frequently used to deal with. How these | example, DoT and DoH) are frequently used to deal with. How these | |||
| concerns apply to IoT devices located within a residence or | concerns apply to IoT devices located within a residence or | |||
| enterprise is a key concern. | enterprise is a key concern. | |||
| Section 9 also covers some of the negative outcomes should MUD/ | Section 10 also covers some of the negative outcomes should MUD/ | |||
| firewall managers and IoT manufacturers choose not to cooperate. | firewall managers and IoT manufacturers choose not to cooperate. | |||
| 2. Terminology | 2. Terminology | |||
| This document makes use of terms defined in [RFC8520] and [RFC9499]. | This document makes use of terms defined in [RFC8520] and [RFC9499]. | |||
| The term "anti-pattern" comes from agile software design literature, | The term "anti-pattern" comes from agile software design literature, | |||
| as per [antipattern]. | as per [antipattern]. | |||
| "CDNs" refers to Content Distribution Networks, such as those | "CDNs" refers to Content Distribution Networks, such as those | |||
| skipping to change at line 572 ¶ | skipping to change at line 573 ¶ | |||
| enforcement point (an intra-department firewall) and could very well | enforcement point (an intra-department firewall) and could very well | |||
| be rejected because the MUD controller did not know about that | be rejected because the MUD controller did not know about that | |||
| interaction. | interaction. | |||
| [RFC8250] includes a number of provisions for controlling internal | [RFC8250] includes a number of provisions for controlling internal | |||
| communications, including complex communications like same | communications, including complex communications like same | |||
| manufacturer ACLs. To date, this aspect of MUD has been difficult to | manufacturer ACLs. To date, this aspect of MUD has been difficult to | |||
| describe. This document does not consider internal communications to | describe. This document does not consider internal communications to | |||
| be in scope. | be in scope. | |||
| 8. Privacy Considerations | 8. IANA Considerations | |||
| This document has no IANA actions. | ||||
| 9. Privacy Considerations | ||||
| The use of non-local DNS servers exposes the list of DNS names | The use of non-local DNS servers exposes the list of DNS names | |||
| resolved to a third party, including passive eavesdroppers. | resolved to a third party, including passive eavesdroppers. | |||
| The use of DoT and DoH eliminates the threat from passive | The use of DoT and DoH eliminates the threat from passive | |||
| eavesdropping but still exposes the list to the operator of the DoT | eavesdropping but still exposes the list to the operator of the DoT | |||
| or DoH server. There are additional methods to help preserve | or DoH server. There are additional methods to help preserve | |||
| privacy, such as that described by [RFC9230]. | privacy, such as that described by [RFC9230]. | |||
| The use of unencrypted (Do53) requests to a local DNS server exposes | The use of unencrypted (Do53) requests to a local DNS server exposes | |||
| skipping to change at line 619 ¶ | skipping to change at line 624 ¶ | |||
| notification in a private fashion. This is particularly powerful if | notification in a private fashion. This is particularly powerful if | |||
| a local recursive DoT server is used, which then communicates using | a local recursive DoT server is used, which then communicates using | |||
| DoT over the Internet. | DoT over the Internet. | |||
| The more complex case of Section 4.1 postulates that the version | The more complex case of Section 4.1 postulates that the version | |||
| number needs to be provided to an intelligent agent that can decide | number needs to be provided to an intelligent agent that can decide | |||
| the correct route to do upgrades. [RFC9019] provides a wide variety | the correct route to do upgrades. [RFC9019] provides a wide variety | |||
| of ways to accomplish the same thing without having to divulge the | of ways to accomplish the same thing without having to divulge the | |||
| current version number. | current version number. | |||
| 9. Security Considerations | 10. Security Considerations | |||
| This document deals with conflicting security requirements: | This document deals with conflicting security requirements: | |||
| * devices that an operator wants to manage using [RFC8520] | * devices that an operator wants to manage using [RFC8520] | |||
| * requirements for the devices to get access to network resources | * requirements for the devices to get access to network resources | |||
| that may be critical to their continued safe operation | that may be critical to their continued safe operation | |||
| This document takes the view that the two requirements do not need to | This document takes the view that the two requirements do not need to | |||
| be in conflict, but resolving the conflict requires careful planning | be in conflict, but resolving the conflict requires careful planning | |||
| skipping to change at line 657 ¶ | skipping to change at line 662 ¶ | |||
| IoT device can be described by a MUD file. This level of informed | IoT device can be described by a MUD file. This level of informed | |||
| cooperation within the IoT device vendor and with MUD controller | cooperation within the IoT device vendor and with MUD controller | |||
| manufacturers is key to getting significant return on investment from | manufacturers is key to getting significant return on investment from | |||
| MUD. | MUD. | |||
| Manufacturers are encouraged to write MUD files that are good enough | Manufacturers are encouraged to write MUD files that are good enough | |||
| rather than perfect. If in doubt, they should write MUD files that | rather than perfect. If in doubt, they should write MUD files that | |||
| are somewhat more permissive if the files result in no spurious | are somewhat more permissive if the files result in no spurious | |||
| alerts. | alerts. | |||
| 10. References | 11. References | |||
| 10.1. Normative References | 11.1. Normative References | |||
| [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, | [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, | |||
| DOI 10.17487/RFC1794, April 1995, | DOI 10.17487/RFC1794, April 1995, | |||
| <https://www.rfc-editor.org/info/rfc1794>. | <https://www.rfc-editor.org/info/rfc1794>. | |||
| [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram | [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram | |||
| Transport Layer Security (DTLS)", RFC 8094, | Transport Layer Security (DTLS)", RFC 8094, | |||
| DOI 10.17487/RFC8094, February 2017, | DOI 10.17487/RFC8094, February 2017, | |||
| <https://www.rfc-editor.org/info/rfc8094>. | <https://www.rfc-editor.org/info/rfc8094>. | |||
| skipping to change at line 689 ¶ | skipping to change at line 694 ¶ | |||
| [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | |||
| Firmware Update Architecture for Internet of Things", | Firmware Update Architecture for Internet of Things", | |||
| RFC 9019, DOI 10.17487/RFC9019, April 2021, | RFC 9019, DOI 10.17487/RFC9019, April 2021, | |||
| <https://www.rfc-editor.org/info/rfc9019>. | <https://www.rfc-editor.org/info/rfc9019>. | |||
| [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, | [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, | |||
| RFC 9499, DOI 10.17487/RFC9499, March 2024, | RFC 9499, DOI 10.17487/RFC9499, March 2024, | |||
| <https://www.rfc-editor.org/info/rfc9499>. | <https://www.rfc-editor.org/info/rfc9499>. | |||
| 10.2. Informative References | 11.2. Informative References | |||
| [Akamai] Wikipedia, "Akamai Technologies", 26 February 2025, | [Akamai] Wikipedia, "Akamai Technologies", 26 February 2025, | |||
| <https://en.wikipedia.org/w/ | <https://en.wikipedia.org/w/ | |||
| index.php?title=Akamai_Technologies&oldid=1277665363>. | index.php?title=Akamai_Technologies&oldid=1277665363>. | |||
| [AmazonS3] Wikipedia, "Amazon S3", 14 March 2025, | [AmazonS3] Wikipedia, "Amazon S3", 14 March 2025, | |||
| <https://en.wikipedia.org/w/ | <https://en.wikipedia.org/w/ | |||
| index.php?title=Amazon_S3&oldid=1280379498>. | index.php?title=Amazon_S3&oldid=1280379498>. | |||
| [antipattern] | [antipattern] | |||
| End of changes. 8 change blocks. | ||||
| 12 lines changed or deleted | 17 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||