RFC 9726

Operational Considerations for Use of DNS in Internet of Things (IoT) Devices

📅 published March 2025, from ietf

🎀 RFC 9726: Operational Considerations for Use of DNS in IoT Devices 🦋

Okay bestie, this is BCP 241 💅, a Best Current Practice, dated March 2025. It was written by M. Richardson of Sandelman Software Works and W. Pan of Huawei Technologies. The ISSN is 2070-1721. The header doesn't list any Obsoletes or Updates lines, so this doesn't replace or change any earlier RFC according to its own title block 📄✨.

Abstract

Okay so this doc is all about how IoT devices (smart fridges, bulbs, cameras, the whole cozy gang 🧚) use IP addresses and DNS names 🌸. It's giving extremely high stakes, because network operators are starting to deploy Manufacturer Usage Descriptions (MUD), as specified in RFC 8520, to decide which devices can access what 🔥. The whole thing gets intense really fast.

It also gives recommendations on when and how to use DNS names inside MUD files 💜.

Status of This Memo

This memo documents an Internet Best Current Practice 🌈.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on BCPs, check Section 2 of RFC 7841 💖.

Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc9726 ✨.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved 💅.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License 📜🎀.

Table of Contents 🧚

   1.  Introduction
   2.  Terminology
   3.  A Model for MUD Controller Mapping of DNS Names to Addresses
     3.1.  Non-Deterministic Mappings
   4.  DNS and IP Anti-Patterns for IoT Device Manufacturers
     4.1.  Use of IP Address Literals
     4.2.  Use of Non-Deterministic DNS Names in Protocols
     4.3.  Use of a Too Generic DNS Name
   5.  DNS Privacy and Outsourcing versus MUD Controllers
   6.  Recommendations to IoT Device Manufacturers on MUD and DNS
           Usage
     6.1.  Consistently Use DNS
     6.2.  Use Primary DNS Names Controlled by the Manufacturer
     6.3.  Use a Content Distribution Network with Stable DNS Names
     6.4.  Do Not Use Tailored Responses to Answer DNS Names
     6.5.  Prefer DNS Servers Learned from DHCP/Router Advertisements
   7.  Interactions with mDNS and DNS-SD
   8.  IANA Considerations
   9.  Privacy Considerations
   10. Security Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Appendix A.  A Failing Strategy: Anti-Patterns
     A.1.  Too Slow
     A.2.  Reveals Patterns of Usage
     A.3.  Mappings Are Often Incomplete
     A.4.  Forward DNS Names Can Have Wildcards
   Contributors
   Authors' Addresses

1. Introduction ✨

Okay so [RFC8520] gives us a standard way to describe how a device with one specific job uses internet resources 🤖. Access Control Lists (ACLs) can be written into a Manufacturer Usage Description (MUD) file [RFC8520], and they let a device reach internet resources by DNS name or by IP address 🔥.

Using a DNS name instead of an IP address in an ACL is honestly iconic 💅. The extra layer of indirection means the name-to-address mapping can change over time. It also works for IPv4 and IPv6 automatically, and it allows all kinds of load-balancing, including multi-CDN setups where load-balancing can account for geography and load 🌍💜.

BUT, the use of DNS names changes how ACLs get executed at the MUD policy enforcement point (usually a firewall) 😭. The firewall only has access to the Layer 3 headers of the packet. That includes the source and destination IP addresses and, if IPsec isn't encrypting it, the destination UDP or TCP port number in the transport header. The DNS name is not in there at all! 💀

So if we want these name-based ACLs to work, there has to be a mapping between the names in the ACLs and IP addresses 🧩.

For manufacturers to understand how to configure DNS for name-based ACLs, we need a model of how MUD controllers will do DNS resolution 🎀. Section 3 walks through some good strategies that could be used 🌸.

This model is non-normative, but it's included so IoT device manufacturers can understand how DNS will be used to resolve the names they use 🫶.

Some ways of using DNS are going to cause problems for MUD controllers, and Section 4 explains them 🙈.

Section 5 covers how current DNS trends such as public DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can break the strategies in use 😤.

The heart of this document is Section 6 🦋. It's a set of recommendations ("best current practices") for manufacturers on how to use DNS and IP addresses with IoT devices described by MUD 💖.

Section 9 talks about privacy issues that encrypted DNS (for example, DoT and DoH) is often used to handle 🔐. How these concerns apply to IoT devices inside a home or an enterprise is a big deal 🏠.

Section 10 also covers some of the bad outcomes that can happen if MUD/firewall managers and IoT manufacturers don't cooperate 💀✨.

2. Terminology 📚

This document uses terms defined in [RFC8520] and [RFC9499] 🌈.

The term "anti-pattern" comes from agile software design literature, as per [antipattern] 💅.

"CDNs" refers to Content Distribution Networks, like the ones described in [RFC6707], Section 1.1 🚀.

3. A Model for MUD Controller Mapping of DNS Names to Addresses 🧚

This section describes one strategy a MUD controller could take 🔮. Within the limits of the DNS use detailed in Section 6, this process could work. The methods in Appendix A just will not work 🙅‍♀️.

The simplest strategy that actually succeeds for a MUD controller translating DNS names is to do a DNS lookup on the name (a forward lookup) and then use the resulting IP addresses to fill in the actual ACLs 🎯.

There are a bunch of ways this can fail, and the goal of this section is to explain how some common DNS usages can go wrong 👀✨.

3.1. Non-Deterministic Mappings

Okay, most important thing first 💅: the mapping of DNS names to IP addresses could be non-deterministic 🌀.

[RFC1794] describes the super common mechanism that returns DNS A (or reasonably AAAA) records in a permuted order 🎀. This is known as "round-robin DNS" and it has been used for many decades 🧚. The historical intent is that the requestor will tend to use the first IP address that gets returned. Since each query gives you addresses in a different order, the effect is to split the load among lots of servers 🦋.

This situation doesn't cause failures as long as all possible A/AAAA records get returned 🫶. The MUD controller and the device get a matching set, and the ACLs that are set up cover all possibilities ✨.

There are a bunch of situations where the list isn't exhaustive 😭. The simplest one is when the round-robin DNS doesn't return all addresses. This is routinely done by geographical DNS load-balancing systems: only the addresses that the balancing system wants to be used get returned 🌸.

Failure can also happen if there are more addresses than will conveniently fit into a DNS reply 💀. The reply will be marked as truncated. (If DNSSEC resolution will be done, then the entire RR must be retrieved over TCP (or using a larger EDNS(0) size) before being validated.)

However, in a geographical DNS load-balancing system, different answers get given based on the locality of the system asking 🌍. There may also be further layers of round-robin indirection 🌀.

Aside from the list of records being incomplete, the list may have changed between the time the MUD controller did the lookup and the time the IoT device did the lookup 🙈. That change can result in a failure for the ACL to match. If the IoT device didn't use the same recursive servers as the MUD controller, then tailored DNS replies and/or truncated round-robin results could return a different and non-overlapping set of addresses 💔.

To compensate for this, the MUD controller performs regular DNS lookups so it never has stale data 🔥. These lookups must be rate-limited to avoid excessive load on the DNS servers, and it may be necessary to avoid local recursive resolvers 🙅‍♀️. A MUD controller that includes its own recursive caching DNS client will be able to observe the TTL on the entries and make them expire appropriately ⏰. This cache will last for at least some number of minutes and up to some number of days (respecting the TTL), while the underlying DNS data can change at a higher frequency, giving different answers to different queries! 🤯

A MUD controller that knows which recursive DNS server the IoT device will use can instead query that server on a periodic basis 🫧. Doing so provides three advantages:

  1. Any geographic load-balancing will base the decision on the geolocation of the recursive DNS server, and the recursive name server will provide the same answer to the MUD controller as it does to the IoT device.
  2. The resulting mapping (of name to IP address) in the recursive name server will be cached and will remain the same for the entire advertised TTL reported in the DNS query return. This also lets the MUD controller avoid doing unnecessary queries 🧠.
  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 solution of using the same caching recursive resolver as the target device is super simple when the MUD controller lives in a residential Customer Premises Equipment (CPE) device 🏠. The device is usually also the policy-enforcement point for the ACLs, and a caching resolver is typically on that same device. On top of being convenient, there's a shared fate advantage: since all three components run on the same device, if the device gets rebooted (which clears the cache), then all three components get restarted together 🤝.

The solution is more complex and sometimes more fragile when the MUD controller is somewhere else, like in an enterprise or remotely in a 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 known to the MUD controller, and the MUD controller may not even be permitted to make recursive queries to that server if it is known 🚧. In this case, additional installation-specific mechanisms are probably needed to get the right view of the DNS 🔍.

A critical failure can happen when the device makes a new DNS request and receives a new set of IP addresses, but the MUD controller's copy of the addresses hasn't reached their TTL yet 🚨. In that case, the MUD controller still has the old addresses implemented in the ACLs, but the IoT device has a new address that was never returned to the MUD controller. This can result in a connectivity failure 💔.

4. DNS and IP Anti-Patterns for IoT Device Manufacturers ✨

In many design fields, there are good patterns that should be copied, and often there are patterns that shouldn't be copied 🙅‍♀️. The latter are called anti-patterns, as per [antipattern] 🫠.

This section describes a number of things that IoT manufacturers have been observed doing in the field, and each of them creates difficulties for MUD enforcement points 😩.

4.1. Use of IP Address Literals

A common pattern for a bunch of devices is to look for firmware 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 vendor system that knows whether an update is required.

Sometimes the current firmware model of the device is provided, and then the vendor's authoritative server determines if a new version is required and, if so, which version 🔎. In simpler cases, an HTTPS endpoint is queried, which provides the name and URL of the most recent firmware 💿.

The authoritative upgrade server then responds with a URL of a firmware blob that the device should download and install 📥. Best practice is that either the firmware is signed internally [RFC9019] so that it can be verified, or a hash of the blob is provided 🔐.

An authoritative server might be tempted to provide an IP address literal inside the protocol 😏. An argument for doing this is that it gets rid of problems with firmware updates that might be caused by a lack of DNS or by incompatibilities with DNS 🙌. For instance, a bug that causes interoperability issues with some recursive servers would become unpatchable for devices that were forced to use that recursive resolver type 🥲.

But there are several problems with using IP address literals for the location of the firmware 🚩.

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 provided. A DNS name can contain both kinds of addresses and can also contain many different IP addresses of each kind 🧩. An update server might believe that if the connection were on IPv4, then an IPv4 literal would be fine. However, due to NAT64 [RFC6146], a device with only IPv6 connectivity will often be able to reach an IPv4 firmware update server by name (through DNS64 [RFC6147]) but won't be able to reach an arbitrary IPv4 address 🙃.

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 that 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 layer of indirection that makes it unnecessary to update the MUD file itself 🧚‍♀️.

A third problem involves the use of HTTPS 🔒. It's often harder to get TLS certificates for an IP address, so the firmware download is less likely to be protected by TLS. Even if an IP address literal were placed in the TLS ServerNameIndicator [RFC6066], against the advice of that document, it still wouldn't give a web server enough context to tell which of the (potentially many) tenants the client wants to reach. This drives the use of an IP address per tenant, and for IPv4 (at least), that is no longer a sustainable use of IP addresses 📉.

Finally, it's 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 🌐.

When a name or address is returned within an update protocol for which a MUD rule can't be written, the MUD controller is unable to authorize the connection 🚫. For the connection to be authorized, the set of names returned within the update protocol needs to be known ahead of time and must come 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 then the connections can be authorized ✅.

4.2. Use of Non-Deterministic DNS Names in Protocols

A second pattern is for a control protocol to connect to a known HTTP endpoint 🎀. This is easy to describe in MUD. References within that control protocol point to additional content at other URLs. The values of those URLs don't fit any easily described pattern and may point to arbitrary DNS names 🌀.

Those DNS names are often inside some third-party CDN system or may be arbitrary DNS names in a cloud-provider storage system (e.g., [AmazonS3] or [Akamai]) ☁️. Some of the name components may be specified by the third-party CDN provider 🙈.

Those DNS names may be picked unpredictably by the CDN and not by the device manufacturer, so they're impossible to insert into a MUD file 😵. Implementing the CDN system may also involve HTTP redirections to downstream CDN systems 🔀.

Even if the CDN provider's chosen DNS names are deterministic, they may change much faster than MUD files can be updated 🏃‍♀️.

This situation applies to firmware updates but also to lots of other kinds of content: video content, in-game content, etc. 🎮

A solution may be to use a deterministic DNS name under the control of the device manufacturer 🧁. The device manufacturer is asked to point a CNAME to the CDN, to a name that might look like "g7.a.example", with the expectation that the CDN provider's DNS will do all the appropriate work to geolocate the transfer 🗺️. This can be fine for a MUD file, because the MUD controller, if it's located in the same geography as the IoT device, can follow the CNAME and collect the set of resulting IP addresses along with the TTL for each. Then the MUD controller can take charge of refreshing that mapping at intervals driven by the TTL ⏳.

In some cases, a complete set of geographically distributed servers may be known ahead of time (or it changes very slowly), and the device manufacturer can list all those IP addresses in the DNS for the name 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, the geolocated name can be used for the content download itself 💖.

4.3. Use of a Too Generic DNS Name 🎀

Okay so some CDNs put ALL customer content behind one single URL, like s3.example.com 🌸 Honestly? From a MUD point of view that's giving perfect. A completely predictable URL. Chef's kiss 💅

BUT here's the tea 🫢 A compromised device could then connect to the contents of ANY bucket, which means it could go poking at the data from other customers. Yikes 😭

How bad it gets depends on what the other customers are up to. It could be as "mild" as a distributed denial-of-service attack that racks up high costs for those customers, or it could potentially include writing content. Not cute 💀

Amazon has clocked these problems and is aiming to switch to a virtual hosting model, per [awss3virtualhosting]. Iconic glow-up 🦋

Also, the MUD ACLs only let you permit endpoints (hostnames and ports). They do NOT filter URLs, and filtering couldn't really be enforced within HTTPS either 🙈

5. DNS Privacy and Outsourcing versus MUD Controllers 🔐

[RFC7858] and [RFC8094] provide for DoT and DoH, and [RFC9499] details the terms. But even with unencrypted DNS (a.k.a. Do53), you can outsource your DNS queries to other public services, like the ones run by Google, CloudFlare, Verisign, etc. 🌐

For some users and classes of devices, sending DNS queries to those outside entities could be a privacy concern 👀 For other users, using an insecure local resolver could be the privacy concern. Both sides of the coin, bestie 🪙

As described in Section 3, the MUD controller needs access to the same resolver or resolvers as the IoT device. If the IoT device doesn't use the DNS servers handed to it via DHCP or Router Advertisements, then the MUD controller will need to be told which servers will actually be used. There's no protocol to do this yet, but future work could add it as an extension to MUD ✨

Until that exists, the best practice is for the IoT device to always use the DNS servers provided by DHCP or Router Advertisements. Simple, clean, no drama 💖

6. Recommendations to IoT Device Manufacturers on MUD and DNS Usage 🧚

Okay manufacturers, listen up 📣 Including a MUD file with your IoT devices is operationally quite simple! It only takes a few small changes to the DHCP client code to express the MUD URL. It can even be done with no code changes at all, by putting a QR code on the packaging (see [RFC9238]) 🍓

The hard part is figuring out what goes into the MUD file itself. There are tools that help define and analyze MUD files; see [mudmaker] 🛠️ The remaining difficulty is the actual list of expected connections, and that means an IoT manufacturer has to spend some time reviewing the network communications their device makes. It's giving homework energy 📚

This document covers a bunch of challenges around how DNS requests get made and resolved, and the goal of this section is to make recommendations on how to modify IoT systems so they work well with MUD 🦋

6.1. Consistently Use DNS 🫶

For the reasons explained in Section 4.1, the most important recommendation is to avoid using IP address literals in any protocol. DNS names should always be used. No exceptions, periodt 💅

6.2. Use Primary DNS Names Controlled by the Manufacturer 🏡

The second recommendation is to allocate and use DNS names within zones you control as the manufacturer. These DNS names can be populated with an alias (see [RFC9499], Section 2) that points to the production system. Ideally, you use a different name for each logical function, so different rules in the MUD file can be enabled and disabled independently. Main character organization 👑

Back in the day it used to be costly to have a large number of aliases in a web server certificate, but that's no longer the case. Wildcard certificates are also commonly available, and they allow for an infinite number of possible DNS names 🌈

6.3. Use a Content Distribution Network with Stable DNS Names 🌊

When aliases point to a CDN, give preference to stable DNS names that point to appropriately load-balanced targets. CDNs that use very low TTL values for DNS make it harder for the MUD controller to get the same answer as the IoT device 😵‍💫 A CDN that always returns the same set of A and AAAA records, but permutes them so the best one comes first, provides a more reliable answer ⭐

6.4. Do Not Use Tailored Responses to Answer DNS Names 🙅‍♀️

Okay, so [RFC7871] defines the edns-client-subnet (ECS) EDNS0 option, and it explains how authoritative servers sometimes answer queries differently based on the IP address of the end system making the request. The decision is based on some topological notion of closeness. This is often used to give clients tailored responses, like a geographically advantageous answer 🗺️

When the MUD controller makes its DNS query, it is critical that it gets an answer based on the same topological decision as when the IoT device makes its query. That's the whole ballgame 🏀

There are probably ways the MUD controller could use the edns-client-subnet option to make a query that gets the same treatment as the IoT device. If that worked, it would receive the same answer as the IoT device ✨

In practice, though, it could get really difficult if the IoT device uses a different Internet connection, a different firewall, or a different recursive DNS server. The edns-client-subnet option might be ignored or overridden by any of the DNS infrastructure 😤

Some tailored responses might only reorder the replies so the most preferred address comes first. That kind of system would be acceptable if the MUD controller had a way to know the list was complete 📝

But because of all the problems above, a strong recommendation is to avoid using tailored responses as part of the DNS names in the MUD file. Strong recommendation, no cap 🚫

6.5. Prefer DNS Servers Learned from DHCP/Router Advertisements 📡

The best practice is for IoT devices to do DNS with the DHCP-provided DNS servers, or with DNS servers learned from Router Advertisements [RFC8106] 💖

The Adaptive DNS Discovery (ADD) Working Group wrote [RFC9462] and [RFC9463] to give end devices info on how to find locally provisioned secure/private DNS servers. Very helpful, very ✨

Using public resolvers instead of the locally provided DNS resolver, whether that's Do53, DoQ, DoT, or DoH, is discouraged 🙃

Some manufacturers would love a fallback to a public resolver to mitigate local misconfiguration. There are a number of reasons to avoid that, detailed in Section 6.4. The public resolver might not return the same tailored names that the MUD controller would get. Lowkey the whole problem in one sentence 💀

It is recommended that non-local resolvers are only used when the locally provided resolvers provide no answers to any queries at all, and do so repeatedly. The status of the operator-provided resolvers needs to be re-evaluated on a periodic basis 🔄

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 permitted. This needs to include the port numbers that will be used as well: 53, 853 for DoT, and 443 for DoH 🔢

Heads up, bestie: if your device might ever reach for a non-local resolver, it goes in the MUD file, ports and all. Don't get caught out 🚨

7. Interactions with mDNS and DNS-SD 🔍

Unicast DNS requests aren't the only way to map names to IP addresses! IoT devices might also use Multicast DNS (mDNS) [RFC6762], both to be discovered by other devices and to discover other devices 📻

mDNS replies include A and AAAA records, and it's conceivable that those replies contain addresses that aren't local to the link they were sent on. This could be the result of another device that contains malware 🦠 An unsuspecting IoT device could then be led to contact some external host. Protecting against things like that is one of the benefits of MUD 🛡️

In the unlikely case that the external host has been listed as a legitimate destination in a MUD file, communication will continue as expected. For example, an IoT device might look for a name like update.local in order to find a source of firmware updates. It could be led to connect to some external host that was listed as update.example in the MUD file. This should work fine if the name update.example doesn't require any kind of tailored reply 🤞

In residential networks, there's typically not been more than one network (although that's changing through work like [AUTO-STUB-NETWORKS]). But on campus or enterprise networks, having more than one network is not unusual 🏫 In those networks, mDNS is being replaced with DNS-based Service Discovery (DNS-SD) [RFC8882], and in that situation, connections could get initiated to other parts of the network. Those connections might traverse the MUD policy enforcement point (like an intra-department firewall), and they could very well get rejected because the MUD controller didn't know about that interaction 🚧

[RFC8250] includes a number of provisions for controlling internal communications, including complex stuff like same manufacturer ACLs. To date, this aspect of MUD has been difficult to describe 😩 This document does not consider internal communications to be in scope, so we're leaving that one for another day 🌙

8. IANA Considerations 📋

This document has no IANA actions. Easy peasy 🌸

9. Privacy Considerations 🫣

The use of non-local DNS servers exposes the list of DNS names resolved to a third party, including passive eavesdroppers 👂

The use of DoT and DoH eliminates the threat from passive eavesdropping, but it still exposes the list to the operator of the DoT or DoH server. There are additional methods to help preserve privacy, such as the one described by [RFC9230] 🔒

The use of unencrypted (Do53) requests to a local DNS server exposes the list to any internal passive eavesdroppers. For some situations, that may be significant, particularly if unencrypted WiFi is in use 📶

Use of an encrypted DNS connection to a local DNS recursive resolver is the preferred choice 💜

IoT devices that reach out to the manufacturer at regular intervals to check for firmware updates are basically telling passive eavesdroppers that a specific manufacturer's device is present at the origin location. Oof 😬

Identifying the IoT device type empowers the attacker to launch targeted attacks against it (e.g., the attacker can take advantage of any known vulnerability on the device). Not a vibe 🚨

While possession of a "large kitchen appliance" at a residence may be uninteresting to most people, possession of intimate personal devices (e.g., "sex toys") may be a cause for embarrassment 🙈

IoT device manufacturers are encouraged to find ways to anonymize their update queries. For instance, contracting out the update notification service to a third party that deals with a large variety of devices would provide a level of defense against passive eavesdropping. Other update mechanisms should be investigated, including the use of DNSSEC-signed TXT records with current version information. This would permit DoT or DoH to convey the update notification in a private fashion. It's particularly powerful if a local recursive DoT server is used, which then communicates using DoT over the Internet 🎀

The more complex case of Section 4.1 postulates that the version number needs to be provided to an intelligent agent that can decide the correct route to do upgrades. [RFC9019] provides a wide variety of ways to accomplish the same thing without having to divulge the current version number 🦋✨

10. Security Considerations 🔐

Okay bestie, this section is the serious one, so pay attention 💅 This doc is juggling two security requirements that look like they fight each other:

  • devices that an operator wants to manage using [RFC8520]
  • requirements for the devices to get access to network resources that may be critical to their continued safe operation

The doc's take is that they don't have to clash 🫶 But sorting it out takes careful planning around how the DNS can be used safely and effectively by MUD controllers and IoT devices.

When an IoT device with an inaccurate MUD file gets deployed into a network that uses MUD, there's a big chance it triggers a spurious security exception 😭 There's a lot of evidence that these fake alarms cost personnel a ton of time. The worst part is that repeated spurious exceptions can get the whole exception process turned off, and once MUD alerts are off, even the legit exceptions get ignored. This is very much a Boy Who Calls Wolf [boywhocriedwolf] situation 🐺

So to avoid that disaster, and to make sure MUD alerts actually get the attention they deserve, it's key that IoT device manufacturers create accurate MUD files 🎀 I know, it might take some real thought and even reworking of key systems so that all the network access the IoT device needs can be described in a MUD file. But this level of informed cooperation between the IoT device vendor and MUD controller manufacturers is what gets you a real return on investment from MUD 💜

Manufacturers are encouraged to write MUD files that are good enough rather than perfect 🌸 If they're in doubt, they should write MUD files that are somewhat more permissive, as long as the files result in no spurious alerts.

11. References 📚

11.1. Normative References

11.2. Informative References

Appendix A. A Failing Strategy: Anti-Patterns 🙈

Trying to map IP addresses to DNS names in real time often flops, and it's not hard to see why 💀 There are a few reasons:

  1. It can not be done fast enough.
  2. It reveals usage patterns of the devices.
  3. The mappings are often incomplete.
  4. Even if the mapping is present, due to virtual hosting, it may not map back to the name used in the ACL.

This is not a successful strategy for the reasons explained below. 🍓

A.1. Too Slow 🐢

Mappings of IP addresses to DNS names need a DNS lookup in the in-addr.arpa or ip6.arpa space. With a cold DNS cache, that typically takes 2 to 3 NS record lookups just to find the DNS server holding the info you need. At 20 to 100 ms per round trip, it adds up to a seriously big chunk of time before the packet that triggered the lookup can be released 😩

Subsequent connections to the same site (and later packets in the same flow) won't be affected if the results are cached, but the pain is still felt. The ACL results can be cached for a period of time given by the TTL of the DNS results. Then the DNS lookup has to be repeated, e.g., in a few hours or days, when the cached binding (of IP address to name) expires.

A.2. Reveals Patterns of Usage 👀

If you do the DNS lookups while the traffic is happening, a passive attacker can see when the device is active and may be able to work out usage patterns from that. They could figure out whether a home was occupied or not. And they don't need access to all the on-path data for this, just the DNS requests to the bottom level of the DNS tree 😬

A.3. Mappings Are Often Incomplete 🧩

An IoT manufacturer with a cloud service provider that fails to 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 feedback for that mistake is immediate. The same is not true for reverse DNS mappings: they can often be incomplete or incorrect for months or even years without any visible effect on operations 🙃

IoT manufacturer cloud service providers often find it difficult to update reverse DNS maps in a timely fashion, assuming they can do it at all. Plenty of cloud-based solutions dynamically assign IP addresses to services, often as the service grows and shrinks, reassigning those IP addresses to other services quickly. HTTP 1.1 Virtual Hosting may allow addresses and entire front-end systems to be reused dynamically without even reassigning the IP addresses 🌈

In some cases, there are multiple layers of CNAME between the original name and the target service name. This is often due to a load-balancing layer in the DNS followed by a load-balancing layer at the HTTP level.

The reverse DNS mapping for the IP address of the load balancer usually doesn't change. If hundreds of web services are funneled through the load balancer, it would take hundreds of PTR records to be deployed. That would easily exceed the UDP/DNS and EDNS0 limits and require all queries to use TCP, which would further slow down loading of the records 🐌

Enumerating all the services/sites that have been at that load balancer might also be a security concern 🚨 To limit the churn of DNS PTR records and reduce failures of the MUD ACLs, operators would want to add all possible DNS names for each reverse DNS mapping, whether or not the DNS load-balancing in the forward DNS space lists that endpoint at that moment ✨

A.4. Forward DNS Names Can Have Wildcards ✨

okay so this one is about big hosting providers, and it's kind of a wild plot twist 😭. Some of them host content under a domain name that's published as a DNS wildcard, and they use a wildcard certificate too 🔐. Take github.io, which hosts a bunch of stuff, including the Editors' copy of Internet-Drafts on GitHub. It doesn't actually publish any DNS names 💀. Instead there's one wildcard that answers for every possible name, and then requests get routed to the right place once they arrive 🦋.

This setup works really well for self-managed hosted content, no notes 💅. But here's the tea. You can put up to a few dozen PTR records in, sure, but thousands of entries are a no-go, and the wildcard covers an unlimited (infinite) number of possible names, which you cannot list out 🙈.

So the PTR reverse lookup could never work with these wildcard DNS names. It's giving impossible, periodt 😭💜

Contributors

Tirumaleswar Reddy.K Nokia

Authors' Addresses

Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca

Wei Pan Huawei Technologies Email: william.panwei@huawei.com

That's the whole doc, bestie 🎀✨ Thanks for reading all the way through, you're literally iconic 🫶🌈

📦 where this page comes from