Internet Engineering Task Force (IETF) M. Richardson
Request for Comments: 9726 Sandelman Software Works
BCP: 241 W. Pan
Category: Best Current Practice Huawei Technologies
ISSN: 2070-1721 March 2025
This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 8520, to control device access.
このドキュメントでは、モノのインターネット（IoT）デバイスがIPアドレスとDNS名をどのように使用するかについての考慮事項を詳しく説明しています。ネットワークオペレーターは、RFC 8520で指定されているように、デバイスのアクセスを制御するために、ネットワークオペレーターがメーカーの使用説明（MUD）の展開を開始するため、深刻になります。
Also, this document makes recommendations on when and how to use DNS names in MUD files.
また、このドキュメントは、泥ファイルでDNS名をいつ、どのように使用するかについて推奨しています。
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). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、RFC 7841のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9726で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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, as 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 are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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
[RFC8520] provides a standardized way to describe how a device with a specific purpose makes use of Internet resources. Access Control Lists (ACLs) can be defined in a Manufacturer Usage Description (MUD) file [RFC8520] that permits a device to access Internet resources by their DNS names or IP addresses.
[RFC8520]は、特定の目的を持つデバイスがインターネットリソースをどのように使用するかを説明するための標準化された方法を提供します。アクセス制御リスト（ACLS）は、DNS名またはIPアドレスでインターネットリソースにアクセスできるように、メーカーの使用法の説明（MUD）ファイル[RFC8520]で定義できます。
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 of a name to IP addresses to be changed over time, but it also generalizes automatically to IPv4 and IPv6 addresses as well as permits a variety of load-balancing strategies, including multi-CDN deployments wherein load-balancing can account for geography and load.
ACLでのIPアドレスではなくDNS名の使用には多くの利点があります。間接のレイヤーは、IPアドレスへの名前のマッピングを時間の経過とともに変更することを許可するだけでなく、IPv4およびIPv6アドレスに自動的に一般化するだけでなく、さまざまな負荷バランス戦略を許可します。
However, the use of DNS names has implications on how ACLs are executed at the MUD policy enforcement point (typically, a firewall). Concretely, the firewall has access only to the Layer 3 headers of the packet. This includes the source and destination IP addresses and, if not encrypted by IPsec, the destination UDP or TCP port number present in the transport header. The DNS name is not present!
ただし、DNS名の使用は、泥の政策執行ポイント（通常、ファイアウォール）でACLがどのように実行されるかに影響を与えます。具体的には、ファイアウォールにはパケットのレイヤー3ヘッダーにのみアクセスできます。これには、ソースおよび宛先IPアドレスが含まれ、IPSECによって暗号化されていない場合、輸送ヘッダーに存在する宛先UDPまたはTCPポート番号が含まれます。DNS名は存在しません！
So, in order to implement these name-based ACLs, there must be a mapping between the names in the ACLs and IP addresses.
したがって、これらの名前ベースのACLを実装するには、ACLSの名前とIPアドレスの間にマッピングが必要です。
In order for manufacturers to understand how to configure DNS associated with name-based ACLs, a model of how the DNS resolution will be done by MUD controllers is necessary. Section 3 models some good strategies that could be used.
メーカーが名前ベースのACLSに関連付けられたDNSを構成する方法を理解するためには、泥コントローラーによってDNS解像度がどのように行われるかのモデルが必要です。セクション3は、使用できるいくつかの優れた戦略をモデル化します。
This model is non-normative but is included so that IoT device manufacturers can understand how the DNS will be used to resolve the names they use.
このモデルは非規範的ですが、IoTデバイスメーカーがDNSを使用して使用する名前を解決する方法を理解できるように含まれています。
There are some ways of using DNS that will present problems for MUD controllers, which Section 4 explains.
セクション4には、泥コントローラーに問題を提示するDNSを使用する方法がいくつかあります。
Section 5 details how current trends in DNS resolution such as public DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with the strategies employed.
セクション5では、パブリックDNSサーバー、TLS（DOT）上のDNS（RFC7858]、DNSオーバーHTTPS（DOH）[RFC8484]、またはQUIC（DOQ）[RFC9250]オーバーDNSなどのDNS解像度の現在の傾向が、採用された戦略に問題を引き起こす方法を詳しく説明しています。
The core of this document is Section 6, which makes a series of recommendations ("best current practices") for manufacturers on how to use DNS and IP addresses with IoT devices described by MUD.
このドキュメントのコアはセクション6です。これは、MUDが記述されたIoTデバイスでDNSおよびIPアドレスを使用する方法について、製造業者に一連の推奨事項（「最良の現在のプラクティス」）を作成します。
Section 9 discusses a set of privacy issues that encrypted DNS (for example, DoT and DoH) are frequently used to deal with. How these concerns apply to IoT devices located within a residence or enterprise is a key concern.
セクション9では、暗号化されたDNS（たとえば、DOTやDOH）が頻繁に対処に使用される一連のプライバシーの問題について説明します。これらの懸念が居住地または企業内にあるIoTデバイスにどのように適用されるかが重要な懸念事項です。
Section 10 also covers some of the negative outcomes should MUD/ firewall managers and IoT manufacturers choose not to cooperate.
セクション10では、泥/ファイアウォールマネージャーとIoTメーカーが協力しないことを選択した場合、否定的な結果の一部についてもカバーしています。
This document makes use of terms defined in [RFC8520] and [RFC9499].
このドキュメントでは、[RFC8520]および[RFC9499]で定義された用語を使用しています。
The term "anti-pattern" comes from agile software design literature, as per [antipattern].
「アンチパターン」という用語は、[Antipattern]に従って、アジャイルソフトウェアデザインの文献から得られます。
"CDNs" refers to Content Distribution Networks, such as those described in [RFC6707], Section 1.1.
「CDNS」とは、[RFC6707]、セクション1.1に記載されているようなコンテンツ配信ネットワークを指します。
This section details a strategy that a MUD controller could take. Within the limits of the DNS use detailed in Section 6, this process could work. The methods detailed in Appendix A just will not work.
このセクションでは、泥コントローラーが取ることができる戦略について説明します。セクション6で詳述されているDNS使用の制限内で、このプロセスは機能する可能性があります。付録Aに詳述されている方法は機能しません。
The simplest successful strategy for a MUD controller to translate DNS names is to do a DNS lookup on the name (a forward lookup) and then use the resulting IP addresses to populate the actual ACLs.
泥コントローラーがDNS名を翻訳する最も単純な成功した戦略は、名前（順方向ルックアップ）でDNSルックアップを行い、結果のIPアドレスを使用して実際のACLSを入力することです。
There are a number of possible failures, and the goal of this section is to explain how some common DNS usages may fail.
障害が多数あり、このセクションの目標は、いくつかの一般的なDNS使用がどのように失敗するかを説明することです。
Most importantly, the mapping of the DNS names to IP addresses could be non-deterministic.
最も重要なことは、DNS名のIPアドレスへのマッピングは非決定論的である可能性があることです。
[RFC1794] describes the very common mechanism that returns DNS A (or reasonably AAAA) records in a permuted order. This is known as "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 that is returned. As each query results in addresses being in a different order, the effect is to split the load among many servers.
[RFC1794]は、DNS A（または合理的にAAAA）レコードを順序順に戻す非常に一般的なメカニズムを説明しています。これは「ラウンドロビンDNS」として知られており、何十年も使用されてきました。歴史的な意図は、要求者が返される最初のIPアドレスを使用する傾向があることです。各クエリの結果、アドレスが異なる順序であるため、効果は多くのサーバー間で負荷を分割することです。
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 matching set, and the ACLs that are set up cover all possibilities.
この状況は、可能なすべてのA/ AAAAレコードが返されている限り、障害をもたらすことはありません。泥コントローラーとデバイスはマッチングセットを取得し、セットアップされたACLSはすべての可能性をカバーします。
There are a number of circumstances in which the list is not exhaustive. The simplest is when the round-robin DNS does not return all addresses. This is routinely done by geographical DNS load-balancing systems: Only the addresses that the balancing system wishes to be used are returned.
リストが網羅的ではない状況がいくつかあります。最も簡単なのは、ラウンドロビンDNSがすべてのアドレスを返さない場合です。これは、地理的DNS負荷分散システムによって日常的に行われます。バランスシステムが使用することを望むアドレスのみが返されます。
Failure can also occur if there are more addresses than what 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.)
DNSの返信に便利に適合するものよりも多くのアドレスがある場合、障害も発生する可能性があります。返信は切り捨てられたものとしてマークされます。（DNSSEC解像度が完了する場合、RR全体をTCPで取得する（または検証される前により大きなEDN（0）サイズを使用）する必要があります。）
However, in a geographical DNS load-balancing system, different answers are given based upon the locality of the system asking. There may also be further layers of round-robin indirection.
ただし、地理的なDNSロードバランスシステムでは、システムの局所性に基づいて異なる回答が与えられます。また、ラウンドロビンの間接のさらなる層があるかもしれません。
Aside from the list of records being incomplete, the list may have 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 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 DNS replies and/or truncated round-robin results could return a different and non-overlapping set of addresses.
レコードのリストが不完全であることを除けば、リストは、泥コントローラーが検索を行う時間とIoTデバイスがルックアップを行う時間との間に変更された可能性があり、この変更によりACLが一致しない可能性があります。IoTデバイスがMUDコントローラーと同じ再帰サーバーを使用しなかった場合、テーラードDNS応答および/または切り捨てられたラウンドロビンの結果は、異なる非重複したアドレスのセットを返す可能性があります。
In order to compensate for this, the MUD controller performs regular 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 be necessary to avoid local recursive resolvers. A MUD controller that incorporates its own recursive caching DNS client will be able to observe the TTL on the entries and cause them to 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, providing different answers to different queries!
これを補うために、泥コントローラーは、古いデータを持たないように、定期的なDNSルックアップを実行します。これらのルックアップは、DNSサーバーの過度の負荷を避けるために料金制限する必要があり、ローカルな再帰リゾルバーを避ける必要がある場合があります。独自の再帰的キャッシュDNSクライアントを組み込んだ泥コントローラーは、エントリでTTLを観察し、適切に期限切れにすることができます。このキャッシュは、少なくとも数分間、最大数日間（TTLを尊重）続きますが、基礎となるDNSデータはより高い頻度で変化し、さまざまなクエリに異なる答えを提供します。
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. Doing so provides three advantages:
IoTデバイスが使用する再帰DNSサーバーを認識している泥コントローラーは、代わりにそのサーバーを定期的にクエリすることができます。そうすることで3つの利点があります。
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 to the IoT device.
1. 地理的な負荷バランスは、再帰DNSサーバーの地理配置に基づいて決定を下し、再帰名サーバーはIoTデバイスと同じ回答を泥コントローラーに提供します。
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 allows the MUD controller to avoid doing unnecessary queries.
2. 再帰名サーバーの結果のマッピング（IPアドレスの名前の）はキャッシュされ、DNSクエリリターンで報告された広告TTL全体で同じままになります。これにより、泥コントローラーは不必要なクエリを行わないようにすることができます。
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.
3. ラウンドロビンDNSプロセスでアドレスが省略されている場合、キャッシュには同じアドレスが返されます。
The solution of using the same caching recursive resolver as the target device is very simple when the MUD controller is located 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 located on the same device. In addition to convenience, there is a shared fate advantage: As all three components are running on the same device, if the device is rebooted (which clears the cache), then all three components will get restarted when the device is restarted.
ムードコントローラーが住宅顧客施設機器（CPE）デバイスにある場合、ターゲットデバイスとして同じキャッシュ再帰リゾルバーを使用するという解決策は非常に簡単です。デバイスは通常、ACLSのポリシー執行ポイントでもあり、キャッシュリゾルバーは通常同じデバイスにあります。便利さに加えて、共有された運命の利点があります。3つのコンポーネントすべてが同じデバイスで実行されているため、デバイスが再起動された場合（キャッシュがクリアされます）、3つのコンポーネントすべてがデバイスの再起動時に再起動されます。
The solution is more complex and sometimes more fragile when the MUD controller is located elsewhere 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.
ソフトウェア定義ネットワーク（SDN）を使用してACLSを管理する場合など、泥コントローラーが企業の他の場所にある場合、またはクラウド内のリモートに配置されている場合、ソリューションはより複雑で、時には脆弱です。特定のデバイスのDNSサーバーは泥コントローラーに知られていない可能性があり、泥コントローラーは、そのサーバーが既知の場合、そのサーバーに再帰的なクエリを作成することさえ許可されていない場合があります。この場合、DNSの正しいビューを取得するには、おそらく追加のインストール固有のメカニズムが必要です。
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 of the addresses has not yet reached their TTL. In that case, the MUD controller still has the old addresses implemented in the ACLs, but the IoT device has a new address not previously returned to the MUD controller. This can result in a connectivity failure.
デバイスが新しいDNS要求を行い、新しいIPアドレスのセットを受信すると、重大な障害が発生する可能性がありますが、アドレスの泥コントローラーのコピーはまだTTLに到達していません。その場合、泥コントローラーにはACLSに実装された古いアドレスがまだありますが、IoTデバイスには以前に泥コントローラーに戻されていない新しいアドレスがあります。これにより、接続障害が発生する可能性があります。
In many design fields, there are good patterns that should be emulated, and often there are patterns that should not be emulated. The latter are called anti-patterns, as per [antipattern].
多くの設計分野では、エミュレートする必要がある良いパターンがあり、多くの場合、エミュレートしてはならないパターンがあります。後者は[アンチパッターン]に従って、アンチパターンと呼ばれます。
This section describes a number of things that IoT manufacturers have been observed to do in the field, each of which presents difficulties for MUD enforcement points.
このセクションでは、IoTメーカーがこの分野で行うことが観察されている多くのことについて説明します。それぞれが泥執行ポイントの困難をもたらします。
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 HTTPS, sometimes with a POST, but the method is immaterial) to a vendor system that knows whether an update is required.
多くのデバイスの一般的なパターンは、2段階のプロセスでファームウェアの更新を探すことです。初期クエリは、更新が必要かどうかを知っているベンダーシステムに対して、httpsを超えて、時には投稿がありますが、メソッドは重要ではありません）が行われます。
The current firmware model of the device is sometimes provided, and then the vendor's authoritative server provides a determination if a 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 most recent firmware.
デバイスの現在のファームウェアモデルが提供されることがあり、その後、ベンダーの権威あるサーバーは、新しいバージョンが必要な場合、およびもしそうならどのバージョンを決定します。簡単な場合、HTTPSエンドポイントがQueriedされ、最新のファームウェアの名前とURLが提供されます。
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 firmware is signed internally [RFC9019] so that it can be verified, or a hash of the blob is provided.
権威あるアップグレードサーバーは、デバイスがダウンロードしてインストールするファームウェアブロブのURLで応答します。ベストプラクティスは、いずれかのファームウェアが内部で署名され[RFC9019]、検証できるか、BLOBのハッシュが提供されることです。
An authoritative server might be tempted to provide an IP address literal inside the protocol. An argument for doing this is that it eliminates 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.
権威あるサーバーは、プロトコル内で文字通りのIPアドレスを提供するように誘惑される場合があります。これを行うための議論は、DNSの欠如またはDNSとの非互換性によって引き起こされる可能性のあるファームウェアの更新に関する問題を排除するということです。たとえば、一部の再帰サーバーで相互運用性の問題を引き起こすバグは、その再帰的なリゾルバータイプを使用せざるを得なかったデバイスのためにパッチ不能になります。
But, there are several problems with the use of IP address literals for the location of the firmware.
ただし、ファームウェアの位置にIPアドレスリテラルを使用することにはいくつかの問題があります。
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 acceptable. 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 not be able to reach an arbitrary IPv4 address.
1つ目は、アップデートサービスサーバーが、1つのURLのみが提供できると仮定して、IPv4またはIPv6リテラルを提供するかどうかを決定する必要があることです。DNS名には両方の種類のアドレスを含めることができ、各種類の多くの異なるIPアドレスを含めることもできます。更新サーバーは、接続がIPv4にある場合、IPv4リテラルが受け入れられると信じるかもしれません。ただし、NAT64 [RFC6146]により、IPv6接続のみを備えたデバイスは、多くの場合、IPv4ファームウェアアップデートサーバーに名前（DNS64 [RFC6147]を介して）で届くことができますが、任意のIPv4アドレスに到達することはできません。
A MUD file for this access would need to resolve to the set of IP addresses that might be returned by the update server. This can be done with IP address literals in the MUD file, but this may require continuing updates to the MUD file if the addresses change frequently. A DNS name in the MUD could resolve to the set of all possible IPv4 and IPv6 addresses that would be used, with DNS providing a level of indirection that obviates the need to update the MUD file itself.
このアクセスの泥ファイルは、更新サーバーによって返される可能性のあるIPアドレスのセットに解決する必要があります。これは、MUDファイルのIPアドレスリテラルで実行できますが、アドレスが頻繁に変更された場合、泥ファイルの継続的な更新が必要になる場合があります。泥内のDNS名は、使用されるすべての可能なIPv4およびIPv6アドレスのセットに解決でき、DNSは泥ファイル自体を更新する必要性を削除する間接レベルのレベルを提供します。
A third problem involves the use of HTTPS. It is often more difficult to get TLS certificates for an IP address, and so it is less likely that the firmware download will be protected by TLS. Even if an IP address literal was placed in the TLS ServerNameIndicator [RFC6066], against the advice of that document, it still would not provide enough context for a web server to distinguish which of the (potentially many) tenants the client wishes to reach. This drives the use of an IP address per tenant, and for IPv4 (at least), this is no longer a sustainable use of IP addresses.
3番目の問題には、HTTPSの使用が含まれます。多くの場合、IPアドレスのTLS証明書を取得することはより困難であるため、ファームウェアのダウンロードがTLSによって保護される可能性は低くなります。IPアドレスリテラルがTLS ServernameIndicator [RFC6066]に配置されたとしても、そのドキュメントのアドバイスに対して、クライアントが到達したい（潜在的に多くの）テナントを区別するのに十分なコンテキストを提供しません。これにより、テナントごとのIPアドレスの使用が促進され、IPv4の場合（少なくとも）、これはもはやIPアドレスの持続可能な使用ではありません。
Finally, it is common in some CDNs to use multiple layers of DNS CNAMEs in order to isolate the content owner's naming system from changes in how the distribution network is organized.
最後に、一部のCDNでは、DNS CNAMEの複数の層を使用して、コンテンツ所有者の命名システムを配信ネットワークの編成方法の変更から分離することが一般的です。
When a name or address is returned within an update protocol for which a MUD rule cannot be written, then the MUD controller is unable to authorize the connection. In order for the connection to be authorized, the set of names returned within the update protocol needs to be known ahead of time and must be from a finite set of possibilities. Such a set of names or addresses can be placed into the MUD file as an ACL in advance, and the connections can be authorized.
泥のルールを書くことができない更新プロトコル内で名前またはアドレスが返されると、泥コントローラーは接続を承認できません。接続を承認するためには、更新プロトコル内で返される名前のセットは、事前に知られている必要があり、有限の可能性からのものでなければなりません。このような一連の名前またはアドレスは、事前にACLとして泥ファイルに配置でき、接続を承認できます。
A second pattern is for a control protocol to connect to a known HTTP endpoint. This is easily described in MUD. References within that control protocol are made to additional content at other URLs. The values of those URLs do not fit any easily described pattern and may point to arbitrary DNS names.
2番目のパターンは、コントロールプロトコルが既知のHTTPエンドポイントに接続することです。これは泥で簡単に説明されています。そのコントロールプロトコル内の参照は、他のURLで追加のコンテンツに作成されます。これらのURLの値は、簡単に説明されたパターンに適合せず、任意のDNS名を指している場合があります。
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., [AmazonS3] or [Akamai]). Some of the name components may be specified by the third-party CDN provider.
これらのDNS名は、多くの場合、一部のサードパーティCDNシステム内にあるか、クラウドプロバイダーストレージシステム（[Amazons3]または[Akamai]など）の任意のDNS名である場合があります。名前コンポーネントの一部は、サードパーティのCDNプロバイダーによって指定される場合があります。
Such DNS names may be unpredictably chosen by the CDN and not the device manufacturer and therefore impossible to insert into a MUD file. Implementation of the CDN system may also involve HTTP redirections to downstream CDN systems.
このようなDNS名は、デバイスメーカーではなくCDNによって予測的に選択される可能性があるため、泥ファイルに挿入することは不可能です。CDNシステムの実装には、下流のCDNシステムへのHTTPリダイレクトが含まれる場合があります。
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.
CDNプロバイダーの選択したDNS名が決定論的であっても、MUDファイルを更新できるよりもはるかに高速なレートで変更される場合があります。
This situation applies to firmware updates but also applies to many other kinds of content: video content, in-game content, etc.
この状況は、ファームウェアの更新に適用されますが、ビデオコンテンツ、ゲーム内コンテンツなど、他の多くの種類のコンテンツにも適用されます。
A solution may be to use a deterministic DNS name within 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, as the MUD controller, if 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.
解決策は、デバイスメーカーの制御内で決定論的DNS名を使用することです。デバイスメーカーは、CDNプロバイダーのDNSが転送をジオロケートするためにすべての適切な作業を行うことを期待して、「G7.A.Example」のように見えるかもしれない名前をCDNに指すように求められます。これは、IoTデバイスと同じ地理に位置する場合、泥コントローラーがCNAMEに従い、それぞれのTTLとともに結果のIPアドレスのセットを収集できるため、泥ファイルには問題ありません。次に、泥コントローラーは、TTLによって駆動される間隔でマッピングをリフレッシュすることを担当できます。
In some cases, a complete set of geographically distributed servers may be known ahead of time (or that it changes very slowly), and the device manufacturer can list all those IP addresses in the DNS for the name that it lists in the MUD file. As long as the active set of addresses used by the CDN is a strict subset of that list, then the geolocated name can be used for the content download itself.
場合によっては、地理的に分散したサーバーの完全なセットが事前に既知である（または非常にゆっくりと変更されることがあります）、デバイスメーカーは、泥ファイルにリストされている名前のDNSのすべてのIPアドレスをリストできます。CDNで使用されるアドレスのアクティブなセットがそのリストの厳密なサブセットである限り、Geolocated Nameをコンテンツのダウンロード自体に使用できます。
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 view: a completely predictable URL.
一部のCDNは、すべての顧客コンテンツを単一のURLで利用できるようにします（「s3.example.com」など）。これは、泥の観点からは理想的なようです。完全に予測可能なURLです。
The problem is that a compromised device could then connect to the contents of any bucket, potentially attacking the data from other customers.
問題は、侵害されたデバイスがバケツの内容に接続し、他の顧客からのデータを攻撃する可能性があることです。
Exactly what the risk is depends upon what the other customers are doing: It could be limited to simply causing a distributed denial-of-service attack resulting in high costs to those customers, or such an attack could potentially include writing content.
まさにリスクが何であるかは、他の顧客が何をしているのかに依存します。それは単に分散したサービス拒否攻撃を引き起こすことに限定される可能性があります。
Amazon has recognized the problems associated with this practice and aims to change it to a virtual hosting model, as per [awss3virtualhosting].
Amazonは、このプラクティスに関連する問題を認識しており、[AWSS3VirtualHosting]に従って、仮想ホスティングモデルに変更することを目指しています。
The MUD ACLs provide only for permitting endpoints (hostnames and ports) but do not filter URLs (nor could filtering be enforced within HTTPS).
MUD ACLは、エンドポイント（ホスト名とポート）を許可するためにのみ提供しますが、URLをフィルタリングしません（HTTPS内でフィルタリングを施行することもできません）。
[RFC7858] and [RFC8094] provide for DoT and DoH. [RFC9499] details the terms. But, even with the unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS queries to other public services, such as those operated by Google, CloudFlare, Verisign, etc.
[RFC7858]および[RFC8094]はドットとDOHを提供します。[RFC9499]条件の詳細。しかし、暗号化されていないDNS（別名DO53）があっても、Google、CloudFlare、Verisignなどが運営するものなど、DNSクエリを他の公共サービスに外注することができます。
For some users and classes of devices, revealing the DNS queries to those outside entities may constitute a privacy concern. For other users, the use of an insecure local resolver may constitute a privacy concern.
一部のユーザーとクラスのデバイスの場合、外部エンティティにDNSクエリを明らかにすることは、プライバシーの懸念を構成する可能性があります。他のユーザーにとって、不安定なローカルリゾルバーの使用はプライバシーの懸念を構成する可能性があります。
As described in Section 3, the MUD controller needs to have access to 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 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 this, but future work could provide this as an extension to MUD.
セクション3で説明したように、泥コントローラーはIoTデバイスと同じリゾルバーまたはリゾルバーにアクセスできる必要があります。IoTデバイスがDHCPまたはルーター広告を介して提供されたDNSサーバーを使用しない場合、MUDコントローラーは、実際にどのサーバーを使用するかを伝える必要があります。まだ、これを行うプロトコルはありませんが、将来の作業はこれを泥の拡張として提供する可能性があります。
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 Router Advertisements.
そのようなプロトコルが存在するまで、ベストプラクティスは、IoTデバイスが常にDHCPまたはルーター広告が提供するDNSサーバーを使用することです。
Inclusion of a MUD file with IoT devices is operationally quite 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 the use of a QR code affixed to the packaging (see [RFC9238]).
IoTデバイスに泥ファイルを含めることは、動作的に非常に簡単です。泥URLを表現するには、DHCPクライアントコードのわずかな変更のみが必要です。パッケージに貼り付けられたQRコードを使用してコードの変更なしで実行することもできます（[RFC9238]を参照）。
The difficult part is determining what to put into the MUD file itself. There are currently tools that help with the definition and analysis of MUD files; see [mudmaker]. The remaining difficulty is the actual list of expected connections to put in the MUD file. An IoT manufacturer must spend some time reviewing the network communications by their device.
難しい部分は、泥ファイル自体に何を入れるかを決定することです。現在、泥ファイルの定義と分析に役立つツールがあります。[Mudmaker]を参照してください。残りの難易度は、泥ファイルに入れる予定接続の実際のリストです。IoTメーカーは、デバイスによるネットワーク通信のレビューに時間を費やす必要があります。
This document discusses a number of challenges that occur relating to how DNS requests are made and resolved, and the goal of this section is to make recommendations on how to modify IoT systems to work well with MUD.
このドキュメントでは、DNSリクエストがどのように行われ解決されるかに関連する多くの課題について説明します。このセクションの目標は、泥でうまく機能するIoTシステムを変更する方法について推奨することです。
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.
セクション4.1で説明されている理由により、最も重要な推奨事項は、プロトコルでIPアドレスリテラルの使用を避けることです。DNS名は常に使用する必要があります。
The second recommendation is to allocate and use DNS names within zones controlled by the manufacturer. These DNS names can be populated with an alias (see [RFC9499], Section 2) that points to the production system. Ideally, a different name is used for each logical function, allowing different rules in the MUD file to be enabled and disabled.
2番目の推奨事項は、メーカーが制御するゾーン内でDNS名を割り当てて使用することです。これらのDNS名には、生産システムを指すエイリアス（[RFC9499]、セクション2を参照）を入力できます。理想的には、論理関数ごとに異なる名前が使用され、泥ファイルの異なるルールが有効になり、無効にされるようにします。
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 certificates are also commonly available; they allow for an infinite number of possible DNS names.
以前は、Webサーバー証明書に多数のエイリアスを持っているのは費用がかかっていましたが、これはもはやそうではありません。ワイルドカード証明書も一般的に利用可能です。それらは、無限の数の可能なDNS名を可能にします。
When aliases point to a CDN, give preference to stable DNS names that point to appropriately load-balanced targets. CDNs that employ 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 to provide the best one first, provides a more reliable answer.
エイリアスがCDNを指している場合、適切にロードバランスの取れたターゲットを指す安定したDNS名を優先します。DNSの非常に低いTTL値を使用するCDNは、MUDコントローラーがIoTデバイスと同じ答えを得ることを難しくします。AとAAAAのレコードと同じセットを常に返すCDNは、最初に最高のセットを提供するように許可し、より信頼性の高い答えを提供します。
[RFC7871] defines the edns-client-subnet (ECS) EDNS0 option and explains how authoritative servers sometimes answer queries differently based upon the IP address of the end system making the request. Ultimately, the decision is based upon some topological notion of closeness. This is often used to provide tailored responses to clients, providing them with a geographically advantageous answer.
[RFC7871] EDNS-Client-SubNet（ECS）EDNS0オプションを定義し、信頼できるサーバーがリクエストを行うENDシステムのIPアドレスに基づいてクエリに異なる方法でどのように回答するかを説明します。最終的に、この決定は、近さのトポロジカルな概念に基づいています。これは、クライアントにカスタマイズされた応答を提供するためによく使用され、地理的に有利な答えを提供します。
When the MUD controller makes its DNS query, it is critical that it receives an answer that is based upon the same topological decision as when the IoT device makes its query.
MUDコントローラーがDNSクエリを作成する場合、IoTデバイスがクエリを作成するときと同じトポロジの決定に基づいた回答を受信することが重要です。
There are probably ways in which the MUD controller could use the edns-client-subnet option to make a query that would get the same treatment as when the IoT device makes its query. If this worked, then it would receive the same answer as the IoT device.
おそらく、MUDコントローラーがEDNS-Client-SubNetオプションを使用して、IoTデバイスがクエリを作成したときと同じ処理を受けるクエリを作成する方法があります。これが機能した場合、IoTデバイスと同じ回答を受け取ります。
In practice it could be quite 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.
実際には、IoTデバイスが異なるインターネット接続、異なるファイアウォール、または異なる再帰DNSサーバーを使用する場合、非常に困難です。EDNS-Client-SubNetオプションは、DNSインフラストラクチャのいずれかによって無視またはオーバーライドされる場合があります。
Some tailored responses might only reorder the replies so that the 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.
いくつかのカスタマイズされた応答は、最も優先されるアドレスが最初になるように、返信を再注文するだけです。このようなシステムは、リストが完成したことを知る方法がある場合、受け入れられます。
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.
しかし、上記の問題のため、強力な推奨事項は、泥ファイルのDNS名の一部としてテーラード応答を使用しないようにすることです。
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].
ベストプラクティスは、IoTデバイスがDHCP提供されたDNSサーバーまたはルーター広告[RFC8106]から学習したDNSサーバーでDNSを実行することです。
The Adaptive DNS Discovery (ADD) Working Group has written [RFC9462] and [RFC9463] to provide information to end devices on how to find locally provisioned secure/private DNS servers.
Adaptive DNS Discovery（ADD）ワーキンググループは、[RFC9462]および[RFC9463]を作成して、ローカルでプロビジョニングされたセキュア/プライベートDNSサーバーを見つける方法に関するデバイスを終了するための情報を提供しています。
Use of public resolvers instead of the locally provided DNS resolver, whether Do53, DoQ, DoT, or DoH, is discouraged.
DO53、DOQ、DOT、DOHなど、ローカルで提供されたDNSリゾルバーの代わりにパブリックリゾルバーの使用は落胆します。
Some manufacturers would like to have a fallback to using a public resolver to mitigate against local misconfiguration. There are a number of reasons to avoid this, detailed in Section 6.4. The public resolver might not return the same tailored names that the MUD controller would get.
一部のメーカーは、公開解像度を使用して地元の誤解を緩和するためのフォールバックを希望しています。セクション6.4で詳述している、これを回避する理由はいくつかあります。パブリックリゾルバーは、泥コントローラーと同じテーラード名を返さない場合があります。
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 to be permitted. This needs to include the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be used as well.
最後に、デバイスが非ローカルリゾルバーを使用しようとする場合、それらのリゾルバーのアドレスは、許可される宛先として泥ファイルにリストする必要があります。これには、使用するポート番号（つまり、DOTの場合は53、853、DOHの443）を含める必要があります。
Unicast DNS requests are not 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 also to discover other devices.
ユニキャストDNSリクエストは、名前をIPアドレスにマップする唯一の方法ではありません。IoTデバイスは、マルチキャストDNS（MDNS）[RFC6762]を使用して、他のデバイスによって発見され、他のデバイスを発見することもできます。
mDNS replies include A and AAAA records, and it is conceivable that these replies contain addresses that are not local to the link on which they are made. This could be the result of another device that contains malware. An unsuspecting IoT device could be led to contact some external host as a result. Protecting against such things is one of the benefits of MUD.
MDNSの返信にはAおよびAAAAレコードが含まれており、これらの返信には、作成されたリンクにローカルではないアドレスが含まれていると考えられます。これは、マルウェアを含む別のデバイスの結果である可能性があります。疑いを持たないIoTデバイスは、結果として外部ホストに連絡するように導かれる可能性があります。そのようなことから保護することは、泥の利点の1つです。
In the unlikely case that the external host has been listed as a legitimate destination in a MUD file, communication will continue as expected. As an 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" does not require any kind of tailored reply.
外部ホストが泥ファイルの合法的な目的地としてリストされている可能性が低い場合、通信は期待どおりに継続されます。例として、IoTデバイスは、ファームウェアアップデートのソースを見つけるために「update.local」などの名前を探す場合があります。泥ファイルに「update.example」としてリストされている外部ホストに接続するように導かれる可能性があります。「update.example」という名前には、いかなる種類の調整された返信を必要としない場合、これは正常に動作するはずです。
In residential networks, there has typically not been more than one network (although this is changing through work like [AUTO-STUB-NETWORKS]), but on campus or enterprise networks, having more than one network is not unusual. In such networks, mDNS is being replaced with DNS-based Service Discovery (DNS-SD) [RFC8882], and in such a situation, connections could be initiated to other parts of the network. Such connections might traverse the MUD policy enforcement point (an intra-department firewall) and could very well be rejected because the MUD controller did not know about that interaction.
住宅ネットワークでは、通常、複数のネットワークがありませんでした（ただし、これは[Auto-Stub-Networks]のような作業を通じて変化しています）が、キャンパスまたはエンタープライズネットワークでは、複数のネットワークを持つことは珍しいことではありません。このようなネットワークでは、MDNSはDNSベースのサービス発見（DNS-SD）[RFC8882]に置き換えられており、そのような状況では、ネットワークの他の部分に接続を開始できます。このような接続は、泥政策執行ポイント（部門内ファイアウォール）を横断する可能性があり、泥コントローラーがその相互作用について知らなかったため、非常によく拒否される可能性があります。
[RFC8250] includes a number of provisions for controlling internal communications, including complex communications 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.
[RFC8250]は、同じメーカーACLSのような複雑な通信を含む、内部コミュニケーションを管理するための多くの規定を含んでいます。現在までに、泥のこの側面は説明するのが困難です。このドキュメントでは、内部通信が範囲にあるとは考えていません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
The use of non-local DNS servers exposes the list of DNS names resolved to a third party, including passive eavesdroppers.
非ローカルDNSサーバーの使用は、パッシブ盗聴者を含む第三者に解決されたDNS名のリストを公開します。
The use of DoT and DoH eliminates the threat from passive eavesdropping but still exposes the list to the operator of the DoT or DoH server. There are additional methods to help preserve privacy, such as that described by [RFC9230].
DOTとDOHの使用は、受動的な盗聴からの脅威を排除しますが、それでもリストをDOTまたはDOHサーバーのオペレーターに公開します。[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 used.
ローカルDNSサーバーへの暗号化されていない（DO53）要求の使用は、リストを内部パッシブ盗聴者に公開します。状況によっては、特に暗号化されていないWiFiが使用される場合、それは重要かもしれません。
Use of an encrypted DNS connection to a local DNS recursive resolver is the preferred choice.
ローカルDNSリクルーブリゾルバーへの暗号化されたDNS接続を使用することが好ましい選択です。
IoT devices that reach out to the manufacturer at regular intervals to check for firmware updates are informing passive eavesdroppers of the existence of a specific manufacturer's device being present at the origin location.
ファームウェアの更新をチェックするために定期的にメーカーに手を差し伸べるIoTデバイスは、オリジンの場所に存在する特定のメーカーのデバイスの存在を受動的な盗聴者に通知しています。
Identifying the IoT device type empowers the attacker to launch targeted attacks to the IoT device (e.g., the attacker can take advantage of any known vulnerability on the device).
IoTデバイスタイプを識別すると、攻撃者がIoTデバイスにターゲット攻撃を開始する権限があります（たとえば、攻撃者はデバイス上の既知の脆弱性を利用できます）。
While possession of a "large kitchen appliance" at a residence may be uninteresting to most, 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 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. This is particularly powerful if a local recursive DoT server is used, which then communicates using DoT over the Internet.
IoTデバイスメーカーは、更新クエリを匿名化する方法を見つけることをお勧めします。たとえば、多種多様なデバイスを扱う第三者に更新通知サービスを契約すると、受動的な盗聴に対するレベルの防御が提供されます。現在のバージョン情報を含むDNSSECに署名したTXTレコードの使用など、他の更新メカニズムを調査する必要があります。これにより、DOTまたはDOHが更新通知をプライベートファッションで伝えることができます。これは、ローカルの再帰的なDOTサーバーを使用している場合に特に強力です。これは、インターネット上でDOTを使用して通信します。
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.
セクション4.1のより複雑なケースは、アップグレードを行うための正しいルートを決定できるインテリジェントエージェントにバージョン番号を提供する必要があると仮定しています。[RFC9019]は、現在のバージョン番号を漏らすことなく、同じことを達成するためのさまざまな方法を提供します。
This document deals with conflicting security requirements:
このドキュメントは、矛盾するセキュリティ要件を扱います。
* devices that an operator wants to manage using [RFC8520]
* オペレーターが[RFC8520]を使用して管理したいデバイス
* requirements for the devices to get access to network resources that may be critical to their continued safe operation
* 継続的な安全な動作に不可欠なネットワークリソースにアクセスするためのデバイスの要件
This document takes the view that the two requirements do not need to be in conflict, but resolving the conflict requires careful planning on how the DNS can be safely and effectively be used by MUD controllers and IoT devices.
このドキュメントでは、2つの要件が競合する必要はないと考えていますが、競合を解決するには、泥コントローラーとIoTデバイスがDNSを安全かつ効果的に使用する方法を慎重に計画する必要があります。
When an IoT device with an inaccurate MUD file is deployed into a network that uses MUD, there is a significant possibility that the device will cause a spurious security exception to be raised. There is significant evidence that such spurious exceptions can cause significant overhead to personnel. In particular, repeated spurious exceptions are likely to cause the entire exception process to be turned off. When MUD alerts are turned off, then even legitimate exceptions are ignored. This is very much a Boy Who Calls Wolf [boywhocriedwolf] situation.
不正確な泥ファイルを備えたIoTデバイスが泥を使用するネットワークに展開されると、デバイスがスプリアスセキュリティ例外を引き起こす可能性が大きくあります。そのような偽の例外が人員にかなりのオーバーヘッドを引き起こす可能性があるという重要な証拠があります。特に、繰り返される偽の例外は、例外プロセス全体をオフにする可能性があります。泥アラートがオフになると、正当な例外さえも無視されます。これは、オオカミ[BoyWhocriedWolf]の状況を呼ぶ少年です。
In order to avoid this situation, and for MUD alerts to be given appropriate attention, it is key that IoT device manufacturers create accurate MUD files. This may require some significant thought and even rework of key systems so that all network access required by the IoT device can be described by a MUD file. This level of informed cooperation within the IoT device vendor and with MUD controller manufacturers is key to getting significant return on investment from MUD.
この状況を回避し、泥アラートを適切な注意を払うためには、IoTデバイスメーカーが正確な泥ファイルを作成することが重要です。これには、IoTデバイスに必要なすべてのネットワークアクセスが泥ファイルで説明できるように、重要な思考や重要なシステムの再加工を必要とする場合があります。IoTデバイスベンダー内および泥コントローラーメーカーとのこのレベルの情報に基づいた協力は、泥からの投資収益率を大幅に獲得するための鍵です。
Manufacturers are encouraged to write MUD files that are good enough rather than perfect. If in doubt, they should write MUD files that are somewhat more permissive if the files result in no spurious alerts.
メーカーは、完璧ではなく十分な泥ファイルを書くことをお勧めします。疑わしい場合は、ファイルが偽りのアラートをもたらさない場合、やや寛容な泥ファイルを書き込む必要があります。
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
DOI 10.17487/RFC1794, April 1995,
<https://www.rfc-editor.org/info/rfc1794>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/info/rfc9019>.
[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] Wikipedia, "Akamai Technologies", 26 February 2025,
<https://en.wikipedia.org/w/
index.php?title=Akamai_Technologies&oldid=1277665363>.
[AmazonS3] Wikipedia, "Amazon S3", 14 March 2025,
<https://en.wikipedia.org/w/
index.php?title=Amazon_S3&oldid=1280379498>.
[antipattern]
Agile Alliance, "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]
Tech Monitor, "Down to the Wire: AWS Delays 'Path-Style'
S3 Deprecation at Last Minute", 24 September 2020,
<https://techmonitor.ai/techonology/cloud/aws-s3-path-
deprecation>.
[boywhocriedwolf]
Wikipedia, "The Boy Who Cried Wolf", 6 February 2025,
<https://en.wikipedia.org/w/
index.php?title=The_Boy_Who_Cried_Wolf&oldid=1274257821>.
[mudmaker] "MUD Maker", <https://mudmaker.org>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <https://www.rfc-editor.org/info/rfc6707>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8882] Huitema, C. and D. Kaiser, "DNS-Based Service Discovery
(DNS-SD) Privacy and Security Requirements", RFC 8882,
DOI 10.17487/RFC8882, September 2020,
<https://www.rfc-editor.org/info/rfc8882>.
[RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/info/rfc9230>.
[RFC9238] Richardson, M., Latour, J., and H. Habibi Gharakheili,
"Loading Manufacturer Usage Description (MUD) URLs from QR
Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022,
<https://www.rfc-editor.org/info/rfc9238>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/info/rfc9462>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.
Attempts to map IP addresses to DNS names in real time often fail for a number of reasons:
IPアドレスをリアルタイムでDNS名にマッピングしようとする試みは、多くの理由で失敗することがよくあります。
1. It can not be done fast enough.
1. 十分に速く行うことはできません。
2. It reveals usage patterns of the devices.
2. デバイスの使用パターンを明らかにします。
3. The mappings are often incomplete.
3. 多くの場合、マッピングは不完全です。
4. Even if the mapping is present, due to virtual hosting, it may not map back to the name used in the ACL.
4. 仮想ホスティングのためにマッピングが存在していても、ACLで使用されている名前にマッピングされない場合があります。
This is not a successful strategy for the reasons explained below.
これは、以下で説明する理由のために成功した戦略ではありません。
Mappings of IP addresses to DNS names require a DNS lookup in the in-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 that holds the information required. At 20 to 100 ms per round trip, this easily adds up to a significant amount of time before the packet that caused the lookup can be released.
DNS名へのIPアドレスのマッピングには、in-addr.arpaまたはip6.arpaスペースでDNSルックアップが必要です。コールドDNSキャッシュの場合、これは通常、必要な情報を保持するDNSサーバーを見つけるために2〜3 NSレコードルックアップが必要です。往復あたり20〜100ミリ秒で、これはルックアップを引き起こすパケットをリリースする前に、かなりの時間を簡単に追加します。
While subsequent connections to the same site (and subsequent packets 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 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 binding (of IP address to name) expires.
同じサイトへの後続の接続（および同じフロー内の後続のパケット）は、結果がキャッシュされても影響を受けませんが、効果が感じられます。ACLの結果は、DNSのTTLによって与えられた一定期間キャッシュできますが、DNSルックアップは、たとえば、数時間または数日で、（名前のIPアドレスの）有効期限が切れる数時間または数日で繰り返す必要があります。
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 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 DNS requests to the bottom level of the DNS tree.
トラフィックが発生したときにDNSルックアップを行うことにより、パッシブ攻撃者はデバイスがアクティブであり、使用パターンを導き出すことができるときを確認できます。彼らは、家がいつ占領されたかどうかを判断することができました。これには、DNSツリーの下位レベルへのDNS要求だけで、すべてのオンパスデータへのアクセスは必要ありません。
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 a visible effect on operations.
Forward名の出版物の一部としてAまたはAAAAレコードを含めることができないクラウドサービスプロバイダーを備えたIoTメーカーは、新しいサーバーが単に使用されていないことがわかります。その間違いの運用フィードバックは即時です。同じことは、逆DNSマッピングには当てはまりません。多くの場合、操作に目に見える影響を与えずに、数か月または数年間、不完全または間違っていることがよくあります。
IoT manufacturer cloud service providers often find it difficult to update reverse DNS maps in a timely fashion, assuming that they can do it at all. Many cloud-based solutions dynamically assign IP addresses to services, often as the service grows and shrinks, reassigning those IP addresses to other services quickly. The use of HTTP 1.1 Virtual Hosting may allow addresses and entire front-end systems to be reused dynamically without even reassigning the IP addresses.
IoTメーカーのクラウドサービスプロバイダーは、多くの場合、リバースDNSマップをタイムリーに更新することが難しいと感じています。多くのクラウドベースのソリューションは、多くの場合、サービスが成長して縮小するにつれてIPアドレスをサービスに動的に割り当て、それらのIPアドレスを他のサービスに迅速に再割り当てします。HTTP 1.1仮想ホスティングを使用すると、IPアドレスを再設置することなく、アドレスとフロントエンドシステム全体を動的に再利用できる場合があります。
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.
場合によっては、元の名前とターゲットサービス名の間にCNAMEの複数のレイヤーがあります。これは、多くの場合、DNSの負荷バランス層と、その後にHTTPレベルで負荷バランス層が続くためです。
The reverse DNS mapping for the IP address of the load balancer usually does not change. If hundreds of web services are funneled through the load balancer, it would require hundreds of PTR records to be deployed. This 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.
通常、ロードバランサーのIPアドレスの逆DNSマッピングは変更されません。数百のWebサービスがロードバランサーを介して注入されている場合、数百のPTRレコードを展開する必要があります。これは、UDP/DNSおよびEDNS0の制限を簡単に超え、TCPを使用するためにすべてのクエリが必要になるため、レコードの負荷がさらに遅くなります。
The enumeration of all services/sites that have been at that load balancer might also constitute 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.
そのロードバランサーにあったすべてのサービス/サイトの列挙もセキュリティの懸念を構成する可能性があります。DNS PTRレコードの解約を制限し、MUD ACLSの障害を減らすために、オペレーターは、その瞬間にそのエンドポイントでそのエンドポイントをリストするDNSロードバランスを備えているかどうかにかかわらず、各逆DNSマッピングのすべての可能なDNS名を追加したいと思うでしょう。
In some large hosting providers, content is hosted through a domain name that is published as a DNS wildcard (and uses a wildcard certificate). For instance, github.io, which is used for hosting content, including the Editors' copy of Internet-Drafts stored on GitHub, does not actually publish any DNS names. Instead, a wildcard exists to answer all potential DNS names: Requests are routed appropriately once they are received.
一部の大規模なホスティングプロバイダーでは、コンテンツはDNSワイルドカードとして公開されているドメイン名を介してホストされています（およびワイルドカード証明書を使用）。たとえば、Githubに保存されているインターネットドラフトの編集者のコピーを含むコンテンツのホストに使用されるgithub.ioは、実際にはDNS名を公開していません。代わりに、すべての潜在的なDNS名に答えるためにワイルドカードが存在します。リクエストは受信したら適切にルーティングされます。
This kind of system works well for self-managed hosted content. However, while it is possible to insert up to a few dozen PTR records, many thousands of entries are not possible, nor is it possible to deal with the unlimited (infinite) number of possibilities that a wildcard supports.
この種のシステムは、自己管理ホストコンテンツに適しています。ただし、最大数十個のPTRレコードを挿入することは可能ですが、何千ものエントリが不可能であり、ワイルドカードがサポートする無制限の（無限の）可能性に対処することもできません。
Therefore, it would be impossible for the PTR reverse lookup to ever work with these wildcard DNS names.
したがって、PTR逆ルックアップがこれらのワイルドカードDNS名を使用することは不可能です。
Tirumaleswar Reddy.K
Nokia
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Wei Pan
Huawei Technologies
Email: william.panwei@huawei.com