rfc9726v1.txt		rfc9726.txt
	skipping to change at line 128 ¶		skipping to change at line 128 ¶
	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 8 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 9 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
	skipping to change at line 154 ¶		skipping to change at line 154 ¶
	"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 305 ¶
	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. An
	IP address literal in the TLS ServerNameIndicator [RFC6066] might not		IP address literal in the TLS ServerNameIndicator [RFC6066] might not
	provide enough context for a web server to distinguish which of the		provide enough context for a web server to distinguish which of the
	(potentially many) tenants the client wishes to reach. This drives		(potentially many) tenants the client wishes to reach. This drives
	the use of an IP address per tenant, and for IPv4 (at least), this is		the use of an IP address per tenant, and for IPv4 (at least), this is
	skipping to change at line 364 ¶		skipping to change at line 363 ¶
	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 434 ¶
	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 528 ¶		skipping to change at line 527 ¶
	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
End of changes. 7 change blocks.
	20 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48.