rfc9726v1.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
[RFC8520] provides a standardized way to describe how a specific [RFC8520] provides a standardized way to describe how a device with a
purpose device makes use of Internet resources. Access Control Lists specific purpose makes use of Internet resources. Access Control
(ACLs) can be defined in a Manufacturer Usage Description (MUD) file Lists (ACLs) can be defined in a Manufacturer Usage Description (MUD)
[RFC8520] that permits a device to access Internet resources by their file [RFC8520] that permits a device to access Internet resources by
DNS names or IP addresses. their DNS names or IP addresses.
The use of a DNS name rather than an IP address in an ACL has many The use of a DNS name rather than an IP address in an ACL has many
advantages: Not only does the layer of indirection permit the mapping advantages: Not only does the layer of indirection permit the mapping
of a name to IP addresses to be changed over time, but it also of a name to IP addresses to be changed over time, but it also
generalizes automatically to IPv4 and IPv6 addresses as well as generalizes automatically to IPv4 and IPv6 addresses as well as
permits a variety of load-balancing strategies, including multi-CDN permits a variety of load-balancing strategies, including multi-CDN
deployments wherein load-balancing can account for geography and deployments wherein load-balancing can account for geography and
load. load.
However, the use of DNS names has implications on how ACLs are However, the use of DNS names has implications on how ACLs are
skipping to change at line 128 skipping to change at line 129
There are some ways of using DNS that will present problems for MUD There are some ways of using DNS that will present problems for MUD
controllers, which Section 4 explains. controllers, which Section 4 explains.
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 MUD supporting IoT devices. 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
described in [RFC6707], Section 1.1. described in [RFC6707], Section 1.1.
3. A Model for MUD Controller Mapping of DNS Names to Addresses 3. A Model for MUD Controller Mapping of DNS Names to Addresses
This section details a strategy that a MUD controller could take. This section details a strategy that a MUD controller could take.
Within the limits of the DNS use detailed in Section 6, this process Within the limits of the DNS use detailed in Section 6, this process
could work. The methods detailed in Appendix A just will not work. could work. The methods detailed in Appendix A just will not work.
The simplest successful strategy for translating DNS names for a MUD The simplest successful strategy for a MUD controller to translate
controller to take is to do a DNS lookup on the name (a forward DNS names is to do a DNS lookup on the name (a forward lookup) and
lookup) and then use the resulting IP addresses to populate the then use the resulting IP addresses to populate the actual ACLs.
actual ACLs.
There are a number of possible failures, and the goal of this section There are a number of possible failures, and the goal of this section
is to explain how some common DNS usages may fail. is to explain how some common DNS usages may fail.
3.1. Non-Deterministic Mappings 3.1. Non-Deterministic Mappings
Most importantly, the mapping of the DNS names to IP addresses should Most importantly, the mapping of the DNS names to IP addresses could
be non-deterministic. be non-deterministic.
[RFC1794] describes the very common mechanism that returns DNS A (or [RFC1794] describes the very common mechanism that returns DNS A (or
reasonably AAAA) records in a permuted order. This is known as reasonably AAAA) records in a permuted order. This is known as
"round-robin DNS" and has been used for many decades. The historical "round-robin DNS" and has been used for many decades. The historical
intent is that the requestor will tend to use the first IP address intent is that the requestor will tend to use the first IP address
that is returned. As each query results in addresses being in a that is returned. As each query results in addresses being in a
different order, the effect is to split the load among many servers. different order, the effect is to split the load among many servers.
This situation does not result in failures as long as all possible A/ This situation does not result in failures as long as all possible A/
skipping to change at line 306 skipping to change at line 306
The first is that the update service server must decide whether to The first is that the update service server must decide whether to
provide an IPv4 or an IPv6 literal, assuming that only one URL can be provide an IPv4 or an IPv6 literal, assuming that only one URL can be
provided. A DNS name can contain both kinds of addresses and can provided. A DNS name can contain both kinds of addresses and can
also contain many different IP addresses of each kind. An update also contain many different IP addresses of each kind. An update
server might believe that if the connection were on IPv4, then an server might believe that if the connection were on IPv4, then an
IPv4 literal would be acceptable. However, due to NAT64 [RFC6146], a IPv4 literal would be acceptable. However, due to NAT64 [RFC6146], a
device with only IPv6 connectivity will often be able to reach an device with only IPv6 connectivity will often be able to reach an
IPv4 firmware update server by name (through DNS64 [RFC6147]) but not IPv4 firmware update server by name (through DNS64 [RFC6147]) but not
be able to reach an arbitrary IPv4 address. be able to reach an arbitrary IPv4 address.
A MUD file definition for this access would need to resolve to the A MUD file for this access would need to resolve to the set of IP
set of IP addresses that might be returned by the update server. addresses that might be returned by the update server. This can be
This can be done with IP address literals in the MUD file, but this done with IP address literals in the MUD file, but this may require
may require continuing updates to the MUD file if the addresses continuing updates to the MUD file if the addresses change
change frequently. A DNS name in the MUD could resolve to the set of frequently. A DNS name in the MUD could resolve to the set of all
all possible IPv4 and IPv6 addresses that would be used, with DNS possible IPv4 and IPv6 addresses that would be used, with DNS
providing a level of indirection that obviates the need to update the providing a level of indirection that obviates the need to update the
MUD file itself. MUD file itself.
A third problem involves the use of HTTPS. It is often more A third problem involves the use of HTTPS. It is often more
difficult to get TLS certificates for an IP address, and so it is difficult to get TLS certificates for an IP address, and so it is
less likely that the firmware download will be protected by TLS. An less likely that the firmware download will be protected by TLS.
IP address literal in the TLS ServerNameIndicator [RFC6066] might not Even if an IP address literal was placedin the TLS
provide enough context for a web server to distinguish which of the ServerNameIndicator [RFC6066], against the advice of that document,
(potentially many) tenants the client wishes to reach. This drives it still would not provide enough context for a web server to
the use of an IP address per tenant, and for IPv4 (at least), this is distinguish which of the (potentially many) tenants the client wishes
no longer a sustainable use of IP addresses. to reach. This drives the use of an IP address per tenant, and for
IPv4 (at least), this is no longer a sustainable use of IP addresses.
Finally, it is common in some CDNs to use multiple layers of DNS Finally, it is common in some CDNs to use multiple layers of DNS
CNAMEs in order to isolate the content owner's naming system from CNAMEs in order to isolate the content owner's naming system from
changes in how the distribution network is organized. changes in how the distribution network is organized.
When a name or address is returned within an update protocol for When a name or address is returned within an update protocol for
which a MUD rule cannot be written, then the MUD controller is unable which a MUD rule cannot be written, then the MUD controller is unable
to authorize the connection. In order for the connection to be to authorize the connection. In order for the connection to be
authorized, the set of names returned within the update protocol authorized, the set of names returned within the update protocol
needs to be known ahead of time and must be from a finite set of needs to be known ahead of time and must be from a finite set of
skipping to change at line 364 skipping to change at line 365
Even if the CDN provider's chosen DNS names are deterministic, they Even if the CDN provider's chosen DNS names are deterministic, they
may change at a rate much faster than MUD files can be updated. may change at a rate much faster than MUD files can be updated.
This situation applies to firmware updates but also applies to many This situation applies to firmware updates but also applies to many
other kinds of content: video content, in-game content, etc. other kinds of content: video content, in-game content, etc.
A solution may be to use a deterministic DNS name within the control A solution may be to use a deterministic DNS name within the control
of the device manufacturer. The device manufacturer is asked to of the device manufacturer. The device manufacturer is asked to
point a CNAME to the CDN, to a name that might look like point a CNAME to the CDN, to a name that might look like
"g7.a.example", with the expectation that the CDN vendor's DNS will "g7.a.example", with the expectation that the CDN provider's DNS will
do all the appropriate work to geolocate the transfer. This can be do all the appropriate work to geolocate the transfer. This can be
fine for a MUD file, as the MUD controller, if located in the same fine for a MUD file, as the MUD controller, if located in the same
geography as the IoT device, can follow the CNAME and collect the set geography as the IoT device, can follow the CNAME and collect the set
of resulting IP addresses along with the TTL for each. Then, the MUD of resulting IP addresses along with the TTL for each. Then, the MUD
controller can take charge of refreshing that mapping at intervals controller can take charge of refreshing that mapping at intervals
driven by the TTL. driven by the TTL.
In some cases, a complete set of geographically distributed servers In some cases, a complete set of geographically distributed servers
may be known ahead of time (or that it changes very slowly), and the may be known ahead of time (or that it changes very slowly), and the
device manufacturer can list all those IP addresses in the DNS for device manufacturer can list all those IP addresses in the DNS for
skipping to change at line 435 skipping to change at line 436
6. Recommendations to IoT Device Manufacturers on MUD and DNS Usage 6. Recommendations to IoT Device Manufacturers on MUD and DNS Usage
Inclusion of a MUD file with IoT devices is operationally quite Inclusion of a MUD file with IoT devices is operationally quite
simple. It requires only a few small changes to the DHCP client code simple. It requires only a few small changes to the DHCP client code
to express the MUD URL. It can even be done without code changes via to express the MUD URL. It can even be done without code changes via
the use of a QR code affixed to the packaging (see [RFC9238]). the use of a QR code affixed to the packaging (see [RFC9238]).
The difficult part is determining what to put into the MUD file The difficult part is determining what to put into the MUD file
itself. There are currently tools that help with the definition and itself. There are currently tools that help with the definition and
analysis of MUD files; see [mudmaker]. The remaining difficulty is analysis of MUD files; see [mudmaker]. The remaining difficulty is
now the actual list of expected connections to put in the MUD file. the actual list of expected connections to put in the MUD file. An
An IoT manufacturer must now spend some time reviewing the network IoT manufacturer must spend some time reviewing the network
communications by their device. communications by their device.
This document discusses a number of challenges that occur relating to This document discusses a number of challenges that occur relating to
how DNS requests are made and resolved, and the goal of this section how DNS requests are made and resolved, and the goal of this section
is to make recommendations on how to modify IoT systems to work well is to make recommendations on how to modify IoT systems to work well
with MUD. with MUD.
6.1. Consistently Use DNS 6.1. Consistently Use DNS
For the reasons explained in Section 4.1, the most important For the reasons explained in Section 4.1, the most important
skipping to change at line 494 skipping to change at line 495
receives an answer that is based upon the same topological decision receives an answer that is based upon the same topological decision
as when the IoT device makes its query. as when the IoT device makes its query.
There are probably ways in which the MUD controller could use the There are probably ways in which the MUD controller could use the
edns-client-subnet option to make a query that would get the same edns-client-subnet option to make a query that would get the same
treatment as when the IoT device makes its query. If this worked, treatment as when the IoT device makes its query. If this worked,
then it would receive the same answer as the IoT device. then it would receive the same answer as the IoT device.
In practice it could be quite difficult if the IoT device uses a In practice it could be quite difficult if the IoT device uses a
different Internet connection, a different firewall, or a different different Internet connection, a different firewall, or a different
recursive DNS server. The edns-client-server might be ignored or recursive DNS server. The edns-client-subnet option might be ignored
overridden by any of the DNS infrastructure. or overridden by any of the DNS infrastructure.
Some tailored responses might only reorder the replies so that the Some tailored responses might only reorder the replies so that the
most preferred address is first. Such a system would be acceptable most preferred address is first. Such a system would be acceptable
if the MUD controller had a way to know that the list was complete. if the MUD controller had a way to know that the list was complete.
But, due to the above problems, a strong recommendation is to avoid But, due to the above problems, a strong recommendation is to avoid
using tailored responses as part of the DNS names in the MUD file. using tailored responses as part of the DNS names in the MUD file.
6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements 6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements
skipping to change at line 528 skipping to change at line 529
resolver to mitigate against local misconfiguration. There are a resolver to mitigate against local misconfiguration. There are a
number of reasons to avoid this, detailed in Section 6.4. The public number of reasons to avoid this, detailed in Section 6.4. The public
resolver might not return the same tailored names that the MUD resolver might not return the same tailored names that the MUD
controller would get. controller would get.
It is recommended that non-local resolvers are only used when the It is recommended that non-local resolvers are only used when the
locally provided resolvers provide no answers to any queries at all locally provided resolvers provide no answers to any queries at all
and do so repeatedly. The status of the operator-provided resolvers and do so repeatedly. The status of the operator-provided resolvers
needs to be re-evaluated on a periodic basis. needs to be re-evaluated on a periodic basis.
Finally, if a device will ever attempt to use a non-local resolver, Finally, if a device will ever attempt to use non-local resolvers,
then the address of that resolver needs to be listed in the MUD file then the addresses of those resolvers need to be listed in the MUD
as a destination that is to be permitted. This needs to include the file as destinations that are to be permitted. This needs to include
port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be used the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be
as well. used as well.
7. Interactions with mDNS and DNS-SD 7. Interactions with mDNS and DNS-SD
Unicast DNS requests are not the only way to map names to IP Unicast DNS requests are not the only way to map names to IP
addresses. IoT devices might also use Multicast DNS (mDNS) addresses. IoT devices might also use Multicast DNS (mDNS)
[RFC6762], both to be discovered by other devices and also to [RFC6762], both to be discovered by other devices and also to
discover other devices. discover other devices.
mDNS replies include A and AAAA records, and it is conceivable that mDNS replies include A and AAAA records, and it is conceivable that
these replies contain addresses that are not local to the link on these replies contain addresses that are not local to the link on
skipping to change at line 573 skipping to change at line 574
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 620 skipping to change at line 625
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 658 skipping to change at line 663
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 690 skipping to change at line 695
[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. 18 change blocks. 
45 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48.