rfc9726.original   rfc9726.txt 
OPSAWG Working Group M. Richardson Internet Engineering Task Force (IETF) M. Richardson
Internet-Draft Sandelman Software Works Request for Comments: 9726 Sandelman Software Works
Intended status: Best Current Practice W. Pan BCP: 241 W. Pan
Expires: 6 April 2025 Huawei Technologies Category: Best Current Practice Huawei Technologies
3 October 2024 ISSN: 2070-1721 March 2025
Operational Considerations for Use of DNS in IoT Devices Operational Considerations for Use of DNS in Internet of Things (IoT)
draft-ietf-opsawg-mud-iot-dns-considerations-19 Devices
Abstract Abstract
This document details considerations about how Internet of Things This document details considerations about how Internet of Things
(IoT) devices use IP addresses and DNS names. These concerns become (IoT) devices use IP addresses and DNS names. These concerns become
acute as network operators begin deploying RFC 8520 Manufacturer acute as network operators begin deploying Manufacturer Usage
Usage Description (MUD) definitions to control device access. Descriptions (MUD), as specified in RFC 8520, to control device
access.
Also, this document makes recommendations on when and how to use DNS Also, this document makes recommendations on when and how to use DNS
names in MUD files. names in MUD files.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-
considerations/.
Discussion of this document takes place on the opsawg Working Group
mailing list (mailto:opsawg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at
https://www.ietf.org/mailman/listinfo/opsawg/.
Source for this draft and an issue tracker can be found at
https://github.com/mcr/iot-mud-dns-considerations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 6 April 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9726.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. A model for MUD controller mapping of DNS names to 3. A Model for MUD Controller Mapping of DNS Names to Addresses
addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Non-Deterministic Mappings
3.1. Non-Deterministic Mappings . . . . . . . . . . . . . . . 4 4. DNS and IP Anti-Patterns for IoT Device Manufacturers
4. DNS and IP Anti-Patterns for IoT Device Manufacturers . . . . 6 4.1. Use of IP Address Literals
4.1. Use of IP Address Literals . . . . . . . . . . . . . . . 7 4.2. Use of Non-Deterministic DNS Names in Protocols
4.2. Use of Non-deterministic DNS Names in protocols . . . . . 8 4.3. Use of a Too Generic DNS Name
4.3. Use of a Too Generic DNS Name . . . . . . . . . . . . . . 9 5. DNS Privacy and Outsourcing versus MUD Controllers
5. DNS Privacy and Outsourcing versus MUD Controllers . . . . . 10 6. Recommendations to IoT Device Manufacturers on MUD and DNS
6. Recommendations To IoT Device Manufacturers on MUD and DNS Usage
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Consistently Use DNS
6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 6.2. Use Primary DNS Names Controlled by the Manufacturer
6.2. Use Primary DNS Names Controlled By The Manufacturer . . 11 6.3. Use a Content Distribution Network with Stable DNS Names
6.3. Use Content-Distribution Network with Stable DNS Names . 11 6.4. Do Not Use Tailored Responses to Answer DNS Names
6.4. Do Not Use Tailored Responses to answer DNS Names . . . . 11 6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements
6.5. Prefer DNS Servers Learnt From DHCP/Router 7. Interactions with mDNS and DNS-SD
Advertisements . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations
7. Interactions with mDNS and DNSSD . . . . . . . . . . . . . . 12 9. Privacy Considerations
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. A Failing Strategy: Anti-Patterns
Appendix A. A Failing Strategy --- Anti-Patterns . . . . . . . . 18 A.1. Too Slow
A.1. Too Slow . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Reveals Patterns of Usage
A.2. Reveals Patterns of Usage . . . . . . . . . . . . . . . . 19 A.3. Mappings Are Often Incomplete
A.3. Mappings Are Often Incomplete . . . . . . . . . . . . . . 19 A.4. Forward DNS Names Can Have Wildcards
A.4. Forward DNS Names Can Have Wildcards . . . . . . . . . . 20 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[RFC8520] provides a standardized way to describe how a specific [RFC8520] provides a standardized way to describe how a device with a
purpose device makes use of Internet resources. Access Control Lists specific purpose makes use of Internet resources. Access Control
(ACLs) can be defined in an RFC 8520 Manufacturer Usage Description Lists (ACLs) can be defined in a Manufacturer Usage Description (MUD)
(MUD) file that permit a device to access Internet resources by their file [RFC8520] that permits a device to access Internet resources by
DNS names or IP addresses. their DNS names or IP addresses.
Use of a DNS name rather than an IP address in an ACL has many The use of a DNS name rather than an IP address in an ACL has many
advantages: not only does the layer of indirection permit the mapping advantages: Not only does the layer of indirection permit the mapping
of a name to IP address(es) to be changed over time, it also of a name to IP addresses to be changed over time, but it also
generalizes automatically to IPv4 and IPv6 addresses, as well as generalizes automatically to IPv4 and IPv6 addresses as well as
permitting a variety of load balancing strategies, including multi- permits a variety of load-balancing strategies, including multi-CDN
CDN deployments wherein load balancing can account for geography and deployments wherein load-balancing can account for geography and
load. load.
However, the use of DNS names has implications on how ACL are However, the use of DNS names has implications on how ACLs are
executed at the MUD policy enforcement point (typically, a firewall). executed at the MUD policy enforcement point (typically, a firewall).
Concretely, the firewall has access only to the Layer 3 headers of Concretely, the firewall has access only to the Layer 3 headers of
the packet. This includes the source and destination IP address, and the packet. This includes the source and destination IP addresses
if not encrypted by IPsec, the destination UDP or TCP port number and, if not encrypted by IPsec, the destination UDP or TCP port
present in the transport header. The DNS name is not present! number present in the transport header. The DNS name is not present!
So in order to implement these name based ACLs, there must be a So, in order to implement these name-based ACLs, there must be a
mapping between the names in the ACLs and IP addresses. mapping between the names in the ACLs and IP addresses.
In order for manufacturers to understand how to configure DNS In order for manufacturers to understand how to configure DNS
associated with name based ACLs, a model of how the DNS resolution associated with name-based ACLs, a model of how the DNS resolution
will be done by MUD controllers is necessary. Section 3 models some will be done by MUD controllers is necessary. Section 3 models some
good strategies that are used. good strategies that could be used.
This model is non-normative: but is included so that IoT device This model is non-normative but is included so that IoT device
manufacturers can understand how the DNS will be used to resolve the manufacturers can understand how the DNS will be used to resolve the
names they use. names they use.
There are some ways of using DNS that will present problems for MUD There are some ways of using DNS that will present problems for MUD
controllers, which Section 4 explains. controllers, which Section 4 explains.
Section 5 details how current trends in DNS resolution such as public Section 5 details how current trends in DNS resolution such as public
DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH)
[RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with
the strategies employed. the strategies employed.
The core of this document, is Section 6, which makes a series of The core of this document is Section 6, which makes a series of
recommendations ("best current practices") for manufacturers on how recommendations ("best current practices") for manufacturers on how
to use DNS and IP addresses with MUD supporting IoT devices. to use DNS and IP addresses with IoT devices described by MUD.
Section 8 discusses a set of privacy issues that encrypted DNS (DoT, Section 9 discusses a set of privacy issues that encrypted DNS (for
DoH, for example) are frequently used to deal with. How these example, DoT and DoH) are frequently used to deal with. How these
concerns apply to IoT devices located within a residence or concerns apply to IoT devices located within a residence or
enterprise is a key concern. enterprise is a key concern.
Section 9 also covers some of the negative outcomes should MUD/ Section 10 also covers some of the negative outcomes should MUD/
firewall managers and IoT manufacturers choose not to cooperate. firewall managers and IoT manufacturers choose not to cooperate.
2. Terminology 2. Terminology
This document makes use of terms defined in [RFC8520] and This document makes use of terms defined in [RFC8520] and [RFC9499].
[I-D.ietf-dnsop-rfc8499bis].
The term "anti-pattern" comes from agile software design literature, The term "anti-pattern" comes from agile software design literature,
as per [antipatterns]. as per [antipattern].
CDN refers to Content Distribution Networks, such as described by "CDNs" refers to Content Distribution Networks, such as those
[RFC6707], Section 1.1. described in [RFC6707], Section 1.1.
3. A model for MUD controller mapping of DNS names to addresses 3. A Model for MUD Controller Mapping of DNS Names to Addresses
This section details a strategy that a MUD controller could take. This section details a strategy that a MUD controller could take.
Within the limits of DNS use detailed in Section 6, this process can Within the limits of the DNS use detailed in Section 6, this process
work. The methods detailed in Appendix A just will not work. could work. The methods detailed in Appendix A just will not work.
The simplest successful strategy for translating DNS names for a MUD The simplest successful strategy for a MUD controller to translate
controller to take is to do a DNS lookup on the name (a forward DNS names is to do a DNS lookup on the name (a forward lookup) and
lookup), and then use the resulting IP addresses to populate the then use the resulting IP addresses to populate the actual ACLs.
actual ACLs.
There a number of possible failures, and the goal of this section is There are a number of possible failures, and the goal of this section
to explain how some common DNS usages may fail. is to explain how some common DNS usages may fail.
3.1. Non-Deterministic Mappings 3.1. Non-Deterministic Mappings
The most important one is that the mapping of the DNS names to IP Most importantly, the mapping of the DNS names to IP addresses could
addresses may be non-deterministic. be non-deterministic.
[RFC1794] describes the very common mechanism that returns DNS A (or [RFC1794] describes the very common mechanism that returns DNS A (or
reasonably AAAA) records in a permuted order. This is known as Round reasonably AAAA) records in a permuted order. This is known as
Robin DNS, and it has been used for many decades. The historical "round-robin DNS" and has been used for many decades. The historical
intent is that the requestor will tend to use the first IP address intent is that the requestor will tend to use the first IP address
that is returned. As each query results in addresses in a different that is returned. As each query results in addresses being in a
ordering, the effect is to split the load among many servers. different order, the effect is to split the load among many servers.
This situation does not result in failures as long as all possible A/ This situation does not result in failures as long as all possible A/
AAAA records are returned. The MUD controller and the device get a AAAA records are returned. The MUD controller and the device get a
matching set, and the ACLs that are set up cover all possibilities. matching set, and the ACLs that are set up cover all possibilities.
There are a number of circumstances in which the list is not There are a number of circumstances in which the list is not
exhaustive. The simplest is when the round-robin does not return all exhaustive. The simplest is when the round-robin DNS does not return
addresses. This is routinely done by geographical DNS load balancing all addresses. This is routinely done by geographical DNS load-
systems: only the addresses that the balancing system wishes to be balancing systems: Only the addresses that the balancing system
used are returned. wishes to be used are returned.
It can also happen if there are more addresses than will conveniently Failure can also occur if there are more addresses than what will
fit into a DNS reply. The reply will be marked as truncated. (If conveniently fit into a DNS reply. The reply will be marked as
DNSSEC resolution will be done, then the entire RR must be retrieved truncated. (If DNSSEC resolution will be done, then the entire RR
over TCP (or using a larger EDNS(0) size) before being validated) must be retrieved over TCP (or using a larger EDNS(0) size) before
being validated.)
However, in a geographical DNS load balancing system, different However, in a geographical DNS load-balancing system, different
answers are given based upon the locality of the system asking. answers are given based upon the locality of the system asking.
There may also be further layers of round-robin indirection. There may also be further layers of round-robin indirection.
Aside from the list of records being incomplete, the list may have Aside from the list of records being incomplete, the list may have
changed between the time that the MUD controller did the lookup and changed between the time that the MUD controller did the lookup and
the time that the IoT device did the lookup, and this change can the time that the IoT device did the lookup, and this change can
result in a failure for the ACL to match. If the IoT device did not result in a failure for the ACL to match. If the IoT device did not
use the same recursive servers as the MUD controller, then tailored use the same recursive servers as the MUD controller, then tailored
DNS replies and/or truncated round-robin results could return a DNS replies and/or truncated round-robin results could return a
different, and non-overlapping set of addresses. different and non-overlapping set of addresses.
In order to compensate for this, the MUD controller performs regular In order to compensate for this, the MUD controller performs regular
DNS lookups in order to never have stale data. These lookups must be DNS lookups in order to never have stale data. These lookups must be
rate limited to avoid excessive load on the DNS servers, and it may rate-limited to avoid excessive load on the DNS servers, and it may
be necessary to avoid local recursive resolvers. A MUD controller be necessary to avoid local recursive resolvers. A MUD controller
that incorporates its own recursive caching DNS client will be able that incorporates its own recursive caching DNS client will be able
to observe the TTL on the entries, and expire them appropriately. to observe the TTL on the entries and cause them to expire
This cached will last for at least some number of minutes, up to some appropriately. This cache will last for at least some number of
number of days (respecting the TTL), while the underlying DNS data minutes and up to some number of days (respecting the TTL), while the
can change at a higher frequency, providing different answers to underlying DNS data can change at a higher frequency, providing
different queries! different answers to different queries!
A MUD controller that is aware of which recursive DNS server the IoT A MUD controller that is aware of which recursive DNS server the IoT
device will use can instead query that server on a periodic basis. device will use can instead query that server on a periodic basis.
Doing so provides three advantages: Doing so provides three advantages:
1. Any geographic load balancing will base the decision on the 1. Any geographic load-balancing will base the decision on the
geolocation of the recursive DNS server, and the recursive name geolocation of the recursive DNS server, and the recursive name
server will provide the same answer to the MUD controller as to server will provide the same answer to the MUD controller as to
the IoT device. the IoT device.
2. The resulting name to IP address mapping in the recursive name 2. The resulting mapping (of name to IP address) in the recursive
server will be cached, and will remain the same for the entire name server will be cached and will remain the same for the
advertised Time-To-Live reported in the DNS query return. This entire advertised TTL reported in the DNS query return. This
also allows the MUD controller to avoid doing unnecessary also allows the MUD controller to avoid doing unnecessary
queries. queries.
3. if any addresses have been omitted in a round-robin DNS process, 3. If any addresses have been omitted in a round-robin DNS process,
the cache will have the same set of addresses that were returned. the cache will have the same set of addresses that were returned.
The solution of using the same caching recursive resolver as the The solution of using the same caching recursive resolver as the
target device is very simple when the MUD controller is located in a target device is very simple when the MUD controller is located in a
residential CPE device. The device is usually also the policy residential Customer Premises Equipment (CPE) device. The device is
enforcement point for the ACLs, and a caching resolver is typically usually also the policy-enforcement point for the ACLs, and a caching
located on the same device. In addition to convenience, there is a resolver is typically located on the same device. In addition to
shared fate advantage: as all three components are running on the convenience, there is a shared fate advantage: As all three
same device, if the device is rebooted, clearing the cache, then all components are running on the same device, if the device is rebooted
three components will get restarted when the device is restarted. (which clears the cache), then all three components will get
restarted when the device is restarted.
Where the solution is more complex and sometimes more fragile is when The solution is more complex and sometimes more fragile when the MUD
the MUD controller is located elsewhere in an Enterprise, or remotely controller is located elsewhere in an enterprise or remotely in a
in a cloud such as when a Software Defined Network (SDN) is used to cloud, such as when a Software-Defined Network (SDN) is used to
manage the ACLs. The DNS servers for a particular device may not be manage the ACLs. The DNS servers for a particular device may not be
known to the MUD controller, nor the MUD controller be even permitted known to the MUD controller, and the MUD controller may not even be
to make recursive queries to that server if it is known. In this permitted to make recursive queries to that server if it is known.
case, additional installation specific mechanisms are probably needed In this case, additional installation-specific mechanisms are
to get the right view of the DNS. probably needed to get the right view of the DNS.
A critical failure can occur when the device makes a new DNS request A critical failure can occur when the device makes a new DNS request
and receives a new set of IP addresses, but the MUD controller's copy and receives a new set of IP addresses, but the MUD controller's copy
of the addresses has not yet reached their time to live. In that of the addresses has not yet reached their TTL. In that case, the
case, the MUD controller still has the old address(es) implemented in MUD controller still has the old addresses implemented in the ACLs,
the ACLs, but the IoT device has a new address not previously but the IoT device has a new address not previously returned to the
returned to the MUD controller. This can result in a connectivity MUD controller. This can result in a connectivity failure.
failure.
4. DNS and IP Anti-Patterns for IoT Device Manufacturers 4. DNS and IP Anti-Patterns for IoT Device Manufacturers
In many design fields, there are good patterns that should be In many design fields, there are good patterns that should be
emulated, and often there are patterns that should not be emulated. emulated, and often there are patterns that should not be emulated.
The latter are called anti-patterns, as per [antipatterns]. The latter are called anti-patterns, as per [antipattern].
This section describes a number of things which IoT manufacturers This section describes a number of things that IoT manufacturers have
have been observed to do in the field, each of which presents been observed to do in the field, each of which presents difficulties
difficulties for MUD enforcement points. for MUD enforcement points.
4.1. Use of IP Address Literals 4.1. Use of IP Address Literals
A common pattern for a number of devices is to look for firmware A common pattern for a number of devices is to look for firmware
updates in a two-step process. An initial query is made (often over updates in a two-step process. An initial query is made (often over
HTTPS, sometimes with a POST, but the method is immaterial) to a HTTPS, sometimes with a POST, but the method is immaterial) to a
vendor system that knows whether an update is required. vendor system that knows whether an update is required.
The current firmware model of the device is sometimes provided and The current firmware model of the device is sometimes provided, and
then the vendor's authoritative server provides a determination if a then the vendor's authoritative server provides a determination if a
new version is required and, if so, what version. In simpler cases, new version is required and, if so, what version. In simpler cases,
an HTTPS endpoint is queried which provides the name and URL of the an HTTPS endpoint is queried, which provides the name and URL of the
most recent firmware. most recent firmware.
The authoritative upgrade server then responds with a URL of a The authoritative upgrade server then responds with a URL of a
firmware blob that the device should download and install. Best firmware blob that the device should download and install. Best
practice is that firmware is either signed internally ([RFC9019]) so practice is that either firmware is signed internally [RFC9019] so
that it can be verified, or a hash of the blob is provided. that it can be verified, or a hash of the blob is provided.
An authoritative server might be tempted to provide an IP address An authoritative server might be tempted to provide an IP address
literal inside the protocol. An argument for doing this is that it literal inside the protocol. An argument for doing this is that it
eliminates problems with firmware updates that might be caused by eliminates problems with firmware updates that might be caused by a
lack of DNS, or incompatibilities with DNS. For instance a bug that lack of DNS or by incompatibilities with DNS. For instance, a bug
causes interoperability issues with some recursive servers would that causes interoperability issues with some recursive servers would
become unpatchable for devices that were forced to use that recursive become unpatchable for devices that were forced to use that recursive
resolver type. resolver type.
But, there are several problems with the use of IP address literals But, there are several problems with the use of IP address literals
for the location of the firmware. for the location of the firmware.
The first is that the update service server must decide whether to The first is that the update service server must decide whether to
provide an IPv4 or an IPv6 literal, assuming that only one URL can be provide an IPv4 or an IPv6 literal, assuming that only one URL can be
provided. A DNS name can contain both kinds of addresses, and can provided. A DNS name can contain both kinds of addresses and can
also contain many different IP addresses of each kind. An update also contain many different IP addresses of each kind. An update
server might believe that if the connection was on IPv4, that an IPv4 server might believe that if the connection were on IPv4, then an
literate would be acceptable, but due to NAT64 [RFC6146] a device IPv4 literal would be acceptable. However, due to NAT64 [RFC6146], a
with only IPv6 connectivity will often be able to reach an IPv4 device with only IPv6 connectivity will often be able to reach an
firmware update server by name (through DNS64 [RFC6147]), but not be IPv4 firmware update server by name (through DNS64 [RFC6147]) but not
able to reach arbitrary IPv4 address. be able to reach an arbitrary IPv4 address.
A MUD file definition for this access would need to resolve to the A MUD file for this access would need to resolve to the set of IP
set of IP addresses that might be returned by the update server. addresses that might be returned by the update server. This can be
This can be done with IP address literals in the MUD file, but this done with IP address literals in the MUD file, but this may require
may require continuing updates to the MUD file if the addresses continuing updates to the MUD file if the addresses change
change frequently. A DNS name in the MUD could resolve to the set of frequently. A DNS name in the MUD could resolve to the set of all
all possible IPv4 and IPv6 addresses that would be used, with DNS possible IPv4 and IPv6 addresses that would be used, with DNS
providing a level of indirection that obviates the need to update the providing a level of indirection that obviates the need to update the
MUD file itself. MUD file itself.
A third problem involves the use of HTTPS. It is often more A third problem involves the use of HTTPS. It is often more
difficult to get TLS certificates for an IP address, and so it is difficult to get TLS certificates for an IP address, and so it is
less likely that the firmware download will be protected by TLS. An less likely that the firmware download will be protected by TLS.
IP address literal in the TLS ServerNameIndicator [RFC6066], might Even if an IP address literal was placedin the TLS
not provide enough context for a web server to distinguish which of ServerNameIndicator [RFC6066], against the advice of that document,
potentially many tenants, the client wishes to reach. This then it still would not provide enough context for a web server to
drives the use of an IP address per-tenant, and for IPv4 (at least), distinguish which of the (potentially many) tenants the client wishes
this is no longer a sustainable use of IP addresses. to reach. This drives the use of an IP address per tenant, and for
IPv4 (at least), this is no longer a sustainable use of IP addresses.
Finally, it is common in some Content Distribution Networks (CDNs) to Finally, it is common in some CDNs to use multiple layers of DNS
use multiple layers of DNS CNAMEs in order to isolate the content- CNAMEs in order to isolate the content owner's naming system from
owner's naming system from changes in how the distribution network is changes in how the distribution network is organized.
organized.
When a name or address is returned within an update protocol for When a name or address is returned within an update protocol for
which a MUD rule cannot be written, then the MUD controller is unable which a MUD rule cannot be written, then the MUD controller is unable
to authorize the connection. In order for the connection to be to authorize the connection. In order for the connection to be
authorized, the set of names returned within the update protocol authorized, the set of names returned within the update protocol
needs to be known ahead of time, and must be from a finite set of needs to be known ahead of time and must be from a finite set of
possibilities. Such a set of names or addresses can be placed into possibilities. Such a set of names or addresses can be placed into
the MUD file as an ACL in advance, and the connections authorized. the MUD file as an ACL in advance, and the connections can be
authorized.
4.2. Use of Non-deterministic DNS Names in protocols 4.2. Use of Non-Deterministic DNS Names in Protocols
A second pattern is for a control protocol to connect to a known HTTP A second pattern is for a control protocol to connect to a known HTTP
endpoint. This is easily described in MUD. References within that endpoint. This is easily described in MUD. References within that
control protocol are made to additional content at other URLs. The control protocol are made to additional content at other URLs. The
values of those URLs do not fit any easily described pattern and may values of those URLs do not fit any easily described pattern and may
point at arbitrary DNS names. point to arbitrary DNS names.
Those DNS names are often within some third-party CDN system, or may Those DNS names are often within some third-party CDN system or may
be arbitrary DNS names in a cloud-provider storage system (e.g., be arbitrary DNS names in a cloud-provider storage system (e.g.,
[AmazonS3], or [Akamai]). Some of the name components may be [AmazonS3] or [Akamai]). Some of the name components may be
specified by the third party CDN provider. specified by the third-party CDN provider.
Such DNS names may be unpredictably chosen by the CDN, and not the Such DNS names may be unpredictably chosen by the CDN and not the
device manufacturer, and so impossible to insert into a MUD file. device manufacturer and therefore impossible to insert into a MUD
Implementation of the CDN system may also involve HTTP redirections file. Implementation of the CDN system may also involve HTTP
to downstream CDN systems. redirections to downstream CDN systems.
Even if the CDN provider's chosen DNS names are deterministic they Even if the CDN provider's chosen DNS names are deterministic, they
may change at a rate much faster than MUD files can be updated. may change at a rate much faster than MUD files can be updated.
This situation applies to firmware updates, but also applies to many This situation applies to firmware updates but also applies to many
other kinds of content: video content, in-game content, etc. other kinds of content: video content, in-game content, etc.
A solution may be to use a deterministic DNS name, within the control A solution may be to use a deterministic DNS name within the control
of the device manufacturer. The device manufacturer is asked to of the device manufacturer. The device manufacturer is asked to
point a CNAME to the CDN, to a name that might look like point a CNAME to the CDN, to a name that might look like
"g7.a.example", with the expectation that the CDN vendors DNS will do "g7.a.example", with the expectation that the CDN provider's DNS will
all the appropriate work to geolocate the transfer. This can be fine do all the appropriate work to geolocate the transfer. This can be
for a MUD file, as the MUD controller, if located in the same fine for a MUD file, as the MUD controller, if located in the same
geography as the IoT device, can follow the CNAME, and can collect geography as the IoT device, can follow the CNAME and collect the set
the set of resulting IP addresses, along with the TTL for each. The of resulting IP addresses along with the TTL for each. Then, the MUD
MUD controller can then take charge of refreshing that mapping at controller can take charge of refreshing that mapping at intervals
intervals driven by the TTL. driven by the TTL.
In some cases, a complete set of geographically distributed servers In some cases, a complete set of geographically distributed servers
may be known ahead of time (or that it changes very slowly), and the may be known ahead of time (or that it changes very slowly), and the
device manufacturer can list all those IP addresses in the DNS for device manufacturer can list all those IP addresses in the DNS for
the the name that it lists in the MUD file. As long as the active the name that it lists in the MUD file. As long as the active set of
set of addresses used by the CDN is a strict subset of that list, addresses used by the CDN is a strict subset of that list, then the
then the geolocated name can be used for the content download itself. geolocated name can be used for the content download itself.
4.3. Use of a Too Generic DNS Name 4.3. Use of a Too Generic DNS Name
Some CDNs make all customer content available at a single URL (such Some CDNs make all customer content available at a single URL (such
as "s3.example.com"). This seems to be ideal from a MUD point of as "s3.example.com"). This seems to be ideal from a MUD point of
view: a completely predictable URL. view: a completely predictable URL.
The problem is that a compromised device could then connect to the The problem is that a compromised device could then connect to the
contents of any bucket, potentially attacking the data from other contents of any bucket, potentially attacking the data from other
customers. customers.
Exactly what the risk is depends upon what the other customers are Exactly what the risk is depends upon what the other customers are
doing: it could be limited to simply causing a distributed denial-of- doing: It could be limited to simply causing a distributed denial-of-
service attack resulting in high costs to those customers, or such an service attack resulting in high costs to those customers, or such an
attack could potentially include writing content. attack could potentially include writing content.
Amazon has recognized the problems associated with this practice, and Amazon has recognized the problems associated with this practice and
aims to change it to a virtual hosting model, as per aims to change it to a virtual hosting model, as per
[awss3virtualhosting]. [awss3virtualhosting].
The MUD ACLs provide only for permitting end points (hostnames and The MUD ACLs provide only for permitting endpoints (hostnames and
ports), but do not filter URLs (nor could filtering be enforced ports) but do not filter URLs (nor could filtering be enforced within
within HTTPS). HTTPS).
5. DNS Privacy and Outsourcing versus MUD Controllers 5. DNS Privacy and Outsourcing versus MUD Controllers
[RFC7858] and [RFC8094] provide for DoT and DoH. [RFC7858] and [RFC8094] provide for DoT and DoH. [RFC9499] details
[I-D.ietf-dnsop-rfc8499bis] details the terms. But, even with the the terms. But, even with the unencrypted DNS (a.k.a. Do53), it is
unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS possible to outsource DNS queries to other public services, such as
queries to other public services, such as those operated by Google, those operated by Google, CloudFlare, Verisign, etc.
CloudFlare, Verisign, etc.
For some users and classes of devices, revealing the DNS queries to For some users and classes of devices, revealing the DNS queries to
those outside entities may constitute a privacy concern. For other those outside entities may constitute a privacy concern. For other
users the use of an insecure local resolver may constitute a privacy users, the use of an insecure local resolver may constitute a privacy
concern. concern.
As described above in Section 3 the MUD controller needs to have As described in Section 3, the MUD controller needs to have access to
access to the same resolver(s) as the IoT device. If the IoT device the same resolver or resolvers as the IoT device. If the IoT device
does not use the DNS servers provided to it via DHCP or Router does not use the DNS servers provided to it via DHCP or Router
Advertisements, then the MUD controller will need to be told which Advertisements, then the MUD controller will need to be told which
servers will in fact be used. As yet, there is no protocol to do servers will in fact be used. As yet, there is no protocol to do
this, but future work could provide this as an extension to MUD. this, but future work could provide this as an extension to MUD.
Until such time as such a protocol exists, the best practice is for Until such time as such a protocol exists, the best practice is for
the IoT device to always use the DNS servers provided by DHCP or the IoT device to always use the DNS servers provided by DHCP or
Router Advertisements. Router Advertisements.
6. Recommendations To IoT Device Manufacturers on MUD and DNS Usage 6. Recommendations to IoT Device Manufacturers on MUD and DNS Usage
Inclusion of a MUD file with IoT devices is operationally quite Inclusion of a MUD file with IoT devices is operationally quite
simple. It requires only a few small changes to the DHCP client code simple. It requires only a few small changes to the DHCP client code
to express the MUD URL. It can even be done without code changes via to express the MUD URL. It can even be done without code changes via
the use of a QR code affixed to the packaging (see [RFC9238]) the use of a QR code affixed to the packaging (see [RFC9238]).
The difficult part is determining what to put into the MUD file The difficult part is determining what to put into the MUD file
itself. There are currently tools that help with the definition and itself. There are currently tools that help with the definition and
analysis of MUD files, see [mudmaker]. The remaining difficulty is analysis of MUD files; see [mudmaker]. The remaining difficulty is
now the actual list of expected connections to put in the MUD file. the actual list of expected connections to put in the MUD file. An
An IoT manufacturer must now spend some time reviewing the network IoT manufacturer must spend some time reviewing the network
communications by their device. communications by their device.
This document discusses a number of challenges that occur relating to This document discusses a number of challenges that occur relating to
how DNS requests are made and resolved, and the goal of this section how DNS requests are made and resolved, and the goal of this section
is to make recommendations on how to modify IoT systems to work well is to make recommendations on how to modify IoT systems to work well
with MUD. with MUD.
6.1. Consistently use DNS 6.1. Consistently Use DNS
For the reasons explained in Section 4.1, the most important For the reasons explained in Section 4.1, the most important
recommendation is to avoid using IP address literals in any protocol. recommendation is to avoid using IP address literals in any protocol.
DNS names should always be used. DNS names should always be used.
6.2. Use Primary DNS Names Controlled By The Manufacturer 6.2. Use Primary DNS Names Controlled by the Manufacturer
The second recommendation is to allocate and use DNS names within The second recommendation is to allocate and use DNS names within
zones controlled by the manufacturer. These DNS names can be zones controlled by the manufacturer. These DNS names can be
populated with an alias (see [I-D.ietf-dnsop-rfc8499bis] section 2) populated with an alias (see [RFC9499], Section 2) that points to the
that points to the production system. Ideally, a different name is production system. Ideally, a different name is used for each
used for each logical function, allowing for different rules in the logical function, allowing different rules in the MUD file to be
MUD file to be enabled and disabled. enabled and disabled.
While it used to be costly to have a large number of aliases in a web While it used to be costly to have a large number of aliases in a web
server certificate, this is no longer the case. Wildcard server certificate, this is no longer the case. Wildcard
certificates are also commonly available which allow for an infinite certificates are also commonly available; they allow for an infinite
number of possible DNS names. number of possible DNS names.
6.3. Use Content-Distribution Network with Stable DNS Names 6.3. Use a Content Distribution Network with Stable DNS Names
When aliases point to a CDN, prefer stable DNS names that point to When aliases point to a CDN, give preference to stable DNS names that
appropriately load balanced targets. CDNs that employ very low time- point to appropriately load-balanced targets. CDNs that employ very
to-live (TTL) values for DNS make it harder for the MUD controller to low TTL values for DNS make it harder for the MUD controller to get
get the same answer as the IoT Device. A CDN that always returns the the same answer as the IoT device. A CDN that always returns the
same set of A and AAAA records, but permutes them to provide the best same set of A and AAAA records, but permutes them to provide the best
one first provides a more reliable answer. one first, provides a more reliable answer.
6.4. Do Not Use Tailored Responses to answer DNS Names 6.4. Do Not Use Tailored Responses to Answer DNS Names
[RFC7871] defines the edns-client-subnet (ECS) EDNS0 option, and [RFC7871] defines the edns-client-subnet (ECS) EDNS0 option and
explains how authoritative servers sometimes answer queries explains how authoritative servers sometimes answer queries
differently based upon the IP address of the end system making the differently based upon the IP address of the end system making the
request. Ultimately, the decision is based upon some topological request. Ultimately, the decision is based upon some topological
notion of closeness. This is often used to provide tailored notion of closeness. This is often used to provide tailored
responses to clients, providing them with a geographically responses to clients, providing them with a geographically
advantageous answer. advantageous answer.
When the MUD controller makes its DNS query, it is critical that it When the MUD controller makes its DNS query, it is critical that it
receive an answer which is based upon the same topological decision receives an answer that is based upon the same topological decision
as when the IoT device makes its query. as when the IoT device makes its query.
There are probably ways in which the MUD controller could use the There are probably ways in which the MUD controller could use the
edns-client-subnet option to make a query that would get the same edns-client-subnet option to make a query that would get the same
treatment as when the IoT device makes its query. If this worked treatment as when the IoT device makes its query. If this worked,
then it would receive the same answer as the IoT device. then it would receive the same answer as the IoT device.
In practice it could be quite difficult if the IoT device uses a In practice it could be quite difficult if the IoT device uses a
different Internet connection, a different firewall, or a different different Internet connection, a different firewall, or a different
recursive DNS server. The edns-client-server might be ignored or recursive DNS server. The edns-client-subnet option might be ignored
overridden by any of the DNS infrastructure. or overridden by any of the DNS infrastructure.
Some tailored responses might only re-order the replies so that the Some tailored responses might only reorder the replies so that the
most preferred address is first. Such a system would be acceptable most preferred address is first. Such a system would be acceptable
if the MUD controller had a way to know that the list was complete. if the MUD controller had a way to know that the list was complete.
But, due to the above problems, a strong recommendation is to avoid But, due to the above problems, a strong recommendation is to avoid
using tailored responses as part of the DNS names in the MUD file. using tailored responses as part of the DNS names in the MUD file.
6.5. Prefer DNS Servers Learnt From DHCP/Router Advertisements 6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements
The best practice is for IoT Devices to do DNS with the DHCP provided The best practice is for IoT devices to do DNS with the DHCP-provided
DNS servers, or DNS servers learnt from Router Advertisements DNS servers or with DNS servers learned from Router Advertisements
[RFC8106]. [RFC8106].
The ADD WG has written [RFC9463] and [RFC9462] to provide information The Adaptive DNS Discovery (ADD) Working Group has written [RFC9462]
to end devices on how to find locally provisioned secure/private DNS and [RFC9463] to provide information to end devices on how to find
servers. locally provisioned secure/private DNS servers.
Use of public resolvers instead of the locally provided DNS resolver, Use of public resolvers instead of the locally provided DNS resolver,
whether Do53, DoQ, DoT or DoH is discouraged. whether Do53, DoQ, DoT, or DoH, is discouraged.
Some manufacturers would like to have a fallback to using a public Some manufacturers would like to have a fallback to using a public
resolver to mitigate against local misconfiguration. There are a resolver to mitigate against local misconfiguration. There are a
number of reasons to avoid this, detailed in Section 6.4. The public number of reasons to avoid this, detailed in Section 6.4. The public
resolver might not return the same tailored names that the MUD resolver might not return the same tailored names that the MUD
controller would get. controller would get.
It is recommended that use of non-local resolvers is only done when It is recommended that non-local resolvers are only used when the
the locally provided resolvers provide no answers to any queries at locally provided resolvers provide no answers to any queries at all
all, and do so repeatedly. The status of the operator provided and do so repeatedly. The status of the operator-provided resolvers
resolvers needs to be re-evaluated on a periodic basis. needs to be re-evaluated on a periodic basis.
Finally, if a device will ever attempt to use a non-local resolvers, Finally, if a device will ever attempt to use non-local resolvers,
then the address of that resolver needs to be listed in the MUD file then the addresses of those resolvers need to be listed in the MUD
as destinations that are to be permitted. This needs to include the file as destinations that are to be permitted. This needs to include
port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be used the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be
as well. used as well.
7. Interactions with mDNS and DNSSD 7. Interactions with mDNS and DNS-SD
Unicast DNS requests are not the only way to map names to IP Unicast DNS requests are not the only way to map names to IP
addresses. IoT devices might also use mDNS [RFC6762], both to be addresses. IoT devices might also use Multicast DNS (mDNS)
discovered by other devices, and also to discover other devices. [RFC6762], both to be discovered by other devices and also to
discover other devices.
mDNS replies include A and AAAA records, and it is conceivable that mDNS replies include A and AAAA records, and it is conceivable that
these replies contain addresses which are not local to the link on these replies contain addresses that are not local to the link on
which they are made. This could be the result of another device which they are made. This could be the result of another device that
which contains malware. An unsuspecting IoT device could be led to contains malware. An unsuspecting IoT device could be led to contact
contact some external host as a result. Protecting against such some external host as a result. Protecting against such things is
things is one of the benefits of MUD. one of the benefits of MUD.
In the unlikely case that the external host has been listed as a In the unlikely case that the external host has been listed as a
legitimate destination in a MUD file, then communication will legitimate destination in a MUD file, communication will continue as
continue as expected. As an example of this, an IoT device might expected. As an example, an IoT device might look for a name like
look for a name like "update.local" in order to find a source of "update.local" in order to find a source of firmware updates. It
firmware updates. It could be led to connect to some external host could be led to connect to some external host that was listed as
that was listed as "update.example" in the MUD file. This should "update.example" in the MUD file. This should work fine if the name
work fine if the name "update.example" does not require any kind of "update.example" does not require any kind of tailored reply.
tailored reply.
In residential networks there has typically not been more than one In residential networks, there has typically not been more than one
network (although this is changing through work like network (although this is changing through work like
[I-D.ietf-snac-simple]), but on campus or enterprise networks, having [AUTO-STUB-NETWORKS]), but on campus or enterprise networks, having
more than one network is not unusual. In such networks, mDNS is more than one network is not unusual. In such networks, mDNS is
being replaced with DNS-SD [RFC8882], and in such a situation, being replaced with DNS-based Service Discovery (DNS-SD) [RFC8882],
connections could be initiated to other parts of the network. Such and in such a situation, connections could be initiated to other
connections might traverse the MUD policy enforcement point (an parts of the network. Such connections might traverse the MUD policy
intra-department firewall), and could very well be rejected because enforcement point (an intra-department firewall) and could very well
the MUD controller did not know about that interaction. be rejected because the MUD controller did not know about that
interaction.
[RFC8250] includes a number of provisions for controlling internal [RFC8250] includes a number of provisions for controlling internal
communications, including complex communications like same communications, including complex communications like same
manufacturer ACLs. To date, this aspect of MUD has been difficult to manufacturer ACLs. To date, this aspect of MUD has been difficult to
describe. This document does not consider internal communications to describe. This document does not consider internal communications to
be in scope. be in scope.
8. Privacy Considerations 8. IANA Considerations
This document has no IANA actions.
9. Privacy Considerations
The use of non-local DNS servers exposes the list of DNS names The use of non-local DNS servers exposes the list of DNS names
resolved to a third party, including passive eavesdroppers. resolved to a third party, including passive eavesdroppers.
The use of DoT and DoH eliminates the threat from passive The use of DoT and DoH eliminates the threat from passive
eavesdropping, but still exposes the list to the operator of the DoT eavesdropping but still exposes the list to the operator of the DoT
or DoH server. There are additional methods to help preserve or DoH server. There are additional methods to help preserve
privacy, such as described by [RFC9230]. privacy, such as that described by [RFC9230].
The use of unencrypted (Do53) requests to a local DNS server exposes The use of unencrypted (Do53) requests to a local DNS server exposes
the list to any internal passive eavesdroppers, and for some the list to any internal passive eavesdroppers. For some situations,
situations that may be significant, particularly if unencrypted Wi-Fi that may be significant, particularly if unencrypted WiFi is used.
is used.
Use of Encrypted DNS connection to a local DNS recursive resolver is Use of an encrypted DNS connection to a local DNS recursive resolver
the preferred choice. is the preferred choice.
IoT devices that reach out to the manufacturer at regular intervals IoT devices that reach out to the manufacturer at regular intervals
to check for firmware updates are informing passive eavesdroppers of to check for firmware updates are informing passive eavesdroppers of
the existence of a specific manufacturer's device being present at the existence of a specific manufacturer's device being present at
the origin location. the origin location.
Identifying the IoT device type empowers the attacker to launch Identifying the IoT device type empowers the attacker to launch
targeted attacks to the IoT device (e.g., Attacker can take advantage targeted attacks to the IoT device (e.g., the attacker can take
of any known vulnerability on the device). advantage of any known vulnerability on the device).
While possession of a Large (Kitchen) Appliance at a residence may be While possession of a "large kitchen appliance" at a residence may be
uninteresting to most, possession of intimate personal devices (e.g., uninteresting to most, possession of intimate personal devices (e.g.,
"sex toys") may be a cause for embarrassment. "sex toys") may be a cause for embarrassment.
IoT device manufacturers are encouraged to find ways to anonymize IoT device manufacturers are encouraged to find ways to anonymize
their update queries. For instance, contracting out the update their update queries. For instance, contracting out the update
notification service to a third party that deals with a large variety notification service to a third party that deals with a large variety
of devices would provide a level of defense against passive of devices would provide a level of defense against passive
eavesdropping. Other update mechanisms should be investigated, eavesdropping. Other update mechanisms should be investigated,
including use of DNSSEC signed TXT records with current version including use of DNSSEC-signed TXT records with current version
information. This would permit DoT or DoH to convey the update information. This would permit DoT or DoH to convey the update
notification in a private fashion. This is particularly powerful if notification in a private fashion. This is particularly powerful if
a local recursive DoT server is used, which then communicates using a local recursive DoT server is used, which then communicates using
DoT over the Internet. DoT over the Internet.
The more complex case of Section 4.1 postulates that the version The more complex case of Section 4.1 postulates that the version
number needs to be provided to an intelligent agent that can decide number needs to be provided to an intelligent agent that can decide
the correct route to do upgrades. [RFC9019] provides a wide variety the correct route to do upgrades. [RFC9019] provides a wide variety
of ways to accomplish the same thing without having to divulge the of ways to accomplish the same thing without having to divulge the
current version number. current version number.
9. Security Considerations 10. Security Considerations
This document deals with conflicting Security requirements: This document deals with conflicting security requirements:
1. devices which an operator wants to manage using [RFC8520] * devices that an operator wants to manage using [RFC8520]
2. requirements for the devices to get access to network resources * requirements for the devices to get access to network resources
that may be critical to their continued safe operation. that may be critical to their continued safe operation
This document takes the view that the two requirements do not need to This document takes the view that the two requirements do not need to
be in conflict, but resolving the conflict requires careful planning be in conflict, but resolving the conflict requires careful planning
on how the DNS can be safely and effectively used by MUD controllers on how the DNS can be safely and effectively be used by MUD
and IoT devices. controllers and IoT devices.
When an IoT device with an inaccurate MUD file is deployed into a When an IoT device with an inaccurate MUD file is deployed into a
network that uses MUD, there is a significant possibility that the network that uses MUD, there is a significant possibility that the
device will cause a spurious security exception to be raised. There device will cause a spurious security exception to be raised. There
is significant evidence that such spurious exceptions cause is significant evidence that such spurious exceptions can cause
significant overhead to personnel. In particular, repeated spurious significant overhead to personnel. In particular, repeated spurious
exceptions are likely to cause the entire exception process to be exceptions are likely to cause the entire exception process to be
turned off. When MUD alerts are turned off, then even legitimate turned off. When MUD alerts are turned off, then even legitimate
exceptions are ignored. This is very much a Boy Who Calls Wolf exceptions are ignored. This is very much a Boy Who Calls Wolf
[boywhocriedwolf] situation. [boywhocriedwolf] situation.
In order to avoid this situation, and for MUD alerts to be given In order to avoid this situation, and for MUD alerts to be given
appropriate attention, it is key that IoT device manufacturers create appropriate attention, it is key that IoT device manufacturers create
accurate MUD files. This may require some significant thought, even accurate MUD files. This may require some significant thought and
rework of key systems, so that all network access required by the IoT even rework of key systems so that all network access required by the
device can be described by a MUD file. This level of informed IoT device can be described by a MUD file. This level of informed
cooperation within the IoT device vendor and with MUD controller cooperation within the IoT device vendor and with MUD controller
manufacturers is key to getting significant return on investment from manufacturers is key to getting significant return on investment from
MUD. MUD.
Manufacturers are encouraged to write MUD files that are good enough, Manufacturers are encouraged to write MUD files that are good enough
rather than perfect. If in doubt, they should write MUD files that rather than perfect. If in doubt, they should write MUD files that
are somewhat more permissive if it results in no spurious alerts. are somewhat more permissive if the files result in no spurious
alerts.
10. References
10.1. Normative References 11. References
[I-D.ietf-dnsop-rfc8499bis] 11.1. Normative References
Hoffman, P. E. and K. Fujiwara, "DNS Terminology", Work in
Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-10,
25 September 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnsop-rfc8499bis-10>.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
DOI 10.17487/RFC1794, April 1995, DOI 10.17487/RFC1794, April 1995,
<https://www.rfc-editor.org/info/rfc1794>. <https://www.rfc-editor.org/info/rfc1794>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
skipping to change at page 16, line 15 skipping to change at line 691
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520, Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019, DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>. <https://www.rfc-editor.org/info/rfc8520>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things", Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021, RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/info/rfc9019>. <https://www.rfc-editor.org/info/rfc9019>.
10.2. Informative References [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[Akamai] "Akamai", 2019, 11.2. Informative References
<https://en.wikipedia.org/wiki/Akamai_Technologies>.
[AmazonS3] "Amazon S3", 2019, [Akamai] Wikipedia, "Akamai Technologies", 26 February 2025,
<https://en.wikipedia.org/wiki/Amazon_S3>. <https://en.wikipedia.org/w/
index.php?title=Akamai_Technologies&oldid=1277665363>.
[antipatterns] [AmazonS3] Wikipedia, "Amazon S3", 14 March 2025,
"AntiPattern", 12 July 2021, <https://en.wikipedia.org/w/
index.php?title=Amazon_S3&oldid=1280379498>.
[antipattern]
Agile Alliance, "AntiPattern",
<https://www.agilealliance.org/glossary/antipattern>. <https://www.agilealliance.org/glossary/antipattern>.
[AUTO-STUB-NETWORKS]
Lemon, T. and J. Hui, "Automatically Connecting Stub
Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-06, 4 November
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
snac-simple-06>.
[awss3virtualhosting] [awss3virtualhosting]
"Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation Tech Monitor, "Down to the Wire: AWS Delays 'Path-Style'
at Last Minute", 12 July 2021, S3 Deprecation at Last Minute", 24 September 2020,
<https://techmonitor.ai/techonology/cloud/aws-s3-path- <https://techmonitor.ai/techonology/cloud/aws-s3-path-
deprecation>. deprecation>.
[boywhocriedwolf] [boywhocriedwolf]
"Boy who Cried Wolf", 15 August 2024, Wikipedia, "The Boy Who Cried Wolf", 6 February 2025,
<https://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf>. <https://en.wikipedia.org/w/
index.php?title=The_Boy_Who_Cried_Wolf&oldid=1274257821>.
[I-D.ietf-snac-simple]
Lemon, T. and J. Hui, "Automatically Connecting Stub
Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-05, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-snac-
simple-05>.
[mudmaker] "Mud Maker", 2019, <https://mudmaker.org>. [mudmaker] "MUD Maker", <https://mudmaker.org>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
skipping to change at page 18, line 26 skipping to change at line 804
Jensen, "Discovery of Designated Resolvers", RFC 9462, Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023, DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/info/rfc9462>. <https://www.rfc-editor.org/info/rfc9462>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)", the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023, RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>. <https://www.rfc-editor.org/info/rfc9463>.
Appendix A. A Failing Strategy --- Anti-Patterns Appendix A. A Failing Strategy: Anti-Patterns
Attempts to map IP addresses to DNS names in real time often fails Attempts to map IP addresses to DNS names in real time often fail for
for a number of reasons: a number of reasons:
1. it can not be done fast enough, 1. It can not be done fast enough.
2. it reveals usage patterns of the devices, 2. It reveals usage patterns of the devices.
3. the mappings are often incomplete, 3. The mappings are often incomplete.
4. Even if the mapping is present, due to virtual hosting, it may 4. Even if the mapping is present, due to virtual hosting, it may
not map back to the name used in the ACL. not map back to the name used in the ACL.
This is not a successful strategy: for reasons explained below. This is not a successful strategy for the reasons explained below.
A.1. Too Slow A.1. Too Slow
Mappings of IP addresses to DNS names requires a DNS lookup in the Mappings of IP addresses to DNS names require a DNS lookup in the in-
in-addr.arpa or ip6.arpa space. For a cold DNS cache, this will addr.arpa or ip6.arpa space. For a cold DNS cache, this will
typically require 2 to 3 NS record lookups to locate the DNS server typically require 2 to 3 NS record lookups to locate the DNS server
that holds the information required. At 20 to 100 ms per round trip, that holds the information required. At 20 to 100 ms per round 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. that caused the lookup can be released.
While subsequent connections to the same site (and subsequent packets While subsequent connections to the same site (and subsequent packets
in the same flow) will not be affected if the results are cached, the in the same flow) will not be affected if the results are cached, the
effects will be felt. The ACL results can be cached for a period of effects will be felt. The ACL results can be cached for a period of
time given by the TTL of the DNS results, but the DNS lookup must be time given by the TTL of the DNS results, but the DNS lookup must be
repeated, e.g, in a few hours or days,when the cached IP address to repeated, e.g., in a few hours or days, when the cached binding (of
name binding expires. IP address to name) expires.
A.2. Reveals Patterns of Usage A.2. Reveals Patterns of Usage
By doing the DNS lookups when the traffic occurs, then a passive By doing the DNS lookups when the traffic occurs, then a passive
attacker can see when the device is active, and may be able to derive attacker can see when the device is active and may be able to derive
usage patterns. They could determine when a home was occupied or usage patterns. They could determine when a home was occupied or
not. This does not require access to all on-path data, just to the not. This does not require access to all on-path data, just to the
DNS requests to the bottom level of the DNS tree. DNS requests to the bottom level of the DNS tree.
A.3. Mappings Are Often Incomplete A.3. Mappings Are Often Incomplete
An IoT manufacturer with a cloud service provider that fails to An IoT manufacturer with a cloud service provider that fails to
include an A or AAAA record as part of their forward name publication include an A or AAAA record as part of their forward name publication
will find that the new server is simply not used. The operational will find that the new server is simply not used. The operational
feedback for that mistake is immediate. The same is not true for feedback for that mistake is immediate. The same is not true for
reverse DNS mappings: they can often be incomplete or incorrect for reverse DNS mappings: They can often be incomplete or incorrect for
months or even years without visible effect on operations. months or even years without a visible effect on operations.
IoT manufacturer cloud service providers often find it difficult to IoT manufacturer cloud service providers often find it difficult to
update reverse DNS maps in a timely fashion, assuming that they can update reverse DNS maps in a timely fashion, assuming that they can
do it at all. Many cloud based solutions dynamically assign IP do it at all. Many cloud-based solutions dynamically assign IP
addresses to services, often as the service grows and shrinks, addresses to services, often as the service grows and shrinks,
reassigning those IP addresses to other services quickly. The use of reassigning those IP addresses to other services quickly. The use of
HTTP 1.1 Virtual Hosting may allow addresses and entire front-end HTTP 1.1 Virtual Hosting may allow addresses and entire front-end
systems to be re-used dynamically without even reassigning the IP systems to be reused dynamically without even reassigning the IP
addresses. addresses.
In some cases there are multiple layers of CNAME between the original In some cases, there are multiple layers of CNAME between the
name and the target service name. This is often due to a load original name and the target service name. This is often due to a
balancing layer in the DNS, followed by a load balancing layer at the load-balancing layer in the DNS followed by a load-balancing layer at
HTTP level. the HTTP level.
The reverse DNS mapping for the IP address of the load balancer The reverse DNS mapping for the IP address of the load balancer
usually does not change. If hundreds of web services are funneled usually does not change. If hundreds of web services are funneled
through the load balancer, it would require hundreds of PTR records through the load balancer, it would require hundreds of PTR records
to be deployed. This would easily exceed the UDP/DNS and EDNS0 to be deployed. This would easily exceed the UDP/DNS and EDNS0
limits, and require all queries to use TCP, which would further slow limits and require all queries to use TCP, which would further slow
down loading of the records. down loading of the records.
The enumeration of all services/sites that have been at that load The enumeration of all services/sites that have been at that load
balancer might also constitute a security concern. To limit churn of balancer might also constitute a security concern. To limit the
DNS PTR records, and reduce failures of the MUD ACLs, operators would churn of DNS PTR records and reduce failures of the MUD ACLs,
want to add all possible DNS names for each reverse DNS mapping, operators would want to add all possible DNS names for each reverse
whether or not the DNS load balancing in the forward DNS space lists DNS mapping, whether or not the DNS load-balancing in the forward DNS
that end-point at that moment. space lists that endpoint at that moment.
A.4. Forward DNS Names Can Have Wildcards A.4. Forward DNS Names Can Have Wildcards
In some large hosting providers content is hosted through a domain In some large hosting providers, content is hosted through a domain
name that is published as a DNS wildcard (and uses a wildcard name that is published as a DNS wildcard (and uses a wildcard
certificate). For instance, github.io, which is used for hosted certificate). For instance, github.io, which is used for hosting
content, including the Editors' copy of internet drafts stored on content, including the Editors' copy of Internet-Drafts stored on
github, does not actually publish any DNS names. Instead, a wildcard GitHub, does not actually publish any DNS names. Instead, a wildcard
exists to answer all potential DNS names: requests are routed exists to answer all potential DNS names: Requests are routed
appropriate once they are received. appropriately once they are received.
This kind of system works well for self-managed hosted content. This kind of system works well for self-managed hosted content.
However, while it is possible to insert up to a few dozen PTR However, while it is possible to insert up to a few dozen PTR
records, many thousand entries are not possible, nor is it possible records, many thousands of entries are not possible, nor is it
to deal with the unlimited (infinite) number of possibilities that a possible to deal with the unlimited (infinite) number of
wildcard supports. possibilities that a wildcard supports.
It would be therefore impossible for the PTR reverse lookup to ever Therefore, it would be impossible for the PTR reverse lookup to ever
work with these wildcard DNS names. work with these wildcard DNS names.
Contributors Contributors
Tirumaleswar Reddy Tirumaleswar Reddy.K
Nokia Nokia
Authors' Addresses Authors' Addresses
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Wei Pan Wei Pan
Huawei Technologies Huawei Technologies
 End of changes. 151 change blocks. 
382 lines changed or deleted 369 lines changed or added

This html diff was produced by rfcdiff 1.48.