Summary

  • RFC 9726 explains why a DNS name in a Manufacturer Usage Description is not yet an executable firewall rule: the controller must resolve that name into a dated address set, and the device may see a different set because of resolver choice, caching, geography or timing.
  • A defensible control links the signed policy, functional name, device and controller resolvers, exact DNS answers and TTLs, projected ACL, installation receipt, packet match, endpoint identity, update verification and device outcome. No earlier record inherits the authority of the later one.

The thermostat asks for an update. Its manufacturer still controls the same update name, the MUD file still permits that name, and the DNS answer received by the thermostat is valid. The destination address changed overnight. The MUD controller queried yesterday, its cached answer has not expired, and the firewall does exactly what it was told: it blocks the new address.

Nothing in that sequence requires an attacker, a malformed packet or a broken DNS server. Two components can obey their specifications and still disagree about the executable meaning of one name. RFC 9726 makes that ordinary failure legible. It is the difference between a durable policy symbol and the local, temporary projection that packet enforcement can actually use.

That difference matters because an access-control list written in terms of a DNS name is attractive precisely where IoT operations are least stable. Manufacturers change hosting providers. CDNs steer by geography and load. IPv4 and IPv6 coexist. Firmware services move. A name absorbs those changes better than a literal address. Yet the firewall does not see the name in the packet. It sees a source, destination and transport fields. Someone must translate the promise into addresses.

The missing operation is projection

RFC 8520 defines Manufacturer Usage Description as a way to state the network behaviour expected of a device. A manufacturer can say that a product needs to contact a service by DNS name. The statement is useful: it scopes intention to a function the manufacturer controls and lets an operator build policy before every future address is known.

But the policy-enforcement point usually receives no DNS name with the packet. HTTPS hides the URL path; IP routing deals in addresses; the firewall cannot infer that an address was reached because the device first resolved the name listed in the MUD file. The MUD controller must resolve the name, collect an address set and compile that set into rules.

The result is not “the DNS policy”. It is a projection with a time, resolver, cache, query context and compiler version. A controller that successfully installs the projection has proved only that a particular rule set reached a particular enforcement point. It has not proved that the device will receive the same DNS answer, that the answer will stay valid, that the address is exclusive to the named service, or that the allowed endpoint will deliver safe code.

The source record and executable record must therefore remain distinct. Store the retrieved MUD bytes and their authority checks. Store the functional name the policy used. Then store the exact DNS response, TTL, resolver identity, CNAME chain, address set, generated rule and installation acknowledgement. Without that chain, an alert cannot tell whether the device departed from policy or the controller merely enforced an older view.

Two correct resolvers can return incompatible truth

The simplest round-robin case is manageable. RFC 1794 describes DNS load balancing in which a complete address set may be returned in a different order. If both controller and device receive the full set, order need not change which addresses the ACL permits.

Modern steering is less tidy. A CDN may return only a geographically appropriate subset. One recursive resolver may already hold an older cached set while another sends a fresh query. The controller may query from a cloud region while the device sits behind a residential gateway. EDNS Client Subnet, described in RFC 7871, can add another topological input, and infrastructure may ignore, replace or interpret it differently.

Time is a second source of divergence. The controller resolves at 09:00 and installs two addresses. At 09:04 the authoritative service changes the answer. The device obtains the new set from a cache that has just refreshed; the controller still correctly honours the TTL on its previous answer. “Both respected DNS” does not mean “both share an address set”.

RFC 9726 favours the same recursive resolver for the device and controller because the shared cache aligns geography, returned subset and TTL. In a home gateway, the resolver, controller and firewall may even share a restart fate. In an enterprise or cloud-managed fleet, that alignment is harder: the controller may not know which resolver the device uses, may be unable to query it, or may receive a different view because it arrives from another network.

The operational question is therefore not whether DNS resolved. It is whether the decision-making components resolved through a deliberately common view—or whether the system recorded and reconciled the difference.

Encrypted DNS changes the witness, not the requirement

Privacy can improve while enforcement coherence declines. If a device ignores the network-provided resolver and sends encrypted queries to a public service, local passive observers lose the query text. The external resolver operator gains that view. The MUD controller may lose the only practical witness needed to build the matching ACL.

RFC 9726 recommends that IoT devices prefer resolvers learned from DHCP or Router Advertisements. RFC 8106 defines IPv6 Router Advertisement options for DNS configuration. RFC 9462 and RFC 9463 provide discovery for network-designated encrypted resolvers. A local encrypted resolver can therefore protect the hop without giving up a common resolution view.

That is not a universal command to distrust public DNS. A hostile or defective local resolver is a real concern, and a fallback can preserve device operation. The RFC bounds the fallback: use a non-local resolver after repeated total local failure, re-evaluate the local service, and ensure the fallback resolver itself is reachable under the MUD policy. The choice has consequences for privacy, control and continuity; it should be an explicit product and operator decision, not an undocumented library default.

Oblivious DoH further separates a client address from query content through relays and targets. That can improve one privacy property. It still does not tell the MUD controller which answer drove the device's next connection. Confidentiality architecture and enforcement evidence answer different questions.

Stable names reduce coordination cost

RFC 9726 asks manufacturers to use names they control, preferably separated by logical function. An update service, telemetry service and time service should not all hide behind one generic hosting name if the operator needs to grant, withdraw or investigate those capabilities independently.

A manufacturer-controlled alias can still point to a CDN. The stable edge of the naming contract lets the manufacturer change infrastructure without rewriting every MUD file. The downstream provider must nevertheless offer answer behaviour that policy can follow. Very short TTLs, arbitrary names returned inside an application protocol, redirects to unpredictable providers and address sets tailored more quickly than the controller can refresh turn a nominally precise rule into operational chance.

A too-generic name creates the opposite error. Permitting an entire shared hosting domain can make policy stable by making it meaningless. The firewall cannot see the HTTPS path and cannot distinguish the manufacturer's object from another tenant at the same destination. A valid match proves only that the packet reached an allowed address and port.

IP literals are not a clean escape. They make hosting moves expensive, complicate IPv4/IPv6 and NAT64, weaken tenant identity, and can push update systems away from ordinary TLS naming. A literal looks deterministic because it deletes the name-to-address step. It simply transfers change risk into firmware, MUD revisions and emergency recovery.

Reverse lookup cannot reconstruct the lost intention

When an unknown destination appears, an operator may be tempted to reverse-resolve the address and compare the result with the policy. RFC 9726's appendix explains why that is not a reliable real-time control. Reverse lookup can be too slow for packet admission, can reveal device usage, can return no useful record, and does not prove which forward name the device used. Virtual hosting lets many names share an address. Wildcard forward namespaces may have no finite reverse enumeration.

The evidence must be captured before the intention disappears. A controller should know which forward query it made, which resolver answered, what CNAME chain it followed, which addresses and TTLs it stored, and which generated rule owns the packet match. PTR data may enrich an investigation; it cannot retroactively authorize the flow.

False precision can destroy the control

The most consequential part of RFC 9726 is organisational. An inaccurate MUD file raises spurious exceptions. Each false alarm costs attention. Repetition teaches staff that the control is noisy, and eventually the alert channel is muted. Once that happens, a legitimate exception can pass unnoticed.

This is not an argument for vague policies. It is an argument for precision about the right layer. A supposedly exact address allowlist assembled from the wrong DNS vantage is false precision. RFC 9726 advises manufacturers to prefer a good-enough, somewhat more permissive file over an idealized file that repeatedly breaks legitimate operation. The aim is an enforceable description with a credible exception process—not maximal denial at any operational cost.

The corrective loop should classify an alert before widening policy. Was the MUD document stale? Did the controller use another resolver? Did the answer change within TTL? Did a CDN introduce an undocumented name? Was the endpoint shared too broadly? Did the device bypass the designated resolver? Did the firewall fail to install the current generation? Or did the device genuinely contact an undeclared destination?

Those causes assign responsibility to different actors. Collapsing them into “device violation” shifts every failure onto the endpoint and prevents the manufacturer, resolver operator, controller vendor or local team from correcting its own layer.

An allowed update path is not a safe update

Firmware makes the boundary concrete. A MUD rule can allow a device to reach the manufacturer's update service. The service can return a URL, the URL can resolve, and the firewall can permit the transfer. None of that proves that the downloaded image is authentic or appropriate.

RFC 9019 describes a firmware-update architecture in which manifests, authorization, installation and recovery have their own roles. Network permission is only reachability evidence. The later receipts are endpoint identity, update metadata, signature or hash verification, authorization for the device, install result, boot state, health and rollback availability.

The same separation protects safety. A blocked update may be a policy-view error, but automatically allowing every new destination can create a larger exposure. A permitted download can still be malicious, corrupted, misbound or operationally incompatible. The decision needs both network-policy evidence and update-system evidence.

The useful record has six clocks

A mature operator can reconstruct at least six times: when the manufacturer issued the MUD file; when the controller retrieved and validated it; when the controller queried DNS; when the response's TTL began and ended; when the ACL was compiled and activated; and when the device resolved and sent the packet. Firmware and application events add more.

That record supports a bounded conclusion. It can show that, at 09:05, the device sent a packet to an address returned by its designated resolver while the firewall enforced a controller projection generated at 09:00 from a different set. It cannot, without further evidence, say the manufacturer was attacked, the CDN failed, the device was compromised, or the update succeeded.

Lu Heng's minimum-specification doctrine clarifies the division. MUD can standardize a portable statement of expected network use. It need not centralize resolver policy, exception handling or operational risk. Reality-layer discipline keeps a signed policy, DNS answer, ACL, packet action and functioning appliance from borrowing one another's authority. Running-code primacy makes the active resolver trace, firewall configuration hash and device outcome stronger evidence than a clean policy file.

RFC 9726 is therefore not merely advice about DNS hygiene. It is a warning about policy projection. The name is durable enough to coordinate change. The address set is temporary enough to fail. Good operations preserve both facts.

Sources