rfc9726.original.xml		rfc9726.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.2.		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	2) -->		-ietf-opsawg-mud-iot-dns-considerations-19" number="9726" category="bcp" consens
	<?rfc stand-alone="yes"?>		us="true" tocInclude="true" sortRefs="true" symRefs="true" version="3" xml:lang=
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		"en" updates="" obsoletes="" submissionType="IETF">
	-ietf-opsawg-mud-iot-dns-considerations-19" category="bcp" consensus="true" tocI
	nclude="true" sortRefs="true" symRefs="true" version="3">		<!--[rfced] This document has been assigned a new BCP number. Please
	<!-- xml2rfc v2v3 conversion 3.23.0 -->		let us know if this is not correct (i.e., it should be part of an existing BCP).
			See the complete list of BCPs here: https://www.rfc-editor.org/bcps
			-->
	<front>		<front>
	<title abbrev="mud-iot-dns">Operational Considerations for Use of DNS in IoT		<title abbrev="DNS in IoT Devices">Operational Considerations for Use of DNS
	Devices</title>		in Internet of Things (IoT) Devices</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-mud-iot-dns-consi		<seriesInfo name="RFC" value="9726"/>
	derations-19"/>		<seriesInfo name="BCP" value="241"/>
	<author initials="M." surname="Richardson" fullname="Michael Richardson">		<author initials="M." surname="Richardson" fullname="Michael Richardson">
	<organization>Sandelman Software Works</organization>		<organization>Sandelman Software Works</organization>
	<address>		<address>
	<email>mcr+ietf@sandelman.ca</email>		<email>mcr+ietf@sandelman.ca</email>
	</address>		</address>
	</author>		</author>
	<author initials="W." surname="Pan" fullname="Wei Pan">		<author initials="W." surname="Pan" fullname="Wei Pan">
	<organization>Huawei Technologies</organization>		<organization>Huawei Technologies</organization>
	<address>		<address>
	<email>william.panwei@huawei.com</email>		<email>william.panwei@huawei.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="October" day="03"/>		<date year="2025" month="March"/>
	<area>Operations</area>		<area>OPS</area>
	<workgroup>OPSAWG Working Group</workgroup>		<workgroup>opsawg</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>
	<?line 74?>
	<t>This document details considerations about how Internet of Things (IoT) devic		<keyword>DNS</keyword>
	es use IP		<keyword>MUD</keyword>
	addresses and DNS names.		<keyword>round-robin</keyword>
	These concerns become acute as network operators begin deploying RFC 8520 Manufa		<keyword>tailored response</keyword>
	cturer Usage Description (MUD) definitions to control device access.</t>		<keyword>DNSSEC</keyword>
	<t>Also, this document makes recommendations on when and how to use DNS na		<keyword>IoT security</keyword>
	mes in MUD files.</t>		<keyword>Device Identity</keyword>
			<!--[rfced] FYI, this sentence has been updated as follows for clarity.
			Please review whether these terms convey the same meaning:
			"Manufacturer Usage Description (MUD) definitions"
			replaced with "Manufacturer Usage Descriptions (MUDs)" (plural).
			We note the plural is used in the abstract of RFC 8520.
			Original:
			These concerns become
			acute as network operators begin deploying RFC 8520 Manufacturer
			Usage Description (MUD) definitions to control device access.
			Current:
			These concerns become
			acute as network operators begin deploying Manufacturer
			Usage Descriptions (MUDs), as specified in RFC 8520, to control
			device access.
			-->
			<abstract>
			<t>This document details considerations about how Internet of Things
			(IoT) devices use IP addresses and DNS names. These concerns become
			acute as network operators begin deploying Manufacturer Usage
			Descriptions (MUD), as specified in RFC 8520, to control device access.</t
			>
			<t>Also, this document makes recommendations on when and how to use DNS
			names in MUD files.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	opsawg Working Group mailing list (<eref target="mailto:opsawg@ietf.org"
	/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/opsawg/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/opsawg/
	"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/mcr/iot-mud-dns-considerations"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<?line 82?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t><xref target="RFC8520"/> provides a standardized way to describe how a		<!--[rfced] Please clarify "a specific purpose device".
	specific purpose device makes use of Internet resources.		This term has not been used in past documents;
	Access Control Lists (ACLs) can be defined in an RFC 8520 Manufacturer Usage Des		perhaps it is in contrast to "a general-purpose device", a term
	cription (MUD) file that permit a device to access Internet resources by their D		used in RFC 8520. May it be rephrased as below, or
	NS names or IP addresses.</t>		does it mean the same as "a single-purpose device"?
	<t>Use of a DNS name rather than an IP address in an ACL has many advantag
	es: not only does the layer of indirection permit the mapping of a name to IP ad		Original:
	dress(es) to be changed over time, it also generalizes automatically to IPv4 and		[RFC8520] provides a standardized way to describe how a specific
	IPv6 addresses, as well as permitting a variety of load balancing strategies, i		purpose device makes use of Internet resources.
	ncluding multi-CDN deployments wherein load balancing can account for geography
	and load.</t>		Perhaps:
	<t>However, the use of DNS names has implications on how ACL are executed		[RFC8520] provides a standardized way to describe how a device
	at the MUD policy enforcement point (typically, a firewall).		for a specific purpose makes use of Internet resources.
	Concretely, the firewall has access only to the Layer 3 headers of the packet.		-->
	This includes the source and destination IP address, and if not encrypted by IPs		<t><xref target="RFC8520"/> provides a standardized way to describe how
	ec, the destination UDP or TCP port number present in the transport header.		a specific purpose device makes use of Internet resources. Access
	The DNS name is not present!</t>		Control Lists (ACLs) can be defined in a Manufacturer Usage Description
	<t>So in order to implement these name based ACLs, there must be a mapping		(MUD) file <xref target="RFC8520" format="default"/> that permits a
	between the names in the ACLs and IP addresses.</t>		device to access Internet resources by their DNS names or IP
	<t>In order for manufacturers to understand how to configure DNS associate		addresses.</t>
	d with name based ACLs, a model of how the DNS resolution will be done by MUD co		<t>The use of a DNS name rather than an IP address in an ACL has many
	ntrollers is necessary.		advantages: Not only does the layer of indirection permit the mapping of
	<xref target="mapping"/> models some good strategies that are used.</t>		a name to IP addresses to be changed over time, but it also generalizes
	<t>This model is non-normative: but is included so that IoT device manufac		automatically to IPv4 and IPv6 addresses as well as permits a
	turers can understand how the DNS will be used to resolve the names they use.</t		variety of load-balancing strategies, including multi-CDN deployments
	>		wherein load-balancing can account for geography and load.</t>
	<t>There are some ways of using DNS that will present problems for MUD con		<t>However, the use of DNS names has implications on how ACLs are
	trollers, which <xref target="dns-anti-p"/> explains.</t>		executed at the MUD policy enforcement point (typically, a firewall).
	<t><xref target="sec-priv-out"/> details how current trends in DNS resolut		Concretely, the firewall has access only to the Layer 3 headers of the
	ion such as public DNS servers, DNS over TLS (DoT) <xref target="RFC7858"/>, DNS		packet. This includes the source and destination IP addresses and, if not
	over HTTPS (DoH) <xref target="RFC8484"/>, or DNS over QUIC (DoQ) <xref target=		encrypted by IPsec, the destination UDP or TCP port number present in
	"RFC9250"/> can cause problems with the strategies employed.</t>		the transport header. The DNS name is not present!</t>
	<t>The core of this document, is <xref target="sec-reco"/>, which makes a		<t>So, in order to implement these name-based ACLs, there must be a
	series of recommendations ("best current practices") for manufacturers on how to		mapping between the names in the ACLs and IP addresses.</t>
	use DNS and IP addresses with MUD supporting IoT devices.</t>		<t>In order for manufacturers to understand how to configure DNS
	<t><xref target="sec-privacy"/> discusses a set of privacy issues that enc		associated with name-based ACLs, a model of how the DNS resolution will
	rypted DNS (DoT, DoH, for example) are frequently used to deal with.		be done by MUD controllers is necessary. <xref target="mapping"/>
	How these concerns apply to IoT devices located within a residence or enterprise		models some good strategies that could be used.</t>
	is a key concern.</t>		<t>This model is non-normative but is included so that IoT device
			manufacturers can understand how the DNS will be used to resolve the
			names they use.</t>
			<t>There are some ways of using DNS that will present problems for MUD
			controllers, which <xref target="dns-anti-p"/> explains.</t>
			<t><xref target="sec-priv-out"/> details how current trends in DNS
			resolution such as public DNS servers, DNS over TLS (DoT) <xref
			target="RFC7858"/>, DNS over HTTPS (DoH) <xref target="RFC8484"/>, or
			DNS over QUIC (DoQ) <xref target="RFC9250"/> can cause problems with the
			strategies employed.</t>
			<!--[rfced] Please clarify "with MUD supporting IoT devices".
			Does it mean (A) "with IoT devices that support MUD"
			or (B) "with MUD to support IoT devices" or otherwise?
			Original:
			The core of this document, is Section 6, which makes a series of
			recommendations ("best current practices") for manufacturers on how
			to use DNS and IP addresses with MUD supporting IoT devices.
			Perhaps (if A):
			The core of this document is Section 6, which makes a series of
			recommendations ("best current practices") for manufacturers on how
			to use DNS and IP addresses with IoT devices that support MUD.
			-->
			<t>The core of this document is <xref target="sec-reco"/>, which makes a
			series of recommendations ("best current practices") for manufacturers
			on how to use DNS and IP addresses with IoT devices described by MUD.</t>
			<t><xref target="sec-privacy"/> discusses a set of privacy issues that
			encrypted DNS (for example, DoT and DoH) are frequently used to deal
			with. How these concerns apply to IoT devices located within a
			residence or enterprise is a key concern.</t>
	<t><xref target="sec-security"/> also covers some of the negative outcomes should MUD/firewall managers and IoT manufacturers choose not to cooperate.</t>		<t><xref target="sec-security"/> also covers some of the negative outcomes should MUD/firewall managers and IoT manufacturers choose not to cooperate.</t>
	</section>		</section>
	<section anchor="Terminology">		<section anchor="Terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>This document makes use of terms defined in <xref target="RFC8520"/> an		<t>This document makes use of terms defined in <xref target="RFC8520"/>
	d <xref target="I-D.ietf-dnsop-rfc8499bis"/>.</t>		and <xref target="RFC9499"/>.</t>
	<t>The term "anti-pattern" comes from agile software design literature, as		<t>The term "anti-pattern" comes from agile software design literature,
	per <xref target="antipatterns"/>.</t>		as per <xref target="antipattern"/>.</t>
	<t>CDN refers to Content Distribution Networks, such as described by <xref		<t>"CDNs" refers to Content Distribution Networks, such as those described
	section="1.1" sectionFormat="comma" target="RFC6707"/>.</t>		in
			<xref section="1.1" sectionFormat="comma" target="RFC6707"/>.</t>
	</section>		</section>
	<section anchor="mapping">		<section anchor="mapping">
	<name>A model for MUD controller mapping of DNS names to addresses</name>		<name>A Model for MUD Controller Mapping of DNS Names to Addresses</name>
	<t>This section details a strategy that a MUD controller could take.		<t>This section details a strategy that a MUD controller could take.
	Within the limits of DNS use detailed in <xref target="sec-reco"/>, this process		Within the limits of the DNS use detailed in <xref target="sec-reco"/>,
	can work.		this process could work. The methods detailed in <xref
	The methods detailed in <xref target="failingstrategy"/> just will not work.</t>		target="failingstrategy"/> just will not work.</t>
	<t>The simplest successful strategy for translating DNS names for a MUD co		<t>The simplest successful strategy for a MUD controller to translate
	ntroller to take is to do a DNS lookup on the name (a forward lookup), and then		DNS names is to do a DNS lookup on the name (a forward lookup) and then
	use the resulting IP addresses to populate the actual ACLs.</t>		use the resulting IP addresses to populate the actual ACLs.</t>
	<t>There a number of possible failures, and the goal of this section is to
	explain how some common DNS usages may fail.</t>		<!--[rfced] May this be rephrased for simplicity?
			Original:
			The simplest successful strategy for translating DNS names for a MUD
			controller to take is to do a DNS lookup on the name ...
			Perhaps:
			The simplest successful strategy for a MUD controller
			to translate DNS names is to do a DNS lookup on the name ...
			-->
			<t>There are a number of possible failures, and the goal of this section i
			s
			to explain how some common DNS usages may fail.</t>
	<section anchor="non-deterministic-mappings">		<section anchor="non-deterministic-mappings">
	<name>Non-Deterministic Mappings</name>		<name>Non-Deterministic Mappings</name>
	<t>The most important one is that the mapping of the DNS names to IP add		<t>Most importantly, the mapping of the DNS names to IP addresses
	resses may be non-deterministic.</t>		could be non-deterministic.</t>
	<t><xref target="RFC1794"/> describes the very common mechanism that ret		<t><xref target="RFC1794"/> describes the very common mechanism that
	urns DNS A (or reasonably AAAA) records in a permuted order.		returns DNS A (or reasonably AAAA) records in a permuted order. This
	This is known as Round Robin DNS, and it has been used for many decades.		is known as "round-robin DNS" and has been used for many decades. The
	The historical intent is that the requestor will tend to use the first IP addres		historical intent is that the requestor will tend to use the first IP
	s that is returned.		address that is returned. As each query results in addresses being in a
	As each query results in addresses in a different ordering, the effect is to spl		different order, the effect is to split the load among many
	it the load among many servers.</t>		servers.</t>
	<t>This situation does not result in failures as long as all possible A/		<t>This situation does not result in failures as long as all possible
	AAAA records are returned.		A/AAAA records are returned. The MUD controller and the device get a
	The MUD controller and the device get a matching set, and the ACLs that are set		matching set, and the ACLs that are set up cover all
	up cover all possibilities.</t>		possibilities.</t>
	<t>There are a number of circumstances in which the list is not exhausti		<t>There are a number of circumstances in which the list is not
	ve.		exhaustive. The simplest is when the round-robin DNS does not return
	The simplest is when the round-robin does not return all addresses.		all addresses. This is routinely done by geographical DNS
	This is routinely done by geographical DNS load balancing systems: only the		load-balancing systems: Only the addresses that the balancing system
	addresses that the balancing system wishes to be used are returned.</t>		wishes to be used are returned.</t>
	<t>It can also happen if there are more addresses than will conveniently		<t>Failure can also occur if there are more addresses than what will
	fit into a DNS reply.		conveniently fit into a DNS reply. The reply will be marked as
	The reply will be marked as truncated.		truncated. (If DNSSEC resolution will be done, then the entire RR
	(If DNSSEC resolution will be done, then the entire RR must be retrieved over TC		must be retrieved over TCP (or using a larger EDNS(0) size) before
	P (or using a larger EDNS(0) size) before being validated)</t>		being validated.)</t>
	<t>However, in a geographical DNS load balancing system, different answe		<t>However, in a geographical DNS load-balancing system, different
	rs are given based upon the locality of the system asking.		answers are given based upon the locality of the system asking. There
	There may also be further layers of round-robin indirection.</t>		may also be further layers of round-robin indirection.</t>
	<t>Aside from the list of records being incomplete, the list may have ch		<t>Aside from the list of records being incomplete, the list may have
	anged between the time that the MUD controller did the lookup and the time that		changed between the time that the MUD controller did the lookup and
	the IoT device did the lookup, and this change can result in a failure for the A		the time that the IoT device did the lookup, and this change can
	CL to match.		result in a failure for the ACL to match. If the IoT device did not
	If the IoT device did not use the same recursive servers as the MUD controller,		use the same recursive servers as the MUD controller, then tailored
	then		DNS replies and/or truncated round-robin results could return a
	tailored DNS replies and/or truncated round-robin results could return a differe		different and non-overlapping set of addresses.</t>
	nt, and non-overlapping set of addresses.</t>		<t>In order to compensate for this, the MUD controller performs
	<t>In order to compensate for this, the MUD controller performs regular		regular DNS lookups in order to never have stale data. These lookups
	DNS lookups in order to never have stale data.		must be rate-limited to avoid excessive load on the DNS servers, and
	These lookups must be rate limited to avoid excessive load on the DNS servers,		it may be necessary to avoid local recursive resolvers. A MUD
	and it may be necessary to avoid local recursive resolvers.		controller that incorporates its own recursive caching DNS client will
	A MUD controller that incorporates its own recursive caching DNS client will be		be able to observe the TTL on the entries and cause them to expire
	able to observe the TTL on the entries, and expire them appropriately.		appropriately. This cache will last for at least some number of
	This cached will last for at least some number of minutes, up to some number of		minutes and up to some number of days (respecting the TTL), while the
	days (respecting the TTL), while the underlying DNS data can change at a higher		underlying DNS data can change at a higher frequency, providing
	frequency, providing different answers to different queries!</t>		different answers to different queries!</t>
	<t>A MUD controller that is aware of which recursive DNS server the IoT		<t>A MUD controller that is aware of which recursive DNS server the
	device will use can instead query that server on a periodic basis.		IoT device will use can instead query that server on a periodic basis.
	Doing so provides three advantages:</t>		Doing so provides three advantages:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1">
	<t>Any geographic load balancing will base the decision on the geolo		<li>
	cation of the recursive DNS server, and the recursive name server will provide t		<t>Any geographic load-balancing will base the decision on the
	he same answer to the MUD controller as to the IoT device.</t>		geolocation of the recursive DNS server, and the recursive name
			server will provide the same answer to the MUD controller as to
			the IoT device.</t>
	</li>		</li>
	<li>		<li>
	<t>The resulting name to IP address mapping in the recursive name se		<t>The resulting mapping (of name to IP address) in the recursive
	rver will be cached, and will remain the same for the entire advertised Time-To-		name server will be cached and will remain the same for the entire
	Live reported in the DNS query return.		advertised TTL reported in the DNS query return. This
	This also allows the MUD controller to avoid doing unnecessary queries.</t>		also allows the MUD controller to avoid doing unnecessary
			queries.</t>
	</li>		</li>
	<li>		<li>
	<t>if any addresses have been omitted in a round-robin DNS process,		<t>If any addresses have been omitted in a round-robin DNS
	the cache will have the same set of addresses that were returned.</t>		process, the cache will have the same set of addresses that were
			returned.</t>
	</li>		</li>
	</ol>		</ol>
	<t>The solution of using the same caching recursive resolver as the targ		<t>The solution of using the same caching recursive resolver as the
	et device is very simple when the MUD controller is located in a residential CPE		target device is very simple when the MUD controller is located in a
	device.		residential Customer Premises Equipment (CPE) device. The device is usu
	The device is usually also the policy enforcement point for the ACLs, and a cach		ally also the
	ing resolver is typically located on the same device.		policy-enforcement point for the ACLs, and a caching resolver is
	In addition to convenience, there is a shared fate advantage: as all three compo		typically located on the same device. In addition to convenience,
	nents are running on the same device, if the device is rebooted, clearing the ca		there is a shared fate advantage: As all three components are running
	che, then all three components will get restarted when the device is restarted.		on the same device, if the device is rebooted (which clears the cache),
	</t>		then all three components will get restarted when the device is
	<t>Where the solution is more complex and sometimes more fragile is when		restarted.</t>
	the MUD controller is located elsewhere in an Enterprise, or remotely in a clou		<t>The solution is more complex and sometimes more fragile when the
	d such as when a Software Defined Network (SDN) is used to manage the ACLs.		MUD controller is located elsewhere in an enterprise or remotely in a
	The DNS servers for a particular device may not be known to the MUD controller,		cloud, such as when a Software-Defined Network (SDN) is used to manage
	nor the MUD controller be even permitted to make recursive queries to that serve		the ACLs. The DNS servers for a particular device may not be known to
	r if it is known.		the MUD controller, and the MUD controller may not even be permitted
	In this case, additional installation specific mechanisms are probably needed		to make recursive queries to that server if it is known. In this
	to get the right view of the DNS.</t>		case, additional installation-specific mechanisms are probably needed
	<t>A critical failure can occur when the device makes a new DNS request		to get the right view of the DNS.</t>
	and		<t>A critical failure can occur when the device makes a new DNS
	receives a new set of IP addresses, but the MUD controller's copy of the		request and receives a new set of IP addresses, but the MUD
	addresses has not yet reached their time to live.		controller's copy of the addresses has not yet reached their TTL. In th
	In that case, the MUD controller still has the old address(es) implemented in		at case, the MUD controller still has the old addresses
	the ACLs, but the IoT device has a new address not previously returned to the		implemented in the ACLs, but the IoT device has a new address not
	MUD controller.		previously returned to the MUD controller. This can result in a
	This can result in a connectivity failure.</t>		connectivity failure.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="dns-anti-p">		<section anchor="dns-anti-p">
	<name>DNS and IP Anti-Patterns for IoT Device Manufacturers</name>		<name>DNS and IP Anti-Patterns for IoT Device Manufacturers</name>
	<t>In many design fields, there are good patterns that should be emulated,		<t>In many design fields, there are good patterns that should be
	and often there are patterns that should not be emulated.		emulated, and often there are patterns that should not be emulated. The
	The latter are called anti-patterns, as per <xref target="antipatterns"/>.</t>		latter are called anti-patterns, as per <xref
	<t>This section describes a number of things which IoT manufacturers have		target="antipattern"/>.</t>
	been observed to do in the field, each of which presents difficulties for MUD en		<t>This section describes a number of things that IoT manufacturers have
	forcement points.</t>		been observed to do in the field, each of which presents difficulties for
			MUD enforcement points.</t>
	<section anchor="inprotocol">		<section anchor="inprotocol">
	<name>Use of IP Address Literals</name>		<name>Use of IP Address Literals</name>
	<t>A common pattern for a number of devices is to look for firmware upda		<t>A common pattern for a number of devices is to look for firmware
	tes in a two-step process.		updates in a two-step process. An initial query is made (often over
	An initial query is made (often over HTTPS, sometimes with a POST, but the metho		HTTPS, sometimes with a POST, but the method is immaterial) to a
	d is immaterial) to a vendor system that knows whether an update is required.</t		vendor system that knows whether an update is required.</t>
	>		<t>The current firmware model of the device is sometimes provided, and
	<t>The current firmware model of the device is sometimes provided and th		then the vendor's authoritative server provides a determination if a
	en the vendor's authoritative server provides a determination if a new version i		new version is required and, if so, what version. In simpler cases,
	s required and, if so, what version.		an HTTPS endpoint is queried, which provides the name and URL of the
	In simpler cases, an HTTPS endpoint is queried which provides the name and URL o		most recent firmware.</t>
	f the most recent firmware.</t>		<t>The authoritative upgrade server then responds with a URL of a
	<t>The authoritative upgrade server then responds with a URL of a firmwa		firmware blob that the device should download and install. Best
	re blob that the device should download and install.		practice is that either firmware is signed internally <xref
	Best practice is that firmware is either signed internally (<xref target="RFC901		target="RFC9019"/> so that it can be verified, or a hash of the blob
	9"/>) so that it can be verified, or a hash of the blob is provided.</t>		is provided.</t>
	<t>An authoritative server might be tempted to provide an IP address lit		<t>An authoritative server might be tempted to provide an IP address
	eral inside the protocol.		literal inside the protocol. An argument for doing this is that it
	An argument for doing this is that it eliminates problems with firmware updates		eliminates problems with firmware updates that might be caused by a
	that might be caused by lack of DNS, or incompatibilities with DNS.		lack of DNS or by incompatibilities with DNS. For instance, a bug
	For instance a bug that causes interoperability issues with some recursive serve		that causes interoperability issues with some recursive servers would
	rs would become unpatchable for devices that were forced to use that recursive r		become unpatchable for devices that were forced to use that recursive
	esolver type.</t>		resolver type.</t>
	<t>But, there are several problems with the use of IP address literals f		<t>But, there are several problems with the use of IP address literals
	or the location of the firmware.</t>		for the location of the firmware.</t>
	<t>The first is that the update service server must decide whether to pr		<t>The first is that the update service server must decide whether to
	ovide an		provide an IPv4 or an IPv6 literal, assuming that only one URL can be
	IPv4 or an IPv6 literal, assuming that only one URL can be provided.		provided. A DNS name can contain both kinds of addresses and can
	A DNS name can contain both kinds of addresses, and can also contain many		also contain many different IP addresses of each kind.
	different IP addresses of each kind.		<!--[rfced] Please review; does the updated sentence convey the intended
	An update server might believe that if the connection was on IPv4, that an		meaning? It has been rephrased to avoid the use of two "but" phrases
	IPv4 literate would be acceptable, but due to NAT64 <xref target="RFC6146"/> a d		in a row. (Also, "literate" was changed to "literal".)
	evice with only IPv6
	connectivity will often be able to reach an IPv4 firmware update server by		Original:
	name (through DNS64 <xref target="RFC6147"/>), but not be able to reach arbitrar		An update
	y IPv4 address.</t>		server might believe that if the connection was on IPv4, that an IPv4
	<t>A MUD file definition for this access would need to resolve to the se		literate would be acceptable, but due to NAT64 [RFC6146] a device
	t of IP		with only IPv6 connectivity will often be able to reach an IPv4
	addresses that might be returned by the update server.		firmware update server by name (through DNS64 [RFC6147]), but not be
	This can be done with IP address literals in the MUD file, but this may		able to reach arbitrary IPv4 address.
	require continuing updates to the MUD file if the addresses change frequently.
	A DNS name in the MUD could resolve to the set of all possible IPv4 and IPv6		Current:
	addresses that would be used, with DNS providing a level of indirection that		An update
	obviates the need to update the MUD file itself.</t>		server might believe that if the connection were on IPv4, then an IPv4
	<t>A third problem involves the use of HTTPS.		literal would be acceptable. However, due to NAT64 [RFC6146], a
	It is often more difficult to get TLS certificates for an IP address, and so		device with only IPv6 connectivity will often be able to reach an
	it is less likely that the firmware download will be protected by TLS.		IPv4 firmware update server by name (through DNS64 [RFC6147]) but not
	An IP address literal in the TLS ServerNameIndicator <xref target="RFC6066"/>, m		be able to reach an arbitrary IPv4 address.
	ight not		-->
	provide enough context for a web server to distinguish which of potentially		An update
	many tenants, the client wishes to reach.		server might believe that if the connection were on IPv4, then an IPv4
	This then drives the use of an IP address per-tenant, and for IPv4 (at		literal would be acceptable. However, due to NAT64 <xref
	least), this is no longer a sustainable use of IP addresses.</t>		target="RFC6146"/>, a device with only IPv6 connectivity will often be
	<t>Finally, it is common in some Content Distribution Networks (CDNs) to		able to reach an IPv4 firmware update server by name (through DNS64
	use multiple layers of DNS CNAMEs in order to isolate the content-owner's namin		<xref target="RFC6147"/>) but not be able to reach an arbitrary IPv4
	g system from changes in how the distribution network is organized.</t>		address.</t>
	<t>When a name or address is returned within an update protocol for whic		<!--[rfced] May we change "A MUD file definition" to simply "A MUD file"?
	h a MUD		We see zero usage of "MUD file definition" in RFC 8520 or other RFCs.
	rule cannot be written, then the MUD controller is unable to authorize the
	connection.		Original:
	In order for the connection to be authorized, the set of names returned		A MUD file definition for this access would need to resolve ...
	within the update protocol needs to be known ahead of time, and must be from
	a finite set of possibilities.		Original:
	Such a set of names or addresses can be placed into the MUD file as an ACL in		A MUD file for this access would need to resolve ...
	advance, and the connections authorized.</t>		-->
			<t>A MUD file for this access would need to resolve to the
			set of IP addresses that might be returned by the update server. This
			can be done with IP address literals in the MUD file, but this may
			require continuing updates to the MUD file if the addresses change
			frequently. A DNS name in the MUD could resolve to the set of all
			possible IPv4 and IPv6 addresses that would be used, with DNS
			providing a level of indirection that obviates the need to update the
			MUD file itself.</t>
			<t>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 less
			likely that the firmware download will be protected by TLS. An IP
			address literal in the TLS ServerNameIndicator <xref
			target="RFC6066"/> might not provide enough context for a web server
			to distinguish which of the (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 no longer a sustainable use of IP
			addresses.</t>
			<t>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 changes in how the distribution network is
			organized.</t>
			<t>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
			to authorize the connection. In order for the connection to be
			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
			possibilities. Such a set of names or addresses can be placed into
			the MUD file as an ACL in advance, and the connections can be
			authorized.</t>
	</section>		</section>
	<section anchor="use-of-non-deterministic-dns-names-in-protocols">		<section anchor="use-of-non-deterministic-dns-names-in-protocols">
	<name>Use of Non-deterministic DNS Names in protocols</name>		<name>Use of Non-Deterministic DNS Names in Protocols</name>
	<t>A second pattern is for a control protocol to connect to a known HTTP		<t>A second pattern is for a control protocol to connect to a known
	endpoint.		HTTP endpoint. This is easily described in MUD. References within
	This is easily described in MUD.		that control protocol are made to additional content at other URLs.
	References within that control protocol are made to additional content at other		The values of those URLs do not fit any easily described pattern and
	URLs.		may point to arbitrary DNS names.</t>
	The values of those URLs do not fit any easily described pattern and may point a		<t>Those DNS names are often within some third-party CDN system or may
	t arbitrary DNS names.</t>		be arbitrary DNS names in a cloud-provider storage system (e.g., <xref
	<t>Those DNS names are often within some third-party CDN system, or may		target="AmazonS3"/> or <xref target="Akamai"/>). Some of the name
	be arbitrary DNS names in a cloud-provider storage system (e.g., <xref target="A		components may be specified by the third-party CDN provider.</t>
	mazonS3"/>, or <xref target="Akamai"/>).		<t>Such DNS names may be unpredictably chosen by the CDN and not the
	Some of the name components may be specified by the third party CDN provider.</t		device manufacturer and therefore impossible to insert into a MUD
	>		file. Implementation of the CDN system may also involve HTTP
	<t>Such DNS names may be unpredictably chosen by the CDN, and not the de		redirections to downstream CDN systems.</t>
	vice manufacturer, and so impossible to insert into a MUD file.		<t>Even if the CDN provider's chosen DNS names are deterministic, they
	Implementation of the CDN system may also involve HTTP redirections to downstrea		may change at a rate much faster than MUD files can be updated.</t>
	m CDN systems.</t>		<t>This situation applies to firmware updates but also applies to many
	<t>Even if the CDN provider's chosen DNS names are deterministic they ma		other kinds of content: video content, in-game content, etc.</t>
	y change at a rate much faster than MUD files can be updated.</t>		<t>A solution may be to use a deterministic DNS name within the
	<t>This situation applies to firmware updates, but also applies to many		control of the device manufacturer.
	other kinds of content: video content, in-game content, etc.</t>		<!--[rfced] Should "CDN vendor's DNS" be "CDN provider's DNS" here,
	<t>A solution may be to use a deterministic DNS name, within the control		because that phrase is used earlier within this section?
	of the device manufacturer.		(Note: The apostrophe was added because it seems possessive was intended.)
	The device manufacturer is asked to point a CNAME to the CDN, to a name that mig
	ht look like "g7.a.example", with the expectation that the CDN vendors DNS will		Original: the CDN vendors DNS will do all the appropriate work
	do all the appropriate work to geolocate the transfer.		Current: the CDN vendor's DNS will do all the appropriate work
	This can be fine for a MUD file, as the MUD controller, if located in the same g		Perhaps: the CDN provider's DNS will do all the appropriate work
	eography as the IoT device, can follow the CNAME, and can collect the set of res		-->
	ulting IP addresses, along with the TTL for each.		The device manufacturer is asked
	The MUD controller can then take charge of refreshing that mapping at intervals		to point a CNAME to the CDN, to a name that might look like
	driven by the TTL.</t>		"g7.a.example", with the expectation that the CDN provider's DNS will do
	<t>In some cases, a complete set of geographically distributed servers m		all the appropriate work to geolocate the transfer. This can be fine
	ay be known		for a MUD file, as the MUD controller, if located in the same
	ahead of time (or that it changes very slowly), and the device manufacturer can		geography as the IoT device, can follow the CNAME and collect the set
	list all those IP addresses in the DNS for the the name that it lists in the MUD		of resulting IP addresses along with the TTL for each. Then, the MUD
	file.		controller can take charge of refreshing that mapping at intervals
	As long as the active set of addresses used by the CDN is a strict subset of tha		driven by the TTL.</t>
	t list, then the geolocated name can be used for the content download itself.</t		<t>In some cases, a complete set of geographically distributed servers
	>		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 the
			name that it lists in the MUD file. As long as the active set of
			addresses used by the CDN is a strict subset of that list, then the
			geolocated name can be used for the content download itself.</t>
	</section>		</section>
	<section anchor="use-of-a-too-generic-dns-name">		<section anchor="use-of-a-too-generic-dns-name">
	<name>Use of a Too Generic DNS Name</name>		<name>Use of a Too Generic DNS Name</name>
	<t>Some CDNs make all customer content available at a single URL (such a		<t>Some CDNs make all customer content available at a single URL (such
	s "s3.example.com").		as "s3.example.com"). This seems to be ideal from a MUD point of
	This seems to be ideal from a MUD point of view: a completely predictable URL.</		view: a completely predictable URL.</t>
	t>		<t>The problem is that a compromised device could then connect to the
	<t>The problem is that a compromised device could then connect to the co		contents of any bucket, potentially attacking the data from other
	ntents of any bucket,		customers.</t>
	potentially attacking the data from other customers.</t>		<t>Exactly what the risk is depends upon what the other customers are
	<t>Exactly what the risk is depends upon what the other customers are do		doing: It could be limited to simply causing a distributed
	ing: it could be limited to simply causing a distributed denial-of-service attac		denial-of-service attack resulting in high costs to those customers,
	k resulting in high costs to those customers, or such an attack could potentiall		or such an attack could potentially include writing
	y include writing content.</t>		content.</t>
	<t>Amazon has recognized the problems associated with this practice, and		<t>Amazon has recognized the problems associated with this practice
	aims to change it to a virtual hosting model, as per <xref target="awss3virtual		and aims to change it to a virtual hosting model, as per <xref
	hosting"/>.</t>		target="awss3virtualhosting"/>.</t>
	<t>The MUD ACLs provide only for permitting end points (hostnames and po		<t>The MUD ACLs provide only for permitting endpoints (hostnames and
	rts), but do not filter URLs (nor could filtering be enforced within HTTPS).</t>		ports) but do not filter URLs (nor could filtering be enforced within
			HTTPS).</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-priv-out">		<section anchor="sec-priv-out">
	<name>DNS Privacy and Outsourcing versus MUD Controllers</name>		<name>DNS Privacy and Outsourcing versus MUD Controllers</name>
	<t><xref target="RFC7858"/> and <xref target="RFC8094"/> provide for DoT a		<t><xref target="RFC7858"/> and <xref target="RFC8094"/> provide for DoT
	nd DoH.		and DoH. <xref target="RFC9499"/> details the terms. But, even with
	<xref target="I-D.ietf-dnsop-rfc8499bis"/> details the terms.		the unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS
	But, even with the unencrypted DNS (a.k.a. Do53), it is possible to outsource DN		queries to other public services, such as those operated by Google,
	S queries to other public services, such as those operated by Google, CloudFlar		CloudFlare, Verisign, etc.</t>
	e, Verisign, etc.</t>		<t>For some users and classes of devices, revealing the DNS queries to
	<t>For some users and classes of devices, revealing the DNS queries to tho		those outside entities may constitute a privacy concern. For other
	se outside entities may constitute a privacy concern.		users, the use of an insecure local resolver may constitute a privacy
	For other users the use of an insecure local resolver may constitute a privacy c		concern.</t>
	oncern.</t>		<t>As described in <xref target="mapping"/>, the MUD controller
	<t>As described above in <xref target="mapping"/> the MUD controller needs		needs to have access to the same resolver or resolvers as the IoT device.
	to have access to the same resolver(s) as the IoT device.		If the
	If the IoT device does not use the DNS servers provided to it via DHCP or Router		IoT device does not use the DNS servers provided to it via DHCP or
	Advertisements, then the MUD controller will need to be told which servers will		Router Advertisements, then the MUD controller will need to be told
	in fact be used.		which servers will in fact be used. As yet, there is no protocol to do
	As yet, there is no protocol to do this, but future work could provide this as a		this, but future work could provide this as an extension to MUD.</t>
	n extension to MUD.</t>		<t>Until such time as such a protocol exists, the best practice is for
	<t>Until such time as such a protocol exists, the best practice is for the		the IoT device to always use the DNS servers provided by DHCP or Router
	IoT device to always use the DNS servers provided by DHCP or Router Advertiseme		Advertisements.</t>
	nts.</t>
	</section>		</section>
	<section anchor="sec-reco">		<section anchor="sec-reco">
	<name>Recommendations To IoT Device Manufacturers on MUD and DNS Usage</na		<name>Recommendations to IoT Device Manufacturers on MUD and DNS Usage</na
	me>		me>
	<t>Inclusion of a MUD file with IoT devices is operationally quite simple.		<t>Inclusion of a MUD file with IoT devices is operationally quite
	It requires only a few small changes to the DHCP client code to express the		simple. It requires only a few small changes to the DHCP client code to
	MUD URL.		express the MUD URL. It can even be done without code changes via the
	It can even be done without code changes via the use of a QR code affixed to the		use of a QR code affixed to the packaging (see <xref
	packaging (see <xref target="RFC9238"/>)</t>		target="RFC9238"/>).</t>
	<t>The difficult part is determining what to put into the MUD file itself.		<t>The difficult part is determining what to put into the MUD file
	There are currently tools that help with the definition and analysis of MUD file		itself. There are currently tools that help with the definition and
	s, see <xref target="mudmaker"/>.		analysis of MUD files; see <xref target="mudmaker"/>.
	The remaining difficulty is now the actual list of expected connections to put i		<!--[rfced] May "now" be removed from these two sentences,
	n the MUD file.		or do you want to use a different phrase? (The preceding sentence is
	An IoT manufacturer must now spend some time reviewing the network communication		included for context.)
	s by their device.</t>
	<t>This document discusses a number of challenges that occur relating to h		Original:
	ow DNS requests are made and resolved, and the goal of this section is to make r		There are currently tools that help with the definition and
	ecommendations on how to modify IoT systems to work well with MUD.</t>		analysis of MUD files, see [mudmaker]. The remaining difficulty is
			now the actual list of expected connections to put in the MUD file.
			An IoT manufacturer must now spend some time reviewing the network
			communications by their device.
			Perhaps (if removing two instances of "now"):
			There are currently tools that help with the definition and
			analysis of MUD files; see [mudmaker]. The remaining difficulty is
			the actual list of expected connections to put in the MUD file.
			An IoT manufacturer must spend some time reviewing the network
			communications by their device.
			-->
			The remaining
			difficulty is the actual list of expected connections to put in the
			MUD file. An IoT manufacturer must spend some time reviewing the
			network communications by their device.</t>
			<t>This document discusses a number of challenges that occur relating to
			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 with
			MUD.</t>
	<section anchor="consistently-use-dns">		<section anchor="consistently-use-dns">
	<name>Consistently use DNS</name>		<name>Consistently Use DNS</name>
	<t>For the reasons explained in <xref target="inprotocol"/>, the most im		<t>For the reasons explained in <xref target="inprotocol"/>, the most
	portant recommendation is to avoid using IP address literals in any protocol.		important recommendation is to avoid using IP address literals in any
	DNS names should always be used.</t>		protocol. DNS names should always be used.</t>
	</section>		</section>
	<section anchor="use-primary-dns-names-controlled-by-the-manufacturer">		<section anchor="use-primary-dns-names-controlled-by-the-manufacturer">
	<name>Use Primary DNS Names Controlled By The Manufacturer</name>		<name>Use Primary DNS Names Controlled by the Manufacturer</name>
	<t>The second recommendation is to allocate and use DNS names within zon		<t>The second recommendation is to allocate and use DNS names within
	es controlled by the manufacturer.		zones controlled by the manufacturer. These DNS names can be
	These DNS names can be populated with an alias (see <xref target="I-D.ietf-dnsop		populated with an alias (see <xref target="RFC9499" section="2"
	-rfc8499bis"/> section 2) that points to the production system.		sectionFormat="comma"/>) that points to the production system.
	Ideally, a different name is used for each logical function, allowing for differ		Ideally, a different name is used for each logical function, allowing
	ent rules in the MUD file to be enabled and disabled.</t>		different rules in the MUD file to be enabled and disabled.</t>
	<t>While it used to be costly to have a large number of aliases in a web		<t>While it used to be costly to have a large number of aliases in a
	server certificate, this is no longer the case.		web server certificate, this is no longer the case. Wildcard
	Wildcard certificates are also commonly available which allow for an infinite nu		certificates are also commonly available; they allow for an infinite
	mber of possible DNS names.</t>		number of possible DNS names.</t>
	</section>		</section>
	<section anchor="use-content-distribution-network-with-stable-dns-names">		<section anchor="use-content-distribution-network-with-stable-dns-names">
	<name>Use Content-Distribution Network with Stable DNS Names</name>		<name>Use a Content Distribution Network with Stable DNS Names</name>
	<t>When aliases point to a CDN, prefer stable DNS names that point to ap		<t>When aliases point to a CDN, give preference to stable DNS names
	propriately load balanced targets.		that point to appropriately load-balanced targets. CDNs that employ
	CDNs that employ very low time-to-live (TTL) values for DNS make it harder for t		very low TTL values for DNS make it harder for the MUD
	he MUD controller to get the same answer as the IoT Device.		controller to get the same answer as the IoT device. A CDN that
	A CDN that always returns the same set of A and AAAA records, but permutes them		always returns the same set of A and AAAA records, but permutes them to
	to provide the best one first provides a more reliable answer.</t>		provide the best one first, provides a more reliable answer.</t>
	</section>		</section>
	<section anchor="tailorednames">		<section anchor="tailorednames">
	<name>Do Not Use Tailored Responses to answer DNS Names</name>		<name>Do Not Use Tailored Responses to Answer DNS Names</name>
	<t><xref target="RFC7871"/> defines the edns-client-subnet (ECS) EDNS0 o		<t><xref target="RFC7871"/> defines the edns-client-subnet (ECS) EDNS0
	ption, and explains		option and explains how authoritative servers sometimes answer queries
	how authoritative servers sometimes answer queries differently based upon the		differently based upon the IP address of the end system making the
	IP address of the end system making the request.		request. Ultimately, the decision is based upon some topological
	Ultimately, the decision is based upon some topological notion of closeness.		notion of closeness. This is often used to provide tailored responses
	This is often used to provide tailored responses to clients, providing them		to clients, providing them with a geographically advantageous
	with a geographically advantageous answer.</t>		answer.</t>
	<t>When the MUD controller makes its DNS query, it is critical that it r		<t>When the MUD controller makes its DNS query, it is critical that it
	eceive		receives an answer that is based upon the same topological decision as
	an answer which is based upon the same topological decision as when the IoT		when the IoT device makes its query.</t>
	device makes its query.</t>
	<t>There are probably ways in which the MUD controller could use the		<t>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 treatment		edns-client-subnet option to make a query that would get the same
	as when the IoT device makes its query. If this worked then it would receive		treatment as when the IoT device makes its query. If this worked,
	the same answer as the IoT device.</t>		then it would receive the same answer as the IoT device.</t>
	<t>In practice it could be quite difficult if the IoT device uses a diff		<t>In practice it could be quite difficult if the IoT device uses a
	erent		different Internet connection, a different firewall, or a different
	Internet connection, a different firewall, or a different recursive DNS		recursive DNS server. The edns-client-server might be ignored or
	server.		overridden by any of the DNS infrastructure.</t>
	The edns-client-server might be ignored or overridden by any of the DNS infrastr		<t>Some tailored responses might only reorder the replies so that the
	ucture.</t>		most preferred address is first. Such a system would be acceptable if
	<t>Some tailored responses might only re-order the replies so that the m		the MUD controller had a way to know that the list was complete.</t>
	ost		<t>But, due to the above problems, a strong recommendation is to avoid
	preferred address is first.		using tailored responses as part of the DNS names in the MUD file.</t>
	Such a system would be acceptable if the MUD controller had a way to know
	that the list was complete.</t>
	<t>But, due to the above problems, a strong recommendation is to avoid u
	sing
	tailored responses as part of the DNS names in the MUD file.</t>
	</section>		</section>
	<section anchor="prefer-dns-servers-learnt-from-dhcprouter-advertisements"		<section anchor="prefer-dns-servers-learned-from-dhcprouter-advertisements
	>		">
	<name>Prefer DNS Servers Learnt From DHCP/Router Advertisements</name>		<name>Prefer DNS Servers Learned from DHCP/Router Advertisements</name>
	<t>The best practice is for IoT Devices to do DNS with the DHCP provided		<t>The best practice is for IoT devices to do DNS with the
	DNS servers, or DNS servers learnt from Router Advertisements <xref target="RFC		DHCP-provided DNS servers or with DNS servers learned from Router
	8106"/>.</t>		Advertisements <xref target="RFC8106"/>.</t>
	<t>The ADD WG has written <xref target="RFC9463"/> and <xref target="RFC		<t>The Adaptive DNS Discovery (ADD) Working Group has written <xref targ
	9462"/> to provide information to end devices on how to find locally provisioned		et="RFC9462"/> and <xref
	secure/private DNS servers.</t>		target="RFC9463"/> to provide information to end devices on how to
	<t>Use of public resolvers instead of the locally provided DNS resolver,		find locally provisioned secure/private DNS servers.</t>
	whether Do53, DoQ, DoT or DoH is discouraged.</t>		<t>Use of public resolvers instead of the locally provided DNS
	<t>Some manufacturers would like to have a fallback to using a public re		resolver, whether Do53, DoQ, DoT, or DoH, is discouraged.</t>
	solver to mitigate against local misconfiguration.		<t>Some manufacturers would like to have a fallback to using a public
	There are a number of reasons to avoid this, detailed in <xref target="tailoredn		resolver to mitigate against local misconfiguration. There are a
	ames"/>.		number of reasons to avoid this, detailed in <xref
	The public resolver might not return the same tailored names that the MUD contro		target="tailorednames"/>. The public resolver might not return the
	ller would get.</t>		same tailored names that the MUD controller would get.</t>
	<t>It is recommended that use of non-local resolvers is only done when t		<t>It is recommended that non-local resolvers are only used when
	he locally provided resolvers provide no answers to any queries at all, and do s		the locally provided resolvers provide no answers to any queries at
	o repeatedly.		all and do so repeatedly. The status of the operator-provided
	The status of the operator provided resolvers needs to be re-evaluated on a peri		resolvers needs to be re-evaluated on a periodic basis.</t>
	odic basis.</t>		<!--[rfced] FYI, this sentence has been updated to use singular "resolver"
	<t>Finally, if a device will ever attempt to use a non-local resolvers,		and "destination". Please let us know if that was not the intention.
	then the address of that resolver needs to be listed in the MUD file as destinat
	ions that are to be permitted.		Original:
	This needs to include the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that		Finally, if a device will ever attempt to use a non-local resolvers,
	will be used as well.</t>		then the address of that resolver needs to be listed in the MUD file
			as destinations that are to be permitted.
			Current:
			Finally, if a device will ever attempt to use a non-local resolver,
			then the address of that resolver needs to be listed in the MUD file
			as a destination that is to be permitted.
			-->
			<t>Finally, if a device will ever attempt to use non-local resolvers,
			then the addresses of those resolvers need to be listed in the MUD
			file as destinations that are to be permitted. This needs to include
			the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be
			used as well.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="interactions-with-mdns-and-dnssd">		<section anchor="interactions-with-mdns-and-dnssd">
	<name>Interactions with mDNS and DNSSD</name>		<name>Interactions with mDNS and DNS-SD</name>
	<t>Unicast DNS requests are not the only way to map names to IP addresses.		<t>Unicast DNS requests are not the only way to map names to IP
	IoT devices might also use mDNS <xref target="RFC6762"/>, both to be discovered		addresses. IoT devices might also use Multicast DNS (mDNS) <xref target="
	by other devices, and also to discover other devices.</t>		RFC6762"/>,
	<t>mDNS replies include A and AAAA records, and it is conceivable that the		both to be discovered by other devices and also to discover other
	se replies contain addresses which are not local to the link on which they are m		devices.</t>
	ade.		<t>mDNS replies include A and AAAA records, and it is conceivable that
	This could be the result of another device which contains malware.		these replies contain addresses that are not local to the link on which
	An unsuspecting IoT device could be led to contact some external host as a resul		they are made. This could be the result of another device that contains
	t.		malware. An unsuspecting IoT device could be led to contact some
	Protecting against such things is one of the benefits of MUD.</t>		external host as a result. Protecting against such things is one of the
	<t>In the unlikely case that the external host has been listed as a legiti		benefits of MUD.</t>
	mate destination in a MUD file, then communication will continue as expected.		<t>In the unlikely case that the external host has been listed as a
	As an example of this, an IoT device might look for a name like "update.local" i		legitimate destination in a MUD file, communication will
	n order to find a source of firmware updates.		continue as expected. As an example, an IoT device might look
	It could be led to connect to some external host that was listed as "update.exam		for a name like "update.local" in order to find a source of firmware
	ple" in the MUD file.		updates. It could be led to connect to some external host that was
	This should work fine if the name "update.example" does not require any kind of		listed as "update.example" in the MUD file. This should work fine if
	tailored reply.</t>		the name "update.example" does not require any kind of tailored
	<t>In residential networks there has typically not been more than one netw		reply.</t>
	ork (although this is changing through work like <xref target="I-D.ietf-snac-sim		<t>In residential networks, there has typically not been more than one
	ple"/>), but on campus or enterprise networks, having more than one network is n		network (although this is changing through work like <xref
	ot unusual.		target="I-D.ietf-snac-simple"/>), but on campus or enterprise networks,
	In such networks, mDNS is being replaced with DNS-SD <xref target="RFC8882"/>, a		having more than one network is not unusual. In such networks, mDNS is
	nd in such a situation, connections could be initiated to other parts of the net		being replaced with DNS-based Service Discovery (DNS-SD) <xref target="RFC
	work.		8882"/>, and in such a
	Such connections might traverse the MUD policy enforcement point (an intra-depar		situation, connections could be initiated to other parts of the network.
	tment firewall), and could very well be rejected because the MUD controller did		Such connections might traverse the MUD policy enforcement point (an
	not know about that interaction.</t>		intra-department firewall) and could very well be rejected because the
	<t><xref target="RFC8250"/> includes a number of provisions for controllin		MUD controller did not know about that interaction.</t>
	g internal communications, including		<t><xref target="RFC8250"/> includes a number of provisions for
	complex communications like same manufacturer ACLs.		controlling internal communications, including complex communications
	To date, this aspect of MUD has been difficult to describe.		like same manufacturer ACLs. To date, this aspect of MUD has been
	This document does not consider internal communications to be in scope.</t>		difficult to describe. This document does not consider internal
			communications to be in scope.</t>
	</section>		</section>
	<section anchor="sec-privacy">		<section anchor="sec-privacy">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>The use of non-local DNS servers exposes the list of DNS names resolved		<t>The use of non-local DNS servers exposes the list of DNS names
	to a third party, including passive eavesdroppers.</t>		resolved to a third party, including passive eavesdroppers.</t>
	<t>The use of DoT and DoH eliminates the threat from passive eavesdropping		<t>The use of DoT and DoH eliminates the threat from passive
	, but still exposes the list to the operator of the DoT or DoH server.		eavesdropping but still exposes the list to the operator of the DoT or
	There are additional methods to help preserve privacy, such as described by <xre		DoH server. There are additional methods to help preserve privacy, such
	f target="RFC9230"/>.</t>		as that described by <xref target="RFC9230"/>.</t>
	<t>The use of unencrypted (Do53) requests to a local DNS server exposes th		<t>The use of unencrypted (Do53) requests to a local DNS server exposes
	e list to any internal passive eavesdroppers, and for some situations that may b		the list to any internal passive eavesdroppers. For some situations,
	e significant, particularly if unencrypted Wi-Fi is used.</t>		that may be significant, particularly if unencrypted WiFi is used.</t>
	<t>Use of Encrypted DNS connection to a local DNS recursive resolver is th		<t>Use of an encrypted DNS connection to a local DNS recursive resolver
	e preferred choice.</t>		is the preferred choice.</t>
	<t>IoT devices that reach out to the manufacturer at regular intervals to		<t>IoT devices that reach out to the manufacturer at regular intervals
	check for firmware updates are informing passive eavesdroppers of the existence		to check for firmware updates are informing passive eavesdroppers of the
	of a specific manufacturer's device being present at the origin location.</t>		existence of a specific manufacturer's device being present at the
	<t>Identifying the IoT device type empowers the attacker to launch targete		origin location.</t>
	d attacks		<t>Identifying the IoT device type empowers the attacker to launch
	to the IoT device (e.g., Attacker can take advantage of any known vulnerability		targeted attacks to the IoT device (e.g., the attacker can take
	on the device).</t>		advantage of any known vulnerability on the device).</t>
	<t>While possession of a Large (Kitchen) Appliance at a residence may be u		<t>While possession of a "large kitchen appliance" at a residence may be
	ninteresting to most, possession of intimate personal devices (e.g., "sex toys")		uninteresting to most, possession of intimate personal devices (e.g.,
	may be a cause for embarrassment.</t>		"sex toys") may be a cause for embarrassment.</t>
	<t>IoT device manufacturers are encouraged to find ways to anonymize their		<t>IoT device manufacturers are encouraged to find ways to anonymize
	update queries.		their update queries. For instance, contracting out the update
	For instance, contracting out the update notification service to a third party t		notification service to a third party that deals with a large variety of
	hat deals with a large variety of devices would provide a level of defense again		devices would provide a level of defense against passive eavesdropping.
	st passive eavesdropping.		Other update mechanisms should be investigated, including use of
	Other update mechanisms should be investigated, including use of DNSSEC signed T		DNSSEC-signed TXT records with current version information. This would
	XT records with current version information.		permit DoT or DoH to convey the update notification in a private
	This would permit DoT or DoH to convey the update notification in a private fash		fashion. This is particularly powerful if a local recursive DoT server
	ion.		is used, which then communicates using DoT over the Internet.</t>
	This is particularly powerful if a local recursive DoT server is used, which the		<t>The more complex case of <xref target="inprotocol"/> postulates that
	n communicates using DoT over the Internet.</t>		the version number needs to be provided to an intelligent agent that can
	<t>The more complex case of <xref target="inprotocol"/> postulates that th		decide the correct route to do upgrades. <xref target="RFC9019"/>
	e version number needs to be provided to an intelligent agent that can decide th		provides a wide variety of ways to accomplish the same thing without
	e correct route to do upgrades.		having to divulge the current version number.</t>
	<xref target="RFC9019"/> provides a wide variety of ways to accomplish the same
	thing without having to divulge the current version number.</t>
	</section>		</section>
	<section anchor="sec-security">		<section anchor="sec-security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>This document deals with conflicting Security requirements:</t>		<t>This document deals with conflicting security requirements:</t>
	<ol spacing="normal" type="1"><li>		<ul spacing="normal">
	<t>devices which an operator wants to manage using <xref target="RFC85		<li>
	20"/></t>		<t>devices that an operator wants to manage using <xref target="RFC852
			0"/></t>
	</li>		</li>
	<li>		<li>
	<t>requirements for the devices to get access to network resources tha		<t>requirements for the devices to get access to network resources
	t may be critical to their continued safe operation.</t>		that may be critical to their continued safe operation</t>
	</li>		</li>
	</ol>		</ul>
	<t>This document takes the view that the two requirements do not need to b		<t>This document takes the view that the two requirements do not need to
	e in conflict, but resolving the conflict requires careful planning on how the D		be in conflict, but resolving the conflict requires careful planning on
	NS can be safely and effectively		how the DNS can be safely and effectively be used by MUD controllers and
	used by MUD controllers and IoT devices.</t>		IoT devices.</t>
	<t>When an IoT device with an inaccurate MUD file is deployed into a netwo		<t>When an IoT device with an inaccurate MUD file is deployed into a
	rk that uses MUD, there is a significant possibility that the device will cause		network that uses MUD, there is a significant possibility that the
	a spurious security exception to be raised.		device will cause a spurious security exception to be raised. There is
	There is significant evidence that such spurious exceptions cause significant ov		significant evidence that such spurious exceptions can cause significant
	erhead to personnel.		overhead to personnel. In particular, repeated spurious exceptions are
	In particular, repeated spurious exceptions are likely to cause the entire excep		likely to cause the entire exception process to be turned off. When MUD
	tion process to be turned off. When MUD alerts are turned off, then even legiti		alerts are turned off, then even legitimate exceptions are ignored.
	mate exceptions are ignored.		This is very much a Boy Who Calls Wolf <xref target="boywhocriedwolf"/>
	This is very much a Boy Who Calls Wolf <xref target="boywhocriedwolf"/> situatio		situation.</t>
	n.</t>		<t>In order to avoid this situation, and for MUD alerts to be given
	<t>In order to avoid this situation, and for MUD alerts to be given approp		appropriate attention, it is key that IoT device manufacturers create
	riate attention, it is key that IoT device manufacturers create accurate MUD fil		accurate MUD files. This may require some significant thought and even
	es.		rework of key systems so that all network access required by the IoT
	This may require some significant thought, even rework of key systems, so that a		device can be described by a MUD file. This level of informed
	ll network access required by the IoT device can be described by a MUD file.		cooperation within the IoT device vendor and with MUD controller
	This level of informed cooperation within the IoT device vendor and with MUD con		manufacturers is key to getting significant return on investment from
	troller manufacturers is key to getting significant return on investment from MU		MUD.</t>
	D.</t>		<t>Manufacturers are encouraged to write MUD files that are good enough
	<t>Manufacturers are encouraged to write MUD files that are good enough, r		rather than perfect. If in doubt, they should write MUD files that are
	ather than perfect.		somewhat more permissive if the files result in no spurious alerts.</t>
	If in doubt, they should write MUD files that are somewhat more permissive if it
	results in no spurious alerts.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-snac-simple" to="AUTO-STUB-NETWORKS"/>
	<references anchor="sec-combined-references">		<references anchor="sec-combined-references">
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC8520" target="https://www.rfc-editor.org/info/rfc8		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	520" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml">		520.xml"/>
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
	<title>Manufacturer Usage Description Specification</title>		794.xml"/>
	<author fullname="E. Lear" initials="E." surname="Lear"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<author fullname="R. Droms" initials="R." surname="Droms"/>		499.xml"/>
	<author fullname="D. Romascanu" initials="D." surname="Romascanu"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<date month="March" year="2019"/>		019.xml"/>
	<abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<t>This memo specifies a component-based architecture for Manufact		094.xml"/>
	urer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end de		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	vices to signal to the network what sort of access and network functionality the		250.xml"/>
	y require to properly function. The initial focus is on access control. Later wo
	rk can delve into other aspects.</t>
	<t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP option
	s, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate exten
	sion, and a means to sign and verify the descriptions.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8520"/>
	<seriesInfo name="DOI" value="10.17487/RFC8520"/>
	</reference>
	<reference anchor="RFC1794" target="https://www.rfc-editor.org/info/rfc1
	794" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1794.xml">
	<front>
	<title>DNS Support for Load Balancing</title>
	<author fullname="T. Brisco" initials="T." surname="Brisco"/>
	<date month="April" year="1995"/>
	<abstract>
	<t>This RFC is meant to first chronicle a foray into the IETF DNS
	Working Group, discuss other possible alternatives to provide/simulate load bala
	ncing support for DNS, and to provide an ultimate, flexible solution for providi
	ng DNS support for balancing loads of many types. This memo provides information
	for the Internet community. This memo does not specify an Internet standard of
	any kind.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="1794"/>
	<seriesInfo name="DOI" value="10.17487/RFC1794"/>
	</reference>
	<reference anchor="I-D.ietf-dnsop-rfc8499bis" target="https://datatracke
	r.ietf.org/doc/html/draft-ietf-dnsop-rfc8499bis-10" xml:base="https://bib.ietf.o
	rg/public/rfc/bibxml3/reference.I-D.ietf-dnsop-rfc8499bis.xml">
	<front>
	<title>DNS Terminology</title>
	<author fullname="Paul E. Hoffman" initials="P. E." surname="Hoffman
	">
	<organization>ICANN</organization>
	</author>
	<author fullname="Kazunori Fujiwara" initials="K." surname="Fujiwara
	">
	<organization>Japan Registry Services Co., Ltd.</organization>
	</author>
	<date day="25" month="September" year="2023"/>
	<abstract>
	<t>The Domain Name System (DNS) is defined in literally dozens of
	different RFCs. The terminology used by implementers and developers of DNS proto
	cols, and by operators of DNS systems, has changed in the decades since the DNS
	was first defined. This document gives current definitions for many of the terms
	used in the DNS in a single document. This document updates RFC 2308 by clarify
	ing the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding
	multiple terms and clarifications. Comprehensive lists of changed and new defini
	tions can be found in Appendices A and B.</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc8499bis-1
	0"/>
	</reference>
	<reference anchor="RFC9019" target="https://www.rfc-editor.org/info/rfc9
	019" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9019.xml">
	<front>
	<title>A Firmware Update Architecture for Internet of Things</title>
	<author fullname="B. Moran" initials="B." surname="Moran"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<author fullname="D. Brown" initials="D." surname="Brown"/>
	<author fullname="M. Meriac" initials="M." surname="Meriac"/>
	<date month="April" year="2021"/>
	<abstract>
	<t>Vulnerabilities in Internet of Things (IoT) devices have raised
	the need for a reliable and secure firmware update mechanism suitable for devic
	es with resource constraints. Incorporating such an update mechanism is a fundam
	ental requirement for fixing vulnerabilities, but it also enables other importan
	t capabilities such as updating configuration settings and adding new functional
	ity.</t>
	<t>In addition to the definition of terminology and an architectur
	e, this document provides the motivation for the standardization of a manifest f
	ormat as a transport-agnostic means for describing and protecting firmware updat
	es.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9019"/>
	<seriesInfo name="DOI" value="10.17487/RFC9019"/>
	</reference>
	<reference anchor="RFC8094" target="https://www.rfc-editor.org/info/rfc8
	094" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml">
	<front>
	<title>DNS over Datagram Transport Layer Security (DTLS)</title>
	<author fullname="T. Reddy" initials="T." surname="Reddy"/>
	<author fullname="D. Wing" initials="D." surname="Wing"/>
	<author fullname="P. Patil" initials="P." surname="Patil"/>
	<date month="February" year="2017"/>
	<abstract>
	<t>DNS queries and responses are visible to network elements on th
	e path between the DNS client and its server. These queries and responses can co
	ntain privacy-sensitive information, which is valuable to protect.</t>
	<t>This document proposes the use of Datagram Transport Layer Secu
	rity (DTLS) for DNS, to protect against passive listeners and certain active att
	acks. As latency is critical for DNS, this proposal also discusses mechanisms to
	reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechan
	ism runs over port 853.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8094"/>
	<seriesInfo name="DOI" value="10.17487/RFC8094"/>
	</reference>
	<reference anchor="RFC8250" target="https://www.rfc-editor.org/info/rfc8
	250" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8250.xml">
	<front>
	<title>IPv6 Performance and Diagnostic Metrics (PDM) Destination Opt
	ion</title>
	<author fullname="N. Elkins" initials="N." surname="Elkins"/>
	<author fullname="R. Hamilton" initials="R." surname="Hamilton"/>
	<author fullname="M. Ackermann" initials="M." surname="Ackermann"/>
	<date month="September" year="2017"/>
	<abstract>
	<t>To assess performance problems, this document describes optiona
	l headers embedded in each packet that provide sequence numbers and timing infor
	mation as a basis for measurements. Such measurements may be interpreted in real
	time or after the fact. This document specifies the Performance and Diagnostic
	Metrics (PDM) Destination Options header. The field limits, calculations, and us
	age in measurement of PDM are included in this document.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8250"/>
	<seriesInfo name="DOI" value="10.17487/RFC8250"/>
	</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="AmazonS3" target="https://en.wikipedia.org/wiki/Amazo
	n_S3">		<!-- [rfced] FYI, for the references to Wikipedia pages - [AmazonS3], [Akamai]
			[boywhocriedwolf] - we have updated the data to the most current revision
			and updated the URL to the date-specific URL. Please let us know if you
			prefer otherwise.
			-->
			<reference anchor="AmazonS3" target="https://en.wikipedia.org/w/index.ph
			p?title=Amazon_S3&amp;oldid=1280379498">
	<front>		<front>
	<title>Amazon S3</title>		<title>Amazon S3</title>
	<author>		<author>
	<organization/>		<organization>Wikipedia</organization>
	</author>		</author>
	<date year="2019"/>		<date day="14" month="March" year="2025"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="Akamai" target="https://en.wikipedia.org/wiki/Akamai_
	Technologies">		<reference anchor="Akamai" target="https://en.wikipedia.org/w/index.php?
			title=Akamai_Technologies&amp;oldid=1277665363">
	<front>		<front>
	<title>Akamai</title>		<title>Akamai Technologies</title>
	<author>		<author>
	<organization/>		<organization>Wikipedia</organization>
	</author>		</author>
	<date year="2019"/>		<date day="26" month="February" year="2025"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="mudmaker" target="https://mudmaker.org">		<reference anchor="mudmaker" target="https://mudmaker.org">
	<front>		<front>
	<title>Mud Maker</title>		<title>MUD Maker</title>
	<author>		<author>
	<organization/>		<organization/>
	</author>		</author>
	<date year="2019"/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="antipatterns" target="https://www.agilealliance.org/g
	lossary/antipattern">		<reference anchor="antipattern" target="https://www.agilealliance.org/gl
			ossary/antipattern">
	<front>		<front>
	<title>AntiPattern</title>		<title>AntiPattern</title>
	<author>		<author>
	<organization/>		<organization>Agile Alliance</organization>
	</author>		</author>
	<date year="2021" month="July" day="12"/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="boywhocriedwolf" target="https://en.wikipedia.org/wik
	i/The_Boy_Who_Cried_Wolf">		<reference anchor="boywhocriedwolf" target="https://en.wikipedia.org/w/i
			ndex.php?title=The_Boy_Who_Cried_Wolf&amp;oldid=1274257821">
	<front>		<front>
	<title>Boy who Cried Wolf</title>		<title>The Boy Who Cried Wolf</title>
	<author>		<author>
	<organization/>		<organization>Wikipedia</organization>
	</author>		</author>
	<date year="2024" month="August" day="15"/>		<date year="2025" month="February" day="6"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="awss3virtualhosting" target="https://techmonitor.ai/t echonology/cloud/aws-s3-path-deprecation">		<reference anchor="awss3virtualhosting" target="https://techmonitor.ai/t echonology/cloud/aws-s3-path-deprecation">
	<front>		<front>
	<title>Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation at L ast Minute</title>		<title>Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation at L ast Minute</title>
	<author>		<author>
	<organization/>		<organization>Tech Monitor</organization>
	</author>
	<date year="2021" month="July" day="12"/>
	</front>
	</reference>
	<reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7
	858" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml">
	<front>
	<title>Specification for DNS over Transport Layer Security (TLS)</ti
	tle>
	<author fullname="Z. Hu" initials="Z." surname="Hu"/>
	<author fullname="L. Zhu" initials="L." surname="Zhu"/>
	<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	<author fullname="D. Wessels" initials="D." surname="Wessels"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="May" year="2016"/>
	<abstract>
	<t>This document describes the use of Transport Layer Security (TL
	S) to provide privacy for DNS. Encryption provided by TLS eliminates opportuniti
	es for eavesdropping and on-path tampering with DNS queries in the network, such
	as discussed in RFC 7626. In addition, this document specifies two usage profil
	es for DNS over TLS and provides advice on performance considerations to minimiz
	e overhead from using TCP and TLS with DNS.</t>
	<t>This document focuses on securing stub-to-recursive traffic, as
	per the charter of the DPRIVE Working Group. It does not prevent future applica
	tions of the protocol to recursive-to-authoritative traffic.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7858"/>
	<seriesInfo name="DOI" value="10.17487/RFC7858"/>
	</reference>
	<reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8
	484" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml">
	<front>
	<title>DNS Queries over HTTPS (DoH)</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="P. McManus" initials="P." surname="McManus"/>
	<date month="October" year="2018"/>
	<abstract>
	<t>This document defines a protocol for sending DNS queries and ge
	tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an H
	TTP exchange.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8484"/>
	<seriesInfo name="DOI" value="10.17487/RFC8484"/>
	</reference>
	<reference anchor="RFC9250" target="https://www.rfc-editor.org/info/rfc9
	250" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml">
	<front>
	<title>DNS over Dedicated QUIC Connections</title>
	<author fullname="C. Huitema" initials="C." surname="Huitema"/>
	<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	<date month="May" year="2022"/>
	<abstract>
	<t>This document describes the use of QUIC to provide transport co
	nfidentiality for DNS. The encryption provided by QUIC has similar properties to
	those provided by TLS, while QUIC transport eliminates the head-of-line blockin
	g issues inherent with TCP and provides more efficient packet-loss recovery than
	UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) s
	pecified in RFC 7858, and latency characteristics similar to classic DNS over UD
	P. This specification describes the use of DoQ as a general-purpose transport fo
	r DNS and includes the use of DoQ for stub to recursive, recursive to authoritat
	ive, and zone transfer scenarios.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9250"/>
	<seriesInfo name="DOI" value="10.17487/RFC9250"/>
	</reference>
	<reference anchor="RFC6707" target="https://www.rfc-editor.org/info/rfc6
	707" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml">
	<front>
	<title>Content Distribution Network Interconnection (CDNI) Problem S
	tatement</title>
	<author fullname="B. Niven-Jenkins" initials="B." surname="Niven-Jen
	kins"/>
	<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur
	"/>
	<author fullname="N. Bitar" initials="N." surname="Bitar"/>
	<date month="September" year="2012"/>
	<abstract>
	<t>Content Delivery Networks (CDNs) provide numerous benefits for
	cacheable content: reduced delivery cost, improved quality of experience for End
	Users, and increased robustness of delivery. For these reasons, they are freque
	ntly used for large-scale content delivery. As a result, existing CDN Providers
	are scaling up their infrastructure, and many Network Service Providers (NSPs) a
	re deploying their own CDNs. It is generally desirable that a given content item
	can be delivered to an End User regardless of that End User's location or attac
	hment network. This is the motivation for interconnecting standalone CDNs so the
	y can interoperate as an open content delivery infrastructure for the end-to-end
	delivery of content from Content Service Providers (CSPs) to End Users. However
	, no standards or open specifications currently exist to facilitate such CDN Int
	erconnection.</t>
	<t>The goal of this document is to outline the problem area of CDN
	Interconnection for the IETF CDNI (CDN Interconnection) working group. This doc
	ument is not an Internet Standards Track specification; it is published for info
	rmational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6707"/>
	<seriesInfo name="DOI" value="10.17487/RFC6707"/>
	</reference>
	<reference anchor="RFC6146" target="https://www.rfc-editor.org/info/rfc6
	146" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml">
	<front>
	<title>Stateful NAT64: Network Address and Protocol Translation from
	IPv6 Clients to IPv4 Servers</title>
	<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
	<author fullname="P. Matthews" initials="P." surname="Matthews"/>
	<author fullname="I. van Beijnum" initials="I." surname="van Beijnum
	"/>
	<date month="April" year="2011"/>
	</front>
	<seriesInfo name="RFC" value="6146"/>
	<seriesInfo name="DOI" value="10.17487/RFC6146"/>
	</reference>
	<reference anchor="RFC6147" target="https://www.rfc-editor.org/info/rfc6
	147" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml">
	<front>
	<title>DNS64: DNS Extensions for Network Address Translation from IP
	v6 Clients to IPv4 Servers</title>
	<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
	<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
	<author fullname="P. Matthews" initials="P." surname="Matthews"/>
	<author fullname="I. van Beijnum" initials="I." surname="van Beijnum
	"/>
	<date month="April" year="2011"/>
	<abstract>
	<t>DNS64 is a mechanism for synthesizing AAAA records from A recor
	ds. DNS64 is used with an IPv6/IPv4 translator to enable client-server communica
	tion between an IPv6-only client and an IPv4-only server, without requiring any
	changes to either the IPv6 or the IPv4 node, for the class of applications that
	work through NATs. This document specifies DNS64, and provides suggestions on ho
	w it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TR
	ACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6147"/>
	<seriesInfo name="DOI" value="10.17487/RFC6147"/>
	</reference>
	<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6
	066" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml">
	<front>
	<title>Transport Layer Security (TLS) Extensions: Extension Definiti
	ons</title>
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
	rd"/>
	<date month="January" year="2011"/>
	<abstract>
	<t>This document provides specifications for existing TLS extensio
	ns. It is a companion document for RFC 5246, "The Transport Layer Security (TLS)
	Protocol Version 1.2". The extensions specified are server_name, max_fragment_l
	ength, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_reque
	st. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6066"/>
	<seriesInfo name="DOI" value="10.17487/RFC6066"/>
	</reference>
	<reference anchor="RFC9238" target="https://www.rfc-editor.org/info/rfc9
	238" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9238.xml">
	<front>
	<title>Loading Manufacturer Usage Description (MUD) URLs from QR Cod
	es</title>
	<author fullname="M. Richardson" initials="M." surname="Richardson"/
	>
	<author fullname="J. Latour" initials="J." surname="Latour"/>
	<author fullname="H. Habibi Gharakheili" initials="H." surname="Habi
	bi Gharakheili"/>
	<date month="May" year="2022"/>
	<abstract>
	<t>This informational document details a protocol to load Manufact
	urer Usage Description (MUD) definitions from RFC 8520 for devices that do not h
	ave them integrated.</t>
	<t>This document is published to inform the Internet community of
	this mechanism to allow interoperability and to serve as a basis of other standa
	rds work if there is interest.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9238"/>
	<seriesInfo name="DOI" value="10.17487/RFC9238"/>
	</reference>
	<reference anchor="RFC7871" target="https://www.rfc-editor.org/info/rfc7
	871" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml">
	<front>
	<title>Client Subnet in DNS Queries</title>
	<author fullname="C. Contavalli" initials="C." surname="Contavalli"/
	>
	<author fullname="W. van der Gaast" initials="W." surname="van der G
	aast"/>
	<author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
	<author fullname="W. Kumari" initials="W." surname="Kumari"/>
	<date month="May" year="2016"/>
	<abstract>
	<t>This document describes an Extension Mechanisms for DNS (EDNS0)
	option that is in active use to carry information about the network that origin
	ated a DNS query and the network for which the subsequent response can be cached
	. Since it has some known operational and privacy shortcomings, a revision will
	be worked through the IETF for improvement.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7871"/>
	<seriesInfo name="DOI" value="10.17487/RFC7871"/>
	</reference>
	<reference anchor="RFC8106" target="https://www.rfc-editor.org/info/rfc8
	106" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml">
	<front>
	<title>IPv6 Router Advertisement Options for DNS Configuration</titl
	e>
	<author fullname="J. Jeong" initials="J." surname="Jeong"/>
	<author fullname="S. Park" initials="S." surname="Park"/>
	<author fullname="L. Beloeil" initials="L." surname="Beloeil"/>
	<author fullname="S. Madanapalli" initials="S." surname="Madanapalli
	"/>
	<date month="March" year="2017"/>
	<abstract>
	<t>This document specifies IPv6 Router Advertisement (RA) options
	(called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recur
	sive Server Addresses and a DNS Search List to IPv6 hosts.</t>
	<t>This document, which obsoletes RFC 6106, defines a higher defau
	lt value of the lifetime of the DNS RA options to reduce the likelihood of expir
	y of the options on links with a relatively high rate of packet loss.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8106"/>
	<seriesInfo name="DOI" value="10.17487/RFC8106"/>
	</reference>
	<reference anchor="RFC9463" target="https://www.rfc-editor.org/info/rfc9
	463" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml">
	<front>
	<title>DHCP and Router Advertisement Options for the Discovery of Ne
	twork-designated Resolvers (DNR)</title>
	<author fullname="M. Boucadair" initials="M." role="editor" surname=
	"Boucadair"/>
	<author fullname="T. Reddy.K" initials="T." role="editor" surname="R
	eddy.K"/>
	<author fullname="D. Wing" initials="D." surname="Wing"/>
	<author fullname="N. Cook" initials="N." surname="Cook"/>
	<author fullname="T. Jensen" initials="T." surname="Jensen"/>
	<date month="November" year="2023"/>
	<abstract>
	<t>This document specifies new DHCP and IPv6 Router Advertisement
	options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS,
	and DNS over QUIC). Particularly, it allows a host to learn an Authentication D
	omain Name together with a list of IP addresses and a set of service parameters
	to reach such encrypted DNS resolvers.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9463"/>
	<seriesInfo name="DOI" value="10.17487/RFC9463"/>
	</reference>
	<reference anchor="RFC9462" target="https://www.rfc-editor.org/info/rfc9
	462" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml">
	<front>
	<title>Discovery of Designated Resolvers</title>
	<author fullname="T. Pauly" initials="T." surname="Pauly"/>
	<author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
	<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
	<author fullname="P. McManus" initials="P." surname="McManus"/>
	<author fullname="T. Jensen" initials="T." surname="Jensen"/>
	<date month="November" year="2023"/>
	<abstract>
	<t>This document defines Discovery of Designated Resolvers (DDR),
	a set of mechanisms for DNS clients to use DNS records to discover a resolver's
	encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner
	is referred to as a "Designated Resolver". These mechanisms can be used to move
	from unencrypted DNS to encrypted DNS when only the IP address of a resolver is
	known. These mechanisms are designed to be limited to cases where Unencrypted D
	NS Resolvers and their Designated Resolvers are operated by the same entity or c
	ooperating entities. It can also be used to discover support for encrypted DNS p
	rotocols when the name of an Encrypted DNS Resolver is known.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9462"/>
	<seriesInfo name="DOI" value="10.17487/RFC9462"/>
	</reference>
	<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
	762" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
	<front>
	<title>Multicast DNS</title>
	<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
	<author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
	<date month="February" year="2013"/>
	<abstract>
	<t>As networked devices become smaller, more portable, and more ub
	iquitous, the ability to operate with less configured infrastructure is increasi
	ngly important. In particular, the ability to look up DNS resource record data t
	ypes (including, but not limited to, host names) in the absence of a conventiona
	l managed DNS server is useful.</t>
	<t>Multicast DNS (mDNS) provides the ability to perform DNS-like o
	perations on the local link in the absence of any conventional Unicast DNS serve
	r. In addition, Multicast DNS designates a portion of the DNS namespace to be fr
	ee for local use, without the need to pay any annual fee, and without the need t
	o set up delegations or otherwise configure a conventional DNS server to answer
	for those names.</t>
	<t>The primary benefits of Multicast DNS names are that (i) they r
	equire little or no administration or configuration to set them up, (ii) they wo
	rk when no infrastructure is present, and (iii) they work during infrastructure
	failures.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6762"/>
	<seriesInfo name="DOI" value="10.17487/RFC6762"/>
	</reference>
	<reference anchor="I-D.ietf-snac-simple" target="https://datatracker.iet
	f.org/doc/html/draft-ietf-snac-simple-05" xml:base="https://bib.ietf.org/public/
	rfc/bibxml3/reference.I-D.ietf-snac-simple.xml">
	<front>
	<title>Automatically Connecting Stub Networks to Unmanaged Infrastru
	cture</title>
	<author fullname="Ted Lemon" initials="T." surname="Lemon">
	<organization>Apple Inc.</organization>
	</author>
	<author fullname="Jonathan Hui" initials="J." surname="Hui">
	<organization>Google LLC</organization>
	</author>		</author>
	<date day="8" month="July" year="2024"/>		<date year="2020" month="September" day="24"/>
	<abstract>
	<t>This document describes a set of practices for connecting stub
	networks to adjacent infrastructure networks. This is applicable in cases such a
	s constrained (Internet of Things) networks where there is a need to provide fun
	ctional parity of service discovery and reachability between devices on the stub
	network and devices on an adjacent infrastructure link (for example, a home net
	work).</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-snac-simple-05"/>
	</reference>
	<reference anchor="RFC8882" target="https://www.rfc-editor.org/info/rfc8
	882" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8882.xml">
	<front>
	<title>DNS-Based Service Discovery (DNS-SD) Privacy and Security Req
	uirements</title>
	<author fullname="C. Huitema" initials="C." surname="Huitema"/>
	<author fullname="D. Kaiser" initials="D." surname="Kaiser"/>
	<date month="September" year="2020"/>
	<abstract>
	<t>DNS-SD (DNS-based Service Discovery) normally discloses informa
	tion about devices offering and requesting services. This information includes h
	ostnames, network parameters, and possibly a further description of the correspo
	nding service instance. Especially when mobile devices engage in DNS-based Servi
	ce Discovery at a public hotspot, serious privacy problems arise. We analyze the
	requirements of a privacy-respecting discovery service.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8882"/>
	<seriesInfo name="DOI" value="10.17487/RFC8882"/>
	</reference>
	<reference anchor="RFC9230" target="https://www.rfc-editor.org/info/rfc9
	230" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9230.xml">
	<front>
	<title>Oblivious DNS over HTTPS</title>
	<author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
	<author fullname="P. McManus" initials="P." surname="McManus"/>
	<author fullname="T. Pauly" initials="T." surname="Pauly"/>
	<author fullname="T. Verma" initials="T." surname="Verma"/>
	<author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>This document describes a protocol that allows clients to hide
	their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH
	) messages. This improves privacy of DNS operations by not allowing any one serv
	er entity to be aware of both the client IP address and the content of DNS queri
	es and answers.</t>
	<t>This experimental protocol has been developed outside the IETF
	and is published here to guide implementation, ensure interoperability among imp
	lementations, and enable wide-scale experimentation.</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="9230"/>
	<seriesInfo name="DOI" value="10.17487/RFC9230"/>
	</reference>		</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			858.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			484.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			250.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			707.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			146.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			147.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			066.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			238.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			871.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			106.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			463.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			462.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			762.xml"/>
			<!-- [I-D.ietf-snac-simple] IESG State: I-D Exists as of 02/26/25 -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			ietf-snac-simple.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			882.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			230.xml"/>
	</references>		</references>
	</references>		</references>
	<?line 468?>		<?line 468?>
	<section anchor="failingstrategy">		<section anchor="failingstrategy">
	<name>A Failing Strategy --- Anti-Patterns</name>		<name>A Failing Strategy: Anti-Patterns</name>
	<t>Attempts to map IP addresses to DNS names in real time often fails for		<t>Attempts to map IP addresses to DNS names in real time often fail for a
	a number of reasons:</t>		number of reasons:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1">
	<t>it can not be done fast enough,</t>		<li>
			<t>It can not be done fast enough.</t>
	</li>		</li>
	<li>		<li>
	<t>it reveals usage patterns of the devices,</t>		<t>It reveals usage patterns of the devices.</t>
	</li>		</li>
	<li>		<li>
	<t>the mappings are often incomplete,</t>		<t>The mappings are often incomplete.</t>
	</li>		</li>
	<li>		<li>
	<t>Even if the mapping is present, due to virtual hosting, it may not		<t>Even if the mapping is present, due to virtual hosting, it may
	map back to the name used in the ACL.</t>		not map back to the name used in the ACL.</t>
	</li>		</li>
	</ol>		</ol>
	<t>This is not a successful strategy: for reasons explained below.</t>
			<t>This is not a successful strategy for the reasons explained below.</t>
	<section anchor="too-slow">		<section anchor="too-slow">
	<name>Too Slow</name>		<name>Too Slow</name>
	<t>Mappings of IP addresses to DNS names requires a DNS lookup in the in		<t>Mappings of IP addresses to DNS names require a DNS lookup in the
	-addr.arpa or ip6.arpa space.		in-addr.arpa or ip6.arpa space. For a cold DNS cache, this will
	For a cold DNS cache, this will typically require 2 to 3 NS record lookups to lo		typically require 2 to 3 NS record lookups to locate the DNS server
	cate the DNS server that holds the information required. At 20 to 100 ms per ro		that holds the information required. At 20 to 100 ms per round trip,
	und trip, this easily adds up to significant time before the packet that caused		this easily adds up to a significant amount of time before the packet
	the lookup can be released.</t>		that caused the lookup can be released.</t>
	<t>While subsequent connections to the same site (and subsequent packets		<t>While subsequent connections to the same site (and subsequent
	in the same flow) will not be affected if the results are cached, the effects w		packets in the same flow) will not be affected if the results are
	ill be felt.		cached, the effects will be felt. The ACL results can be cached for a
	The ACL results can be cached for a period of time given by the TTL of the DNS r		period of time given by the TTL of the DNS results, but the DNS lookup
	esults, but the DNS lookup must be repeated, e.g, in a few hours or days,when th		must be repeated, e.g., in a few hours or days, when the cached binding
	e cached IP address to name binding expires.</t>		(of IP
			address to name) expires.</t>
	</section>		</section>
	<section anchor="reveals-patterns-of-usage">		<section anchor="reveals-patterns-of-usage">
	<name>Reveals Patterns of Usage</name>		<name>Reveals Patterns of Usage</name>
	<t>By doing the DNS lookups when the traffic occurs, then a passive atta		<t>By doing the DNS lookups when the traffic occurs, then a passive
	cker can see when the device is active, and may be able to derive usage patterns		attacker can see when the device is active and may be able to derive
	. They could determine when a home was occupied or not. This does not require		usage patterns. They could determine when a home was occupied or not.
	access to all on-path data, just to the DNS requests to the bottom level of the		This does not require access to all on-path data, just to the DNS
	DNS tree.</t>		requests to the bottom level of the DNS tree.</t>
	</section>		</section>
	<section anchor="mappings-are-often-incomplete">		<section anchor="mappings-are-often-incomplete">
	<name>Mappings Are Often Incomplete</name>		<name>Mappings Are Often Incomplete</name>
	<t>An IoT manufacturer with a cloud service provider that fails to inclu		<t>An IoT manufacturer with a cloud service provider that fails to
	de an A or AAAA record as part of their forward name publication will find that		include an A or AAAA record as part of their forward name publication
	the new server is simply not used.		will find that the new server is simply not used. The operational
	The operational feedback for that mistake is immediate.		feedback for that mistake is immediate. The same is not true for
	The same is not true for reverse DNS mappings: they can often be incomplete or i		reverse DNS mappings: They can often be incomplete or incorrect for
	ncorrect for months or even years without visible effect on operations.</t>		months or even years without a visible effect on operations.</t>
	<t>IoT manufacturer cloud service providers often find it difficult to u		<t>IoT manufacturer cloud service providers often find it difficult to
	pdate reverse DNS maps in a timely fashion, assuming that they can do it at all.		update reverse DNS maps in a timely fashion, assuming that they can do
	Many cloud based solutions dynamically assign IP addresses to services, often as		it at all. Many cloud-based solutions dynamically assign IP addresses
	the service grows and shrinks, reassigning those IP addresses to other services		to services, often as the service grows and shrinks, reassigning those
	quickly.		IP addresses to other services quickly. The use of HTTP 1.1 Virtual
	The use of HTTP 1.1 Virtual Hosting may allow addresses and entire front-end sys		Hosting may allow addresses and entire front-end systems to be reused
	tems to be re-used dynamically without even reassigning the IP addresses.</t>		dynamically without even reassigning the IP addresses.</t>
	<t>In some cases there are multiple layers of CNAME between the original		<t>In some cases, there are multiple layers of CNAME between the
	name and the target service name.		original name and the target service name. This is often due to a
	This is often due to a load balancing layer in the DNS, followed by a load balan		load-balancing layer in the DNS followed by a load-balancing layer at
	cing layer at the HTTP level.</t>		the HTTP level.</t>
	<t>The reverse DNS mapping for the IP address of the load balancer usual		<t>The reverse DNS mapping for the IP address of the load balancer
	ly does not change.		usually does not change. If hundreds of web services are funneled
	If hundreds of web services are funneled through the load balancer, it would req		through the load balancer, it would require hundreds of PTR records to
	uire hundreds of PTR records to be deployed.		be deployed. This would easily exceed the UDP/DNS and EDNS0 limits
	This would easily exceed the UDP/DNS and EDNS0 limits, and require all queries t		and require all queries to use TCP, which would further slow
	o use TCP, which would further slow down loading of the records.</t>		down loading of the records.</t>
	<t>The enumeration of all services/sites that have been at that load bal		<t>The enumeration of all services/sites that have been at that
	ancer might also constitute a security concern.		load balancer might also constitute a security concern. To limit
	To limit churn of DNS PTR records, and reduce failures of the MUD ACLs, operator		the churn of DNS PTR records and reduce failures of the MUD ACLs,
	s would want to add all possible DNS names for each reverse DNS mapping, whethe		operators would want to add all possible DNS names for each reverse
	r or not the DNS load balancing in the forward DNS space lists that end-point at		DNS mapping, whether or not the DNS load-balancing in the forward DNS
	that moment.</t>		space lists that endpoint at that moment.</t>
	</section>		</section>
	<section anchor="forward-dns-names-can-have-wildcards">		<section anchor="forward-dns-names-can-have-wildcards">
	<name>Forward DNS Names Can Have Wildcards</name>		<name>Forward DNS Names Can Have Wildcards</name>
	<t>In some large hosting providers content is hosted through a domain na		<t>In some large hosting providers, content is hosted through a domain
	me that is published as a DNS wildcard (and uses a wildcard certificate).		name that is published as a DNS wildcard (and uses a wildcard
	For instance, github.io, which is used for hosted content, including the Editors		certificate).
	' copy of internet drafts stored on github, does not actually publish any DNS na
	mes.		<!--[rfced] Please clarify "the Editors' copy of internet drafts".
	Instead, a wildcard exists to answer all potential DNS names: requests are route		What is this referring to? If this is referring to I-Ds created
	d appropriate once they are received.</t>		using the i-d template build system, then perhaps "including the
			Editors' copies of some Internet-Drafts that are stored on GitHub".
			Original:
			For instance, github.io, which is used for hosted
			content, including the Editors' copy of internet drafts stored on
			github, does not actually publish any DNS names.
			Current:
			For instance, github.io, which is used for hosted
			content, including the Editors' copy of Internet-Drafts stored on
			GitHub, does not actually publish any DNS names.
			-->
			For instance, github.io, which is used for hosting
			content, including the Editors' copy of Internet-Drafts stored on
			GitHub, does not actually publish any DNS names. Instead, a wildcard
			exists to answer all potential DNS names: Requests are routed
			appropriately once they are received.</t>
	<t>This kind of system works well for self-managed hosted content.		<t>This kind of system works well for self-managed hosted content.
	However, while it is possible to insert up to a few dozen PTR records, many thou		However, while it is possible to insert up to a few dozen PTR records,
	sand entries are not possible, nor is it possible to deal with the unlimited (in		many thousands of entries are not possible, nor is it possible to deal
	finite) number of possibilities that a wildcard supports.</t>		with the unlimited (infinite) number of possibilities that a wildcard
	<t>It would be therefore impossible for the PTR reverse lookup to ever w		supports.</t>
	ork with these wildcard DNS names.</t>		<t>Therefore, it would be impossible for the PTR reverse lookup to
			ever work with these wildcard DNS names.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">		<section anchor="contributors" numbered="false" toc="include">
	<name>Contributors</name>		<name>Contributors</name>
	<contact initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">		<contact initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
	<organization>Nokia</organization>		<organization>Nokia</organization>
	<address>		<address>
	</address>		</address>
	</contact>		</contact>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA5V9WZfbRpLuO34FWn5w1bkktXqrlzvVKrutM7JarSqP7psP
	CCRJjEAkB0uVaB399xtfLJkJkOWZ8TnToyKJXCIjI75YsVwus6EeGneV//Pg
	umKofVs0+Wvf9nWlf/f5xnf5773L/Sa/eXeb123+xt/lN+6+Ll2fFet15+6v
	8v1YLWs/LKu2zypftsWeRq26YjMsazdslv7QFw/bZfKzZTmZZ/n8pyyrD91V
	PnRjP7x49uynZy+yonNFsro+e9jSn+9vrz/+I//ou091u83/0fnxkH16uMrf
	tIPrWjcsbzBxVhbDVb4uD1l2qK9y+u+bvCzafKTNFF1XHPOLepMXTZMfXX+Z
	0zZ3Rb/Ld65zWZ4PvrzCF/TP3ndD5zb9FQ9RuU0xNkNPv7Dvj3v5Wv8cirZa
	Fo1vHW/GZVkxDjvfXWXZkuhHP/xtlX+oy13RVb1v6REh12/4yDXTr3xHO76l
	EV2zp8Xf+s3wQFTh3WM2ty/qhuhfdv8HhP633n66Kosw38dV/r6IE310tf7N
	o/86Fg/0yZ0rd61v/LZ2ycAPddPUxX51KFr60b/t+Ler0u+zrPXdno7l3l3R
	zz/88vrH7148038+/+GnV1egFliGzqet6H/XxDv9eDgQOelXb5Y3K2YN4gV/
	WHab8sdXP/20rnsd4qdnz3+inf/+5u76w+tfdYZnNCyxSbtJp77eF3/69vYl
	/k0HJxz9RD7Nb18+kY+LbuuIH57shuHQXz196trVQ/2pPriqLlZEh6f466k8
	9Yc9VRUDjfWCloJ5PhVEk9ks/Nn/bgp+5I+U3Gcmo5uyLz65bjrdb2OV/4aP
	H5nRnsJsZwYt2qE+FANuSX91foSHh4dVsa0bV+Dc29LxwreN7/uiOz5NRngy
	JQR98T79wiZ+8Xz57Ifl8xcZfbr2x4edL7vaVQ++2TyyhPNku9u5P/7uj398
	3Pk/XmOEPz7SENNF0Pc5TZDz93n8Pqzl1fLZj8vn32EtxUPfv7yvu2Esmp3v
	BxIlU1rf+IcWl3zY0W2rO/ro+uMtCb6mOPb5t7TX3fJ2ODbuW+Ix+vjQuZKF
	VF4M+duiH+g+t+PgHjmpgY5/79t68N2qqPlPz+xwfFo2fqye0vqW/cvlAfNU
	cfTHiEvSdOjq9Th4Zhm56Hd1N+6LxvUkMvIPrqqOduff+U81yYfs3rUjXyK5
	7SKm/w33EpSnz7f1sBvXLGCeQnJDgp9Kb5I0y2VerPuhK8ohy+52dZ+THhj3
	rh1IZA40ep9Pn6Gf+3HId/4hCG4oGXq03fb5BWmZS3qS1QzL7Dfvs6KqOtf3
	9AFJOZYt2Ge/ovkc/YLGL8Ha+dqRgCIpXxL986LPaegHkpe0PUzuO/xiS9KI
	6Nr4I5QICZcc8otuVztuaA9j56D3iq2js+2JZQ98the//X6DZW1qOjreBXEI
	0943ulqalpZMi8qum94viH9SWuB69nmHBdLflZKCRn7YuZa3BYLQoNhy2CHU
	Ls2cb+hiYmRQe19XVUPK5RuQr/PVWGKsLPvyRWXx16/5ofP3RHGil6glUiv1
	n3Q1Hkj70RwV72zteE76ycGV9aYu88PYHTzNrxuSNY8CAsJZ0Un4sSuxnmve
	MZAD0+Ft3ZN+vLh+/Zb0KlTu2gnJaOYam/xfkhu7JjLSvaLz29cDLVVXRnsQ
	ap9ZVr4+4u7WXUJGUvJv3ueBjYiSCm2K8KOcOIQwAObjpcbf69ppW0AKRJX2
	SF/dk0ikZZOWbT0xcNsc6bBpKogNEhU0Eg1ftxVJED4g2wO+3xeHA7iPF8CT
	04bihBfAJfQJkY8QQbsl8vl7LK3eu0UOOhCD5VvXElc3dK50zHT/oRhLkt5H
	Gez+FXMV/eP7uPEFbsWDI+xD/18WBAFIq7gvSHYORyyp8UWVr4uGtAC+w90e
	HNQVzd2WzVjh0z1hoXr5+uadXiYweQ9m7hyRazYEeIHOi/DAwLhy6/y2Kw67
	Iy8RP6YT+dU/ONrlgik0RuQpJwjK1/tDU5fx6oB7cSrARe6zw62vIIUxAG7N
	wdPPj7kDbCgdX8ODr+l/L4bjQWhFBCE269wD/XG5yoiTy84NDl9gFPuKp1eO
	46NW/fCWD/olgceC5FuPJePjQ1F+csNKxKHQTDlDeJS3TR8R7UV1xLNf8HcE
	UMFVjlZzPGBXxNNv3veulGWlj/5+8x7sfff6fQ6Elbfjfk1rIsXRY8N0GHiC
	zrDt+XtZKovOyPu0TMynD/0ty249nvRdBbbzTHkh4MASlx9aFz2tDLedV0WH
	sCcED64tAoevSQI7J2sIEg1/4DFl0Mm9fGOzgk/2iZRgiUuAkv41JOKSZPCm
	3tIPeDNF3/uyLkCxB1Jgp+uklXnCyTgoHkCJAOHRjExPAF8WXITjQXYwkgr6
	BqsAqRwYgWDRioSu7pSELo/c0xHTnFvvq+TmiBQDnxJjg9mZM2QpTPt2GVF1
	Tto8j4xD43h5HgZYEM0pZdi8mZFGd2bbwbygF+/03iUHQv864mteFU4Ry+RN
	PADxEKXGHkeJ0XgZPKTxF2maNbGG2IszWi1IHpBNk+dfvgA6AEMuD0Qo9/nQ
	FGSgrKC0iKmXh66+XxIooO8MM2AP5dh1zHP0vxVzzuys+pFGhyQb13TT+dve
	dfc8Nf5gqXn39ja/uAGq+PLl/5IC+uHH7378+jX5wa93d+/5J7/aT3589eMr
	/MR38Vf/+v3Na/zoX/ajn158B1UL2pcF5FUgBbMe3/bIAG4PKalnD8jSOZEW
	CUhY4NSFIgAKWIEQUBRxgc1hLHpuDiQunqxJJgSKHQDHgKCeXJ65SCo6E7Ax
	v4iyBRynGm5ggMh+05MryiMOru7LUTAarZMhnX5Ju+pHuwNRpGFenAudhP91
	wct0nwsImktmwU3n/mukzTTHwLwVWSe8tBW0hcqigP7oIqryiwsl5VIGcQA9
	DvYhZESP4HQd0AMts2cRWOSf6CroeGGL9H9jVw/YI+vdEuyg11zlfeu2fHVz
	4mEgUPp258emAgWfBh1Ch0CAoVOxR2ucXeKdB/aCHGa5JqAV1/IbstFJVYuZ
	kIf/vnyTfPx1Dr4n4I12SXyZYLEULGI5X748apd//ao8i0HyJ3KL1eLLZbeb
	zu9zth6JLOqoIB1VbwkJ1AO2QVtcKOaguVJ7lIcHjujcRqU88CS2cEN4km0b
	3PV3guXpZtutNxTL2lHu5Pc/PPthkd8q4nq+es6jf5Nfq6w9FVIpFotoA/gy
	3IUv35iMVxr3Or7JqsIu+lHl/HyOkplhoBNZZR+FERkm1oS/ept5ZOCNEe2I
	UkHAgoIkDEMQyBwQQ7T43g07X/Wzhzf0b1hUujI65/+EdmbhDR6T53mAntU7
	fUmUxfibsYk7AskYPTTFYGpAiIRvTrYKYET7xHXChfWKsBvvP40HSB5TPPlF
	gRGIVyr99lKwzwCDCMTAL+kIADQhfVLxREMf/GGkJcnPcIlINEDHRzVmUAiS
	yPd9TcI5B1WIF/swFWnqogmS2E5WVq96ioUlX3fIXPpWjwvon9jnyIOCzb4h
	87pd3riBryUxL+mk34R1eqH03hOVidokUekO5IAYtQrGmV0w7NyUHyf7x6xr
	x7ihSqdbqRkIPxwrU7khgj1JbB1tC3sHy6Lu9zI5Yd4RIhQzXucXdLCdK3rf
	FmuSqNf03yVrnE60cMGmA6NtxmoGdPv8UwvnCd3ND+z7+8C+PxpUUe3AOHrt
	5IArU01kObmSUKkY9DmNRbY68DlNxoIgpRFrBfxAWJm+r0yTKWInEifGGz9Y
	97pFKOBr0sYFiRAahwgiHCb7CvTlTVb1hiQS5udd0sEI+nb0cTkoj/RkksjC
	2OYpiLhb2ZMiEQN7fU0sKmIDZiKuoEyNyYwtQboGI8DcAMoyvr1+ilMIhwAB
	Gzd0p/ZOcg2NuxUubt3AoHwod2zSuSFeAEbiAZ9CddNFZSWXLIFkyVC7foIR
	0wtW1h3pHcDPUsgnwEWkXD+YgeE+7wgqQVWuppKn7sURwicM3lmK3zihFXbL
	K0rMBeM7eoSEhGMbXGC7mZjMRiKBplbtsR8Iq12pObdziZMp8Nr858Ry/U6u
	o0Hq6UlkbwYxdgEUdnSbaUv1Rq0j/HQP3DeZSS0OOrt719aCdzY1uGIw4dmR
	hX0UgvE/A6jfF90nrKFHvKFloLPKLt6wPrn9+fVjZs1CZCzzMmliWtGHD8F2
	o80QyLw3nwPsSsgDsQGKvIFDs8t/phkunl3SAf5JcG3tNtjX2uE390VTw09Z
	XSY2PV+o/9mZLJKLR2rngRETjb4lrmnVmBsPqkkA74g1jyYy9ZyKHiGilTIr
	pCWfCG1vM3bs5mEXjUDphN0Sfw38eECKAm4CIyv2xiWU7ZKV5sHEg5BVfoUZ
	d8V99N+kdjDcOJHHZhe3qivdGCtMu6TTZxJDcPp7u9V1rzMzN0Y5U5ikEbUu
	tx/szKJhlb3ZnBsf98/ka8+uMkDiHoBXhRyz4MlmhM8yoBJijyrwci2O3KeM
	LJRvJ8dgMllwk139yBeyTWg/8GijWlOtjrPeBEbUe7qOPSCDbL4Wv8X8BEi3
	IcwEjbElhNEl+KWfOEVasLYcMwk+EtLE9YX5pO2BcK0wLwM+MWWKe0+UdZ+B
	t0BIvgrK1Kkdm6niNI1vroc4Bl+B5EjUwofmuT5BZ6wMiWM7giC0ItoQAOhD
	mzxfFqIksIqygUQKwqOAKqKJ/ZqXx4u9u3tr63YIRRi2IvAEyUKf72GZdZ7M
	rAKeNZXamIbtMhq6QdiE4eSQNw5/MNyK6mXPIRUama4ElO702wp+igva9wFX
	l5au67pk+7mRdbJ/pDnaznBWYrvLPWHYvqu3kA1qeZbHhTrS8dCpUAK+DR8C
	TNDe/5Y9RnRiebaLaL2iGyPF43nPbx9TB1cPK61bkm3EJYJbeFR9yismq31F
	kJNEZE2Hf+P5UvgYDBh2nXOp6zrLnq/y6zbVlnOZLEdf6O0nnFb3UCd64vQc
	G9j80Ubx2em2ItiI37INoOtXjxIvM0oZobO5WucAp7cvIrnowr9Y5XcTs+HU
	ux5Qtlphf7GktVM2lQ3wZx0C5G1cpQlS1aREXdcNNZTUHcns5Z1fvpVbCdAv
	xpndcQOgEG8rxPf4YrCmIpzjH87J1HjvKz7fsY0iQXmQyPByBdghgQrDGiyo
	GHt7uP01JjORu1iU2pgiGnn3sm9+POx6LmvVM+imaIghniGQ4EgMg5ikOZVd
	pk8kfGq3gYjDNoygxggYZxSqo9cn9fgMNZJc3v8cmOUu4uManpKRgydMfnbi
	PxY9SFSnyroi2YpugEbMQ5QhrMcnjGPLeMOGB0cV1aEtQLB05lZn11S/K6BD
	N9Aj4QpfmaEgVxsqjvAdIjGMS4k52Jw8mXWhqDTZf+fW3g9g9ZJEcGcHxRyg
	gPHsRMwcbGDQ3um82NlmJ5MOr18SW3zkXQ0pc7A3vJOBG/eZqQopD9yjX206
	8TClpsLjJ++a3j0I9Th693Pw9LFbl26xhzISDuHIe/ArSUQ2ptzcqNtMPVD5
	xe3Nu0thGdHl4tgLPBFjK4aOxFNyoP3XJUOK4MU/MrgiOSOW81lZt6DfdOe2
	S485YGIN5NliPqUyTWWCjBw1Bh1/PQSLnZlQUGMBAhk/sgUObNOIiA+B4uA+
	EEaD55tdBa1zlauywTNDsHQllTrk97V7SLwawNZ52dUcsAyQFDrOl7TwE/4x
	/3dLowiIZB8AuCSjrTraqH2tgin1liw4oHJKv28BMA9mOmSppBSb88hMLThF
	IsoCwz0BuXunRCsGJdqZAyJLV2OH+NITlk0jvCGoxoIqiyLFlpsAAY4/8gZN
	i2m87r72Y98cg9RVFsqmKwmYa2oM0A9aQKZ7WFB6DOwvTWICSPBZaoaPcHLM
	A5yE8eEoTcI8DL7VucOe4E3tmiqECtmiQ5DM/MDKnuI3B2fv2b2nqpfuorCE
	Pnr2Kb1K9qTcw4Z/yQ9BFsNcTjzY/V95pWfOXvOlpX6PQbJWBNGd+vQTnSuQ
	uVKvqKIApslC3FEBGGporWd0CYEBz0twXZ/oo15cj5rQgBNTDnnLrvcG51K3
	dEUHX/rmK189cQLqZlU8JXhaYyfi4YIlwz/Z1N2eBeJ4qMR2AA+RTFwSLj0Y
	cCCrA1C1ZnUrCAfCvSBkdyGnGINui0TGc8SpyN//8/Yu3gBxbXMwdE8mKomy
	ouHUiIKQQFvRotTgZzaALGPxzRY+YqK8UFE//zUSPAvhN42ThS2FqPBUa8Xl
	KTqtootaXKpYxLecgLHzJNAkDKRCNsnCMS+tyNF6o5cZ2kHVn60QE7B6Rg7R
	A7alP2J5I9CnY5HD4EOjl7QOASc0koj8KnBTQP+KcLGD3z+8td2yTxpSNKGH
	kmm6q/FANkLlElOFpQkBgSocn45bRMquG7+OngslrV7YinSPuE1h5IqmWWV/
	h2i3CGbw/YYB6QNX8wlDrLDsBBczzrr48mVpqaNfv16GyHk9WD4SrZw0GMQK
	Mz2n/ioheKV1PGpoqfb8ye5Zq60RE9sfVPGa/TLNHZL4F+tRM27sKvJNIYAr
	8TrcMIH0gzo1beUOboOWb9w0xHxyIfmJsDaOSnNwrCnKTxpm4n2Lz4p2ZH5d
	GY818y/8vXhyiUDrcWtKbhTPOO2HQ5P8bAju8gBsl586hx5UpnNy3tge4Gti
	VwLvWYVNNCBYviVOfY5PnFgIBK7Bpn8fh1Sl9PDJFM2ZWPwY5OPsaPoA6Oem
	7Ow2SGghjUWofME+mauVOeDygaVcuSCMJvyRcXaW74RV7r+3lUAX9eNeeKDQ
	pDL4s3GrlH8jc17H9B32Y5Cyh2G69rThTzXuZGqgiRoNvmn7NRR0Fr0YkyAT
	Pc6KCYMxrybbTe5AA2+xMqvQzWAF3M4FpxtgwwsNMuj2NTDsAndwftVhAGOI
	AqhGxlrvru++f2Xx3eevvkfEOvpHaLNMJtAxm+AZNkxE4ySuK8ZzSvhX8xtk
	W1sfMwlRkrXjxy3fjHQNP5BskTUq5JiN3q3roYNFLml4QtGVuYY4rTGmkgZv
	pCWYCUEApScJO2IaBHw7j1eEax+QoORBTreWAEHLcWIanrsWdbSxsGTTyqzN
	j5nqK+akuh3ZF2FiyE8eNLaIC1afW8zwmHBzndp24gA+R4JJfGyS7zgnTeAw
	yMNFkHWJc6/IG2LiZp6yiaczv76vVbq6cCpK1Ok2h941Gz5molJXmRCiIe+x
	/j6VQ6y2V4gX1b1yKVu5AfPlakQhfamES2mD1EcLu5+mDPY+E4uukUP85Jpj
	lFSB0YPKNQcXtBFtV/iFJuObflaBiVuVlnPLrPSOzuoNEatEZrXdjWfff49s
	BWFGuhyZST3X8kUCt7jP6uwlcb8OaALOVM7GH2tSyYJdOHI/iOumOWZsTdCf
	BNTNP2X+aQvL8QVUJmeAUnX1jPJT/UyabClDChnZwAEzXdDRsy/6chE0cus5
	Ogtwmfck5UmC8s0/0S3shPulbiXFVM5FQTeKYaAH/zLJJb94ffNOkoAxNifb
	wuUVo1bg39fvrn/7eRqTqOmmGGOWMsOSTpyNXbpcSSiTw1pyEXkISxqs0vVY
	Aj14tNuSxf+nOXBay1zGQVqedIyyh3yroDUM9TCF5Xg5eSTrxoY1mIrShw6u
	jDaJUZ46ecbWBK6isz95x1lUPKtpIulMK0n8NjxbLVK5IhkXtpHsIebrzHcC
	YWDBYM18QHYtwwdO1QZDWQAI9M6Ai0nqh7lmwfVb9kBNFxLp64LcPhCgE+A7
	k7TwEkimet1m7CUsXXS+Rwr0yeYn5uO7eUYJM9o7y9y1rfcQcmQZE/QPVmRt
	fi4riwh0Eq8mphbTTWgFCRjslhjKpytXN8ckuUtKIFbZB8cgpVSwWZvzZT4b
	m3OwUySJyxxZehsQ6PEMyQhUqavuvmhGp8nbSMHDNzDSwZEIxUPsnCzLts1n
	XBzVN8xZFKb9k0IVmsdPCjskFASxr5thocB6YwlH4TFHTpxFxDlPhgOAZ0ZP
	fJhLFbdwPfkOTkm97RdutV0tSEpb0Zymt9IHXJZGgIbYL01pLPYTN69Orx7A
	iC5U04UV2wJoy8zNcZU6AuF/snLrcmCHYQmytDYYDWCh3Ym5mDpVTNtxGpVq
	fwi+lhRJyJqwC0FiwJxsE2QfaRuTA1RLC19iiZ3dFXbZPJBNRNplnzyLc/35
	PqR4TPb/bW97m5759HINyL3GCtIoJKPiPYi3IfVjJSmhDMiEgEij6jS/CHmw
	6vKdW4iC4STCFH/FelUuRTAc9Lpc5diNtz+RyLHcCmvoB24oGfIEV76es6qu
	Ij8VJ6DGIk8Eq93hqf8lPfVJtCb9goMj/Sc1weUOimI0uMhMxVwhscAIltmz
	BaSUP9n+sCpWmn78ZBGtRvcZMeUioMFwzuL56WOOfeU1PuLScDenWQqUk0ip
	qGZOqNzM4TjCDElWpYDuRzIr6k0a5ArhnaSypp/5kBc8zcYjsijbAJWiXVhi
	5HJIVeH57Et6hHPUApGQAsDp24q9TlQ2hhd1juAEqpy3TsYnE6DfBYPXIrOc
	pEBccw8zhBFcEBE0l+R1SEKmusFyy8GxlaepRhDbBmpQTaFeCeVTVkbZRHFz
	wlPwGylEksgj0a45xkTVsxyJ3XIWkPCD5xrGaXKhRYANmwSJa7M2XEo3s8A4
	ddHSA5nRSnVKzYKx5vcxZq01R5mkLuHWtf6e58JECdYKbFpFz4KluiVAijVp
	MCWC4RNxRJHfeZ//AyVqCYbIRMUA20qcChQqCSDRp13U0PdF3TDAY3GImHEj
	PpALC9E96V/abUVN+pPLlTnr4fMRRFZztYCkpms5GKQDLQ7RqKuEaYhBok7i
	mdTjEww4S5DkR2hEju/r2WtyNyiYoJyEUOKIIRG7HlEWtsgSm4a2OBTlJ4u2
	clYKL1nEsdGGNc1nOm4k/4VM2LpnZF65A9fHcFJc+HY2gCgf+BevmKvNJE5S
	kti3fGRHn9jE6a2pXEsLXvrN0rxdsvJERsCIqNnG6wd1AoD3wxIYcMgJtva0
	rCMliFY9sR3AtYNCROgYqexHKAwpeFu2RsyjKt6+ef2XZs2LK1lj9bVwiGrc
	WjGpVoTnWhIuAYE0OHRaNh4KI8BcnEVrxi57pHBdkhJL5ClLvCa/wAAKCfjT
	bujVnxRQZzMoRM0vEP0VOsnHUldngaBgarFH4TKE795r8Q1m+Oc4cOEhp2fS
	SYw9r/l1Utb25ZtJIZbmkUutlFaIaCOGWF7MW7whBcNV2f5XlMP9RRlJqJdg
	iYeKlJW4bzmIHR217axGqFh9IuVME3z38tKM6RT6ed2diNQ04i13QKvDlG+T
	AhLhT62zYYH5D++3ULqvAaZ/aQpUrfwHDYdIg0EdOMhZ+ZBQ1GKesinMY6ru
	7AWx6D3JH7vYlu4TQvE8My1cfCODeOEZCRLipD+5gj1UUIWaJEwuu5LZp34N
	gOASoXTLCVRf+X8/LjRLtG2Ktb93UkYSyxvPmOLBAOY4p7ovzUsniaKygov+
	8hSQnE03tXxvyzdN0yhCDA54H0kFRX7z62suf/1AtKQFXVv2FZcjP+5DkCoY
	9eUxWG0sXhaCFvgJp+aXg6lAVsBHNySJOa2f2LmVzyWxFJd5MwIQCARUQRdy
	3Bi24szcZxJvvXol2NDNfid+aIRLGY7QD4Vl41TuMwCC+C3W83iZKeqErpBx
	Dddz/iVh6Qr8JUVZunyY1R7e+cdTArwYLta2QSr9RdZwZROgHMn7Xm2zCHzV
	LZ1U8sEHFdsVNUh3Y08KR0TZk6ouaS3RJkWKfJA9YwwFccqbvEf1HZZeXAWE
	9LVeRJInGAVoOj8LqNRfjgYW/GBAh8SL6V3M//VBflBsNvXnkJbBleHFFlLh
	grBKqCR9SVL2UpRJdADDqBb9rgYUMDerd+K5cTjj/jEgdhfiYRro5rpI3yiM
	2bnmEOVtEolg/UjEPfbslI425yKX1VqfGag+LFaSIS09lpd9lFvxYAAVStUy
	58WaImqknqiwmznWbU8SKsSZhsF7QB71mdQsaADqTNqa2xJ8OrahZUBoDBHS
	RWf9SpIS1qS0ZYe0EWEfjspxilLntB4O0s9P0pL66IICQVUGVv+jkjPL3pp3
	CdF6XUIl9ebIdFEXBD7lvXJXByvbFSzOHb36IdTQYpGivxg+coVXb1VuVjeY
	pIp8FfkyK1qbrk7XLSmpAhwfiSUBAcfQd/SKaC6Aiqcgac2YIByzN3eX+CED
	bKnyvx853TeVOZp1Kr7J82tt1BLHeUzbrSiUIpjp+qgvgi114pGYPGzOWS1M
	VAjKEdeaRLhe+L8CSMYLLy6F1RQvmuwIzV708Ek+wcaRLhYxiGsdHYLRxkFJ
	dJzibLux5TEWkmOMA+MwfHgc/vgT01P1pGPHu+Rr0G3hPzgeINInZEQi+4C4
	RsqxBRxI5VByr5gq5r1MIkFJsOtc5IUNq6LnStqmKlE+OgmPcWWahLgRb4Ei
	CPakhh3YA6JhtLpVj/yZYtHUf6vcqFGb5bmojZz3rRiRgV0tWqK7FSOUTQ52
	TB247BkFJJMZk/PnH6cFFGmKPsjNOdK0Rjarpciemw2Iy4K9PchEH/wSaYv5
	BSojzOe90RYHLHe4PnMSMznNPbe8zjRDP0F2NypZr9nvIEazXGwrMQ0Pqxfi
	mpkprW4U8KQlpvzAPs2fCJAHylhyMpJEKw6iknCuxYHAC5Tju/H5OwKWOMU7
	q0j6wOlLWlGsu4mC5ss3VrrEZ8JGkXSQ+OE5mzNw2MmOHPfGYkSx7Mc1GhJd
	/Pz69pIL5Z4RcNErJ4Ux3P0i4+ZLZ7KL0rQzXZOZDuGWEhdMK+GyROqqG5U1
	pDm5g4tBldQq+52s9n0Re92E2g66bsnYomP9wZsAIXSuaK1s4ODm1AaL3khI
	w8RAODKjd5fSW8jVp0U2OOtMU8lmLryQ8+7HPp7rx0cAvmQMo7gpFFqEOKzl
	HZuvTTOIM+77xOQWOTGlQ+DblBaBZkWSlE73IJskLmMZvIRJ+WxImubrMSmZ
	Pds+QIF7dobVhL0CfijSEiFJfphcW8QxBiCebLbs/JFl5/kbRSuQc069XbUN
	bgT8C7kQENebNjFVEj+UgPkIfusT03AUYBauQBZaf0U0OVWE1nlDc/0SFZfW
	KGUxM2Z2j2e5fvW2ZSaGCU5fdHVViV+awyexZJ9USleQehgZKKzU6XnmDsjI
	rKM6t9QY/s6FGknLXjQQlomy4CTRGHJnERhjx1qofJpUZSSdMdcO6ZfWGA7O
	8CzMybAdGVzmKLV8O83MYoTPrgJzwC3Ez+ylqOcvYWJ2hiDwtsHoOel/cGIc
	QKC/F9WJX92q4Hzrio7O9xd4UGHkPT1rxQpEPGs2Jz1u1ZyXAI/aSmw4Bmt5
	0m9IFamJ8EZWwr7cs4uwVkPPn30fHInXNzf5x3+wh1PTIMxCfPX9y+CH0w9e
	wCcTZWxojiqCwLVVsJyj/UAKSwtG2edNT0J6cVAEfqOn7BcaJs6B2CtP/Wih
	vjQUJOpxTcY1+tivFyEVEn489Pz514J9h0Q3+A7Z0CX7y48IW1d2a6bp9MLV
	HLGLuHJDk67hS+aIo3iuZ0tlyUhSf8uofwvtO6iPbI85pYVYIYkjd2cbHJi1
	FJhY3DzTnitTuKA28nwtITfKCpujXLYbkUDAc84rk+jSb6BO2kqyaC4Gc0Og
	QnrqChQl3VqjhCD8T84uPmAM1hpCUrAU6g05TAMpy1YBqnMhwRxMIGtbQPB2
	GAMwsXac52ZLc2pIKDrgVCudO61xTXKsNmlWKJnCXJyNHI39YYjB6DMUSbyE
	EwBVDPHM0lVBKsaoa5p6k7TlSzpqyFOhRkuxUhjR4h1s4cUGfmQv1iu3WuS4
	LD9+99J87Yv81Sv741c1Eyc93rTB40obhDoWcFgQC7G9VfagQ8QNXI2EY+gy
	nLgvLAODeUW1w744nO9HQ4Zo4qgTBmcbjJPXMLa1Z4LUWkiOstCF7zyRWIxs
	cW0HHzr7o7ge04cfTn9D29ynbQWMmuesCq2k51S8FohFksj0lvVR71pydNIO
	TQxHpYswkCrApm4/SR9XRW/H4P6x6L7pYtHtXH7F/vp0J/q8To1QQCOp58i7
	bvsx1LYniCgG8QRu88OlFs/Dr4yqCI5osa9Z515l7yXlk0WlCkNxNksxE0uI
	kAi0JoS/0TZV4ll6o9lwrSaZlkUfyTibN/T70VvD62jcthbbY9LJkh0BMfFB
	I6qJBy90SkHCMd84cyiyY56d6RwTNucaF8ikuDamfWjNE8SuZIBIhsyKz/bJ
	JKeSlWZhrTtp6HlWjfiJTw/DYsFnzkPuLbr9BLrYCiwL5RT0SIhb3GXscOCE
	kTpJ2DoZI+mfI+nakNtI8mESRQTGDWZwsmmxdGvZqBLt4DrGUNIs6ZqWtswp
	SuAac71eFA3c5NtdcOGwq1yMPEmq598x8Uk6BLdY3xblUpz6Icveo8Xi/jD2
	s559begJR1hAorbn1qLNh8aWa7yljgr8Hh9nGVJbSxeQo7DIKkTj8vbG4NqP
	P7IEk4IlC8uE3KvFxLMdWELK4TTMrkFJwrlBIepCFMSnQwjHDl0BTRXzzR/v
	bMsuLfo9eofTFPvUDtK8FVkWO4fYacya9j81B9xJL8szsMM6wcBG0B7e2k4k
	KBluP/Y3kEl6Y4bWt5NebAY7BXHbDJJBoHdk6rhP+g5nViA+c+0zGzGImsQL
	tBzbc+P0hYXdIDMsvBEE1CTx3kKhq3mEwK6TtTR/bMmWg0IsUvqDFNVaRH72
	oo0YeUcjTTEETvBbalqQ0PO9+p0sshJNJQs3iI8xSc9MuzcfCuk644iv+qrz
	h4N1Koutl2NcP61A49j9Dg4EsW1OR+I+abi1Uv18slrVmwEEmrEntgCmSwxy
	Q+Ixj9e6HcIAQByLq2U7tkGZgn/ZH/KnFy+fBWtLN5rmG1xwkkFEQkzD+Qmc
	3RLkauCFs+SN9QWsD4LMsPodTbCtty37spFbGTsGIDFmutSP9fKX2tz80Uj7
	eZI7Mc15T7dypqJOSiby6GQod16dNgm6U2DMFctjOM3JreMfSO+kmMbHKTeu
	fKSUmAs72YJ9lD2DW/Mzx7RKDbTGngTJEr7tTeWLRLduxZYb1dVb7lJeqs2H
	QArpvM3RvKRp6Px4QE35wT9YwoXkLgk4aIqxBXRiJzy3H8d3fXbSnMZSsK/t
	YU6KZHedeTYtT0zy4+/Hpo1llj5tiHAZYi6IVaCDlIXP33KQ5eLf64GI3V7m
	18jylVLOYdL8NmRj8wm53mKZ8DMtZsPSTwSt4Rj4Ehoz6J6e9CSRB39Eu2HL
	U9emyBx/2q/x4p2+30si16N9rLmRe2s+gIC92EHKd8y3x70We9Sd1WOEtjdp
	6epCFEshMNePk4JNuLA3Biotn20uL4XTEWAL1c0Swkpa5RsdHibZHUk1WUV3
	qe2j0+GsuFxl/5SUHlld0lwjtkOo23sc0lZaIkRJHhvlo+GfVkTf/b+70KWO
	l2717qHePDqLVMXpDuQdBYksHrQjzfFR+klDUHUcbYp+Fwet+6kI4zuE7rJs
	rc8bl2FWa0/SW62eWVWpKcAZrtzIC+sMbbPUHbyyVqtJOxk2UYhM0/A22Hzg
	WG3ibDESKWBJLf80/0hwFsGnesuCZSvN8QtJGNHqX45V+g6FBNyi0qlPUSvp
	eyTMJfXqaRzrAc8nnBbuQMl7Qo1c9Bvtak3H5herCBRmk5lkiDammXOAbI9x
	ya02uD4PTEL769O3u4SbAQ8aAVK+amE0tTjY2SmdxsJtEWu6jRjgodA4t7bS
	keNNmlRzZ690xBCirKK3lruchiQ0Q//xxSB8PCagYhjIqzgxw7Iiqm5cTDY6
	yRMZODzCzIK+NoF1aL7pGjWbM0k0q9tALAFJon1DtyX9LqYylSQTcWPIIgnN
	nNL+/pp0gBU3kuwp7WnpQjXHzBLB5y8xsA7k0YsiQep22nxO0hcI+SHlBdc7
	Zhr1+t4PK0MrAr3NAck5ptMWVhHbJJVvSZVq6r8T9QH9TuyEmJ8xIjdNDAEv
	bq1Y99rtRWZK53H3qvCkUQygYRgxDNTrbOmDkCtcFAAfO+u91ontGEXaIjg6
	zw4KdWaFuD6PhpW2iov7sL7emowoFZR+s1nlOZ8Lp9DRwalvLv5AvSScn5Z4
	VWZr0MBVFMps++3FdsW7sz7i3VlkIPb87iy6d7MXdiE1xeDqrKtmdIanVrAh
	3WThsjdp4poWyMBF28pT2pHKKUc8/roLmB8c2ppypcWhccPN36FYO56reCUs
	65gMY35B1Ian1ZyqRYi8FU3wgphkCX1aNCco9cfZK48Su6OY+2+SQnPoYE6G
	C6ImLYpKBtZeN9KDUF/MMAl2p9QxErI8ZJGcbl9jDqy3gSjEQQBLTpx7v/03
	gAxxqYTi0c3NzZykynsxeZcS+qmSQOJsX+7oPK4lgfYYfFmPjYnD44xHVuYM
	TgQ+SfuypHV36+MNFIajvcj7shAbkncA/CIt8fNb622Pr6f9rb58M++bn2XX
	EkTozQU+70Q/CVN2KDrhlERJhdhwxvu8w5JGk0QtanMarX/muAwK/4yYrPp4
	t/escbnxfGyANamZ6xfc+1EsMmk8n1SaJq2Ks+zVKk9rF0NTzN6MpRDmnZVG
	LKwdLRYMeljwLXghWevE9/yY/lQ3XHHuNQNXTKLTlMS1a/yDhHtRUHRLf4FH
	dWuzmvvpYQQVOnkDgS6rbpd4bFV0h4I74hy+l3/3hwIm7y9aydyoHW1dEGtN
	DI9+UBM0LzD7y1xMax9eaqAttELl36TXK3JxaYpelxQDuKFdVU72Yv7iGQZ5
	/uxZvpdyFHmz5tDVB12TVifTlnprkZuKPLCj9ugedvZ6KkOrkqyzCy2nVYp1
	Dt0PkvQ+Lhzjfh3z9N2Y0oV7fMH1ufHHMluI4UvTVDrHy/guijXnSYsHsrY2
	snK3pW+b9GBl3cm/60PMi2DPIDFGVL2HxtGyB+0xrO0XOXYYavy2s6rCNOlA
	h4l9yBIGin3SRfOTIllttcE5Es5JpHXsp0ZX4kUIsOpS0hcTeH09FTqOoECI
	GyZrruEHvezvk2vOyfNZ9vdj6BOVLizJ5KE7BV+mZCpbfLMItmeReiCQlHqm
	XadUFi5CdXvS4wavQkA3sIkYWqF5Lb88h/t6aca6s16aO3mdVM9LOtSSREMn
	v9Ket6dhigDjoYJ9y+/D5PK4hbzHxDL507ilfrb2w0D6LCha+93QOc0cCQLk
	mqb6J8vGN0E2Zmczz9UDoJ1C1WUQqu2lQ5kUN8WQLloxYKNJGHKW4lJ34R0o
	zAuSK5AEu9j/EfCxNLg0C1nr9bRaRtsdJiUSxI6uYuG8sXpW0p/2dpZ6v8eL
	Vgd7E0PyGji8vFjlsYQdJENUaHYlqpubdVpzpahYrLuY2Lz8fg/CKTsJ3ODC
	HV3R9cFWRSAAbKWv1PBtXH+vjqJpae1Z8lvaIROrHqaufHVZzLZizQtJEqBU
	T7wW8/5bYaMV1xsJHlwBIh11JZIfaKXvxMdHNFnRhMWe217OFVQsQ5NFa5Kc
	7WnboYchi9BdV7efuJJMhpJ1nZQTh5CSjYxcuvKTpV4k/YbwQqT8P1Sb/2qF
	jtz/AFnC07esqpFC0LAdljGVNMnNYMWR7thOVZF1umo3b44zqeBWI5Hj5qet
	bqSaP32DgvhvEaG0foYs9qRZtFES380TUxXRFPMu5/LCzliYvdA6ecPwZ3+u
	l5Ipy8JGPU9nbk0syTrJ0k2TubvQhToGmrjAiMHzjpR+56Q9g+XL83nz29LQ
	CJxDzxpdPRl7kSZsipRNR3x/9yH4DDU1w9kr6xIPoSINWJgKG36/ef/Uskok
	21nea7XQ6hcV6E2TFkCCK+9evzcHn4xt7+ZAlT1Xl/MGkhci6fqUzo7wtNlN
	2g/MSPIUSMSqnUIP1kIxz5TkSbrKpEYy+BtCkeSdl63RobANJWG3hHC25Wos
	46umbPFWJbxIXkcs+34oJMsfrDFtazZ92RYHXc5wV8ytE62aIIMJ21rTWdU4
	DEUBd7XbgL6fr1qGVjaiM7y67Ulx/pI8qsU4aEEKCls1Rh/vtrjLraI6Smsr
	9K97/jJh2oKOndvrJ80Q9PWO/c7SR7TlhtR+XGgRj/hMTwtCLudhAXmx9ar2
	i5jmHSpldDlJtxPzs4NwP1d4bXf/bWgbXVsGckWIiyiIpjuSqiazLOI9lko4
	+MBlMxzoSQpM3kgu5SLdhhR5JqUJwhtaKx+fvpqmbrGnuZo4Wbx4wDQ3SfO1
	Q+sYywcJucPI+eDUAI5WumazFL9sNSPQKr7g58FKgGbF2dqXR4wSQciV/5Mu
	4+TaSGc3Uh69qh7JK9R8KxtPGqFDng+TOcJrIXPLS5KeBhdW3HN5Ut1jfU+1
	rUMgub7uspfUyockc6sT+ynpOmQyXXYit1KNBCTg8lskQlmQZJiFedLSouz/
	A5jtLxORgwAA
			<!-- [rfced] We see some inconsistencies with the following terms. Please
			review and let us know if any updates are needed.
			edns-client-subnet (ECS) EDNS0 option
			edns-client-subnet option
			edns-client-server
			EDNS0
			-->
			<!-- [rfced] FYI - we added expansions to the following acronyms. Please
			verify that these are correct.
			DNS-SD: DNS-based Service Discovery
			mDNS: Multicast DNS
			CPE: Customer Premises Equipment
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			Note that our script did not flag any words in particular, but this should
			still be reviewed as a best practice.
	-->		-->
	</rfc>		</rfc>
End of changes. 70 change blocks.
	1396 lines changed or deleted		835 lines changed or added
This html diff was produced by rfcdiff 1.48.