Internet Engineering Task Force (IETF) M. S. Lenders
Request for Comments: 9953 TU Dresden
Category: Standards Track C. Amsüss
ISSN: 2070-1721
C. Gündoğan
NeuralAgent GmbH
T. C. Schmidt
HAW Hamburg
M. Wählisch
TU Dresden & Barkhausen Institut
March 2026
This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT).
この文書は、Constrained Application Protocol (CoAP) 上で DNS クエリ (OPCODE 0) を交換するためのプロトコルを定義します。これらの CoAP メッセージは、(D)TLS で保護された CoAP または制約された RESTful 環境向けのオブジェクト セキュリティ (OSCORE) によって保護され、モノのインターネット (IoT) の制約されたデバイスに暗号化された DNS メッセージ交換を提供できます。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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 Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。インターネット標準の詳細については、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/rfc9953.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9953 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology and Conventions
3. Selection of a DoC Server
3.1. Discovery by Resource Type
3.2. Discovery Using SVCB Resource Records or DNR
3.2.1. Examples
4. Basic Message Exchange
4.1. The "application/dns-message" Content-Format
4.2. DNS Queries in CoAP Requests
4.2.1. Request Format
4.2.2. Support of CoAP Caching
4.2.3. Example
4.3. DNS Responses in CoAP Responses
4.3.1. Response Codes and Handling DNS and CoAP Errors
4.3.2. Support of CoAP Caching
4.3.3. Examples
5. Interaction with Other CoAP and CoRE Features
5.1. DNS Push Notifications and CoAP Observe
5.2. OSCORE
5.3. Mapping DoC to DoH
6. Considerations for Unprotected Use
7. Security Considerations
8. IANA Considerations
8.1. CoAP Content-Formats Registry
8.2. DNS SVBC Service Parameter Keys (SvcParamKeys) Registry
8.3. Resource Type (rt=) Link Target Attribute Values Registry
9. Operational Considerations
9.1. Coexistence of Different DNS and CoAP Transports
9.2. Redirects
9.3. Proxy Hop Limit
9.4. Error Handling
9.5. DNS Extensions
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Evaluation
Acknowledgments
Authors' Addresses
This document defines DNS over CoAP (DoC), a protocol to send DNS [STD13] queries and get DNS responses over the Constrained Application Protocol (CoAP) [RFC7252] using OPCODE 0 (Query). Each DNS query-response pair is mapped into a CoAP message exchange. Each CoAP message can be secured by any combination of DTLS 1.2 or newer [RFC6347] [RFC9147], TLS 1.3 or newer [RFC8323] [RFC8446], or Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] to ensure message integrity and confidentiality.
この文書は、OPCODE 0 (クエリ) を使用して、Constrained Application Protocol (CoAP) [RFC7252] 経由で DNS [STD13] クエリを送信し、DNS 応答を取得するプロトコルである DNS over CoAP (DoC) を定義します。各 DNS クエリと応答のペアは、CoAP メッセージ交換にマッピングされます。各 CoAP メッセージは、メッセージの整合性と機密性を確保するために、DTLS 1.2 以降 [RFC6347] [RFC9147]、TLS 1.3 以降 [RFC8323] [RFC8446]、または制約付き RESTful 環境のためのオブジェクト セキュリティ (OSCORE) [RFC8613] の任意の組み合わせによって保護できます。
The application use case of DoC is inspired by DNS over HTTPS (DoH) [RFC8484]. However, DoC aims for deployment in the constrained Internet of Things (IoT), which usually conflicts with the requirements introduced by HTTPS. Constrained IoT devices may be restricted in memory, power consumption, link-layer frame sizes, throughput, and latency. They may only have a handful kilobytes of both RAM and ROM. They may sleep for long durations of time, after which they need to refresh the named resources they know about. Name resolution in such scenarios must take into account link-layer frame sizes of only a few hundred bytes, bit rates in the magnitude of kilobits per second, and latencies of several seconds [RFC7228] [RFC7228bis].
DoC のアプリケーションの使用例は、DNS over HTTPS (DoH) [RFC8484] からインスピレーションを得ています。ただし、DoC は、通常、HTTPS によって導入される要件と矛盾する、制約のあるモノのインターネット (IoT) での展開を目指しています。制約のある IoT デバイスは、メモリ、消費電力、リンク層のフレーム サイズ、スループット、遅延が制限される場合があります。RAM と ROM の両方が数キロバイトしかない場合があります。彼らは長時間スリープする可能性があり、その後、知っている名前付きリソースを更新する必要があります。このようなシナリオでの名前解決では、わずか数百バイトのリンク層フレーム サイズ、キロビット/秒規模のビット レート、および数秒の遅延を考慮する必要があります [RFC7228] [RFC7228bis]。
In order not to be burdened by the resource requirements of TCP and HTTPS, constrained IoT devices could use DNS over DTLS [RFC8094]. In contrast to DNS over DTLS, DoC can take advantage of CoAP features to mitigate drawbacks of datagram-based communication. These features include (1) block-wise transfer [RFC7959], which solves the Path MTU problem of DNS over DTLS (see [RFC8094], Section 5), (2) CoAP proxies, which provide an additional level of caching, and (3) reuse of data structures for application traffic and DNS information, which saves memory on constrained devices.
TCP と HTTPS のリソース要件による負担を避けるために、制約のある IoT デバイスは DNS over DTLS [RFC8094] を使用できます。DNS over DTLS とは対照的に、DoC は CoAP 機能を利用して、データグラムベースの通信の欠点を軽減できます。これらの機能には、(1) DTLS 上の DNS のパス MTU 問題を解決するブロック単位の転送 [RFC7959] ([RFC8094]、セクション 5 を参照)、(2) 追加レベルのキャッシュを提供する CoAP プロキシ、(3) 制約のあるデバイスのメモリを節約するアプリケーション トラフィックと DNS 情報のデータ構造の再利用が含まれます。
To avoid the resource requirements of DTLS or TLS on top of UDP (e.g., introduced by DNS over DTLS [RFC8094] or DNS over QUIC [RFC9250]), DoC allows for lightweight message protection based on OSCORE.
UDP 上の DTLS または TLS のリソース要件 (たとえば、DNS over DTLS [RFC8094] または DNS over QUIC [RFC9250] によって導入されたもの) を回避するために、DoC は OSCORE に基づいた軽量のメッセージ保護を可能にします。
. FETCH coaps://[2001:db8::1]/
/
/
CoAP request
+------+ [DNS query] +------+------+ DNS query .--------------.
| DoC |-------------->| DoC | DNS |--- --- --- --->| DNS |
|Client|<--------------|Server|Client|<--- --- --- ---| Infrastructure |
+------+ CoAP response +------+------+ DNS response '--------------'
[DNS response]
\ / \ /
'-----DNS over CoAP-----' '----DNS over UDP/HTTPS/QUIC/...---'
Figure 1: Basic DoC Architecture
図 1: 基本的な DoC アーキテクチャ
The most important components of DoC can be seen in Figure 1: a DoC client tries to resolve DNS information by sending DNS queries carried within CoAP requests to a DoC server. That DoC server can be the authoritative name server for the queried record or a DNS client (i.e., a stub or recursive resolver) that resolves DNS information by using other DNS transports such as DNS over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC [RFC9250] when communicating with the upstream DNS infrastructure. Using that information, the DoC server then replies to the queries of the DoC client with DNS responses carried within CoAP responses. A DoC server MAY also serve as a DNSSEC validator to provide DNSSEC validation to the more constrained DoC clients.
DoC の最も重要なコンポーネントを図 1 に示します。DoC クライアントは、CoAP リクエスト内で伝送される DNS クエリを DoC サーバーに送信することで、DNS 情報の解決を試みます。その DoC サーバーは、クエリされたレコードの権威ネーム サーバー、または上流の DNS インフラストラクチャと通信するときに DNS over UDP [STD13]、DNS over HTTPS [RFC8484]、または DNS over QUIC [RFC9250] などの他の DNS トランスポートを使用して DNS 情報を解決する DNS クライアント (つまり、スタブまたは再帰リゾルバー) にすることができます。その情報を使用して、DoC サーバーは、CoAP 応答内で伝送される DNS 応答で DoC クライアントのクエリに応答します。DoC サーバーは、より制約の多い DoC クライアントに DNSSEC 検証を提供する DNSSEC バリデータとしても機能してもよい(MAY)。
Note that this specification is distinct from DoH because the CoAP-specific FETCH method [RFC8132] is used. A benefit of using this method is having the DNS query in the body such as when using the POST method, but with the same caching advantages of responses to requests that use the GET method. Having the DNS query in the body means that there is no need for extra base64 encoding, which would increase code complexity and message sizes. Also, this allows for the block-wise transfer of queries [RFC7959].
CoAP 固有の FETCH メソッド [RFC8132] が使用されるため、この仕様は DoH とは異なることに注意してください。このメソッドを使用する利点は、POST メソッドを使用する場合などに本文に DNS クエリが含まれることですが、GET メソッドを使用するリクエストに対する応答と同じキャッシュ上の利点もあります。本文に DNS クエリがあるということは、コードの複雑さとメッセージ サイズが増加する追加の Base64 エンコードが必要ないことを意味します。また、これによりクエリのブロック単位の転送が可能になります [RFC7959]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
A server that provides the service specified in this document is called a "DoC server" to differentiate it from a classic "DNS server". A DoC server acts as either a DNS stub resolver or a DNS recursive resolver [BCP219]. As such, the DoC server communicates with an "upstream DNS infrastructure" or a single "upstream DNS server". A "DoC resource" is a CoAP resource [RFC7252] at the DoC server that DoC clients can target in order to send a DNS query in a CoAP request.
このドキュメントで指定されているサービスを提供するサーバーは、従来の「DNS サーバー」と区別するために「DoC サーバー」と呼ばれます。DoC サーバーは、DNS スタブリゾルバまたは DNS 再帰リゾルバとして機能します [BCP219]。そのため、DoC サーバーは「アップストリーム DNS インフラストラクチャ」または単一の「アップストリーム DNS サーバー」と通信します。「DoC リソース」は、DoC クライアントが CoAP リクエストで DNS クエリを送信するためにターゲットにできる DoC サーバーの CoAP リソース [RFC7252] です。
A client using the service specified in this document to retrieve the DNS information is called a "DoC client".
この文書で指定されたサービスを使用して DNS 情報を取得するクライアントを「DoC クライアント」と呼びます。
The term "constrained nodes" is used as defined in [RFC7228]. [RFC6690] describes that Constrained RESTful Environments (CoRE) realize the Representational State Transfer (REST) architecture [REST] in a suitable form for such constrained nodes.
「制約されたノード」という用語は、[RFC7228] で定義されているように使用されます。[RFC6690] では、制約付き RESTful 環境 (CoRE) が、そのような制約付きノードに適した形式で表現状態転送 (REST) アーキテクチャ [REST] を実現すると説明しています。
A DoC server can provide Observe capabilities as defined in [RFC7641], Section 1.2. As part of that, it administers a "list of observers". DoC clients using these capabilities are "observers" as defined in [RFC7641], Section 1.2. A "notification" is a CoAP response message with an Observe option; see [RFC7641], Section 4.2.
DoC サーバーは、[RFC7641] セクション 1.2 で定義されている監視機能を提供できます。その一環として「オブザーバーリスト」を管理している。これらの機能を使用する DoC クライアントは、[RFC7641] セクション 1.2 で定義されている「オブザーバー」です。「通知」は、Observe オプションを備えた CoAP 応答メッセージです。[RFC7641]のセクション 4.2 を参照してください。
The terms "payload" and "body" are used as defined in [RFC7959], Section 2. Note that, when block-wise transfer is not used, the terms "payload" and "body" are to be understood as equal.
「ペイロード」と「ボディ」という用語は、[RFC7959] のセクション 2 で定義されているように使用されます。ブロック単位の転送が使用されない場合、「ペイロード」と「ボディ」という用語は等しいものとして理解されることに注意してください。
In the examples in this document, the binary payload and resource records are shown in a hexadecimal representation as well as a human-readable format for better readability. However, in the actual message sent and received, they are encoded in the binary message format defined in [STD13].
このドキュメントの例では、バイナリ ペイロードとリソース レコードは、読みやすくするために人間が判読できる形式に加えて 16 進数表現でも示されています。ただし、実際に送受信されるメッセージは[STD13]で定義されているバイナリメッセージフォーマットでエンコードされます。
While there is no path specified for the DoC resource, it is RECOMMENDED to use the root path "/" to keep the CoAP requests small.
DoC リソースに指定されたパスはありませんが、CoAP リクエストを小さく保つためにルート パス「/」を使用することが推奨されます。
The DoC client needs to know the DoC server and the DoC resource at the DoC server. Possible options to assure this could be (1) manual configuration of a Uniform Resource Identifier (URI) [RFC3986] or Constrained Resource Identifier (CRI) [CRI] or (2) automatic configuration, e.g., using a CoRE resource directory [RFC9176], DHCP or Router Advertisement options [RFC9463], or discovery of designated resolvers [RFC9462]. Automatic configuration MUST only be done from a trusted source.
DoC クライアントは、DoC サーバーと DoC サーバーの DoC リソースを認識している必要があります。これを保証するための可能なオプションは、(1) ユニフォーム リソース識別子 (URI) [RFC3986] または制約リソース識別子 (CRI) [CRI] の手動構成、または (2) 自動構成、たとえば、CoRE リソース ディレクトリ [RFC9176]、DHCP またはルーター アドバタイズメント オプション [RFC9463]、または指定されたリゾルバーの検出 [RFC9462] を使用することです。自動構成は、信頼できるソースからのみ実行する必要があります。
For discovery of the DoC resource through a link mechanism that allows describing a resource type (e.g., the Resource Type attribute in [RFC6690]), this document introduces the resource type "core.dns". It can be used to identify a generic DNS resolver that is available to the client.
リソースタイプ([RFC6690]のリソースタイプ属性など)の記述を可能にするリンクメカニズムを介したDoCリソースの発見のために、この文書ではリソースタイプ「core.dns」を導入します。これは、クライアントが使用できる汎用 DNS リゾルバーを識別するために使用できます。
A DoC server can also be discovered using Service Binding (SVCB) Resource Records (RRs) [RFC9460] [RFC9461] resolved via another DNS service (e.g., provided by an unencrypted local resolver) or Discovery of Network-designated Resolvers (DNR) Service Parameters [RFC9463] via DHCP or Router Advertisements. [RFC8323] defines the Application-Layer Protocol Negotiation (ALPN) ID for CoAP over TLS servers and [RFC9952] defines the ALPN ID for CoAP over DTLS servers. DoC servers that use only OSCORE [RFC8613] and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] (COSE stands for "Concise Binary Object Notation (CBOR) Object Signing and Encryption" [RFC9052]) to support security cannot be discovered using these SVCB RR or DNR mechanisms. Specifying an alternate discovery mechanism is out of the scope of this document.
DoC サーバーは、別の DNS サービス (暗号化されていないローカル リゾルバーによって提供されるなど) を介して解決されるサービス バインディング (SVCB) リソース レコード (RR) [RFC9460] [RFC9461]、または DHCP またはルーター アドバタイズメントを介したネットワーク指定リゾルバー (DNR) サービス パラメーターの検出 [RFC9463] を使用して検出することもできます。[RFC8323] は CoAP over TLS サーバーの Application-Layer Protocol Negotiation (ALPN) ID を定義し、[RFC9952] は CoAP over DTLS サーバーの ALPN ID を定義します。セキュリティをサポートするために OSCORE [RFC8613] と Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] (COSE は「Concise Binary Object Notation (CBOR) Object Signing and Encryption」[RFC9052] の略) のみを使用してセキュリティをサポートする DoC サーバーは、これらの SVCB RR または DNR メカニズムを使用して検出できません。代替の検出メカニズムの指定については、このドキュメントの範囲外です。
This document is not an SVCB mapping document for the CoAP schemes as defined in Section 2.4.3 of [RFC9460]. A full SVCB mapping is specified in [TRANSPORT-IND]. It generalizes mechanisms for all CoAP services. This document introduces only the discovery of DoC services.
この文書は、[RFC9460] のセクション 2.4.3 で定義されている CoAP スキームの SVCB マッピング文書ではありません。完全な SVCB マッピングは [TRANSPORT-IND] で指定されます。すべての CoAP サービスのメカニズムを一般化します。このドキュメントでは、DoC サービスの検出のみを紹介します。
This document specifies "docpath" as a single-valued Service Parameter Key (SvcParamKey) that is mandatory for DoC SVCB records. If the "docpath" SvcParamKey is absent, the service should not be considered a valid DoC service.
この文書では、DoC SVCB レコードに必須の単一値のサービス パラメーター キー (SvcParamKey) として「docpath」を指定します。「docpath」SvcParamKey が存在しない場合、サービスは有効な DoC サービスとみなされません。
The docpath is divided up into segments of the absolute path to the DoC resource (docpath-segment), each a sequence of 1-255 octets. In ABNF [RFC5234]:
docpath は、DoC リソースへの絶対パスのセグメント (docpath-segment) に分割され、各セグメントは 1 ～ 255 オクテットのシーケンスになります。ABNF [RFC5234] では:
docpath-segment = 1*255OCTET
Note that this restricts the length of each docpath-segment to at most 255 octets. Paths with longer segments cannot be advertised with the "docpath" SvcParam and are thus NOT RECOMMENDED for the path to the DoC resource.
これにより、各 docpath セグメントの長さが最大 255 オクテットに制限されることに注意してください。より長いセグメントを持つパスは、「docpath」SvcParam でアドバタイズできないため、DoC リソースへのパスとして推奨されません。
The presentation format value of "docpath" SHALL be a comma-separated list (Appendix A.1 of [RFC9460]) of 0 or more docpath-segments. The root path "/" is represented by 0 docpath-segments, i.e., an empty list. The same considerations apply for the "," and "\" characters in docpath-segments for zone-file implementations and the alpn-ids in an "alpn" SvcParam (Section 7.1.1 of [RFC9460]).
"docpath" のプレゼンテーション形式の値は、0 個以上の docpath-segments のカンマ区切りリスト ([RFC9460] の付録 A.1) でなければなりません (SHALL)。ルート パス「/」は、0 docpath-segments、つまり空のリストで表されます。同じ考慮事項が、ゾーンファイル実装の docpath セグメント内の「,」および「\」文字と、「alpn」SvcParam 内の alpn-id にも適用されます ([RFC9460] のセクション 7.1.1)。
The wire-format value for "docpath" consists of 0 or more sequences of octets prefixed by their respective length as a single octet. We call this single octet the length octet. The length octet and the corresponding sequence form a length-value pair. These length-value pairs are concatenated to form the SvcParamValue. These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malformed. Each such length-value pair represents one segment of the absolute path to the DoC resource. The root path "/" is represented by 0 length-value pairs, i.e., SvcParamValue length 0.
「docpath」のワイヤ形式の値は、単一のオクテットとしてそれぞれの長さが接頭辞として付けられた 0 個以上のオクテットのシーケンスで構成されます。この単一のオクテットを長さオクテットと呼びます。長さオクテットと対応するシーケンスは、長さと値のペアを形成します。これらの長さと値のペアが連結されて、SvcParamValue が形成されます。これらのペアは SvcParamValue を正確に満たさなければなりません。それ以外の場合、SvcParamValue の形式が不正です。このような長さと値の各ペアは、DoC リソースへの絶対パスの 1 つのセグメントを表します。ルート パス「/」は、0 個の長さと値のペア、つまり SvcParamValue 長さ 0 で表されます。
Note that this format uses the same encoding as the "alpn" SvcParam, and it can reuse the decoders and encoders for that SvcParam with the adaption that a length of zero is allowed. As long as each docpath-segment has a length between 0 and 23 octets, inclusive, it is easily transferred into the path representation in CRIs [CRI] by masking each length octet with the CBOR text string major type 3 (0x60 as an octet; see [RFC8949]). Furthermore, it is easily transferable into a sequence of CoAP Uri-Path options by mapping each length octet into the Option Delta and Option Length of the corresponding CoAP Uri-Path option, provided the docpath-segments are all of a length between 0 and 12 octets (see [RFC7252], Section 3.1). Likewise, it can be transferred into a URI path-abempty form by replacing each length octet with the "/" character. None of the abovementioned prevent longer docpath-segments than the considered ones; they just make the translation harder as space is required for the longer delimiters, which in turn require octets to be moved.
この形式は「alpn」SvcParam と同じエンコーディングを使用し、長さ 0 が許可されるという適応により、その SvcParam のデコーダーとエンコーダーを再利用できることに注意してください。各 docpath セグメントの長さが 0 から 23 オクテットの間である限り、各長オクテットを CBOR テキスト文字列メジャー タイプ 3 (オクテットとして 0x60、[RFC8949] を参照) でマスクすることにより、CRI [CRI] のパス表現に簡単に転送されます。さらに、docpath セグメントがすべて 0 から 12 オクテットの間の長さである場合、各長オクテットを対応する CoAP Uri-Path オプションのオプション デルタとオプション長にマッピングすることにより、一連の CoAP Uri-Path オプションに簡単に転送できます ([RFC7252]、セクション 3.1 を参照)。同様に、各長さのオクテットを「/」文字に置き換えることによって、URI パスが空の形式に変換できます。上記のいずれも、検討されているものよりも長い docpath セグメントを妨げるものではありません。長い区切り文字にはスペースが必要になり、オクテットの移動が必要になるため、翻訳が難しくなるだけです。
To use the service binding from an SVCB RR or DNR Encrypted DNS option, the DoC client MUST send a DoC request constructed from the SvcParams including "docpath". The construction algorithm for DoC requests is as follows, with the provided records in order of their priority. For the purposes of this algorithm, the DoC client is assumed to be SVCB-optional (see Section 3 of [RFC9460]).
SVCB RR または DNR 暗号化 DNS オプションからのサービス バインディングを使用するには、DoC クライアントは、「docpath」を含む SvcParams から構築された DoC リクエストを送信しなければなりません。DoC リクエストの構築アルゴリズムは次のとおりです。提供されたレコードは優先順位の順に並べられています。このアルゴリズムの目的上、DoC クライアントは SVCB オプションであると想定されます ([RFC9460] のセクション 3 を参照)。
* If the "alpn" SvcParam value for the service is "coap", a CoAP request for CoAP over TLS MUST be constructed [RFC8323]. If it is "co", a CoAP request for CoAP over DTLS MUST be constructed [RFC9952]. Any other SvcParamKeys specifying a transport are out of the scope of this document.
* サービスの「alpn」SvcParam 値が「coap」の場合、TLS 上の CoAP に対する CoAP リクエストを構築しなければなりません [RFC8323]。「co」の場合、DTLS 上の CoAP に対する CoAP リクエストを構築しなければなりません [RFC9952]。トランスポートを指定するその他の SvcParamKey は、このドキュメントの範囲外です。
* The destination address for the request SHOULD be taken from additional information about the target. This may include (1) A or AAAA RRs associated with the target name and delivered with the SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6 addresses provided if DNR [RFC9463] is used. As a fallback, an address MAY be queried for the target name of the SVCB record from another DNS service.
* リクエストの宛先アドレスは、ターゲットに関する追加情報から取得する必要があります (SHOULD)。これには、(1) ターゲット名に関連付けられ、SVCB RR とともに配信される A または AAAA RR ([RFC9462] を参照)、(2) SVCB RR からの "ipv4hint" または "ipv6hint" SvcParams ([RFC9461] を参照)、または (3) DNR [RFC9463] が使用されている場合に提供される IPv4 または IPv6 アドレスが含まれる場合があります。フォールバックとして、別の DNS サービスから SVCB レコードのターゲット名についてアドレスを問い合わせることができます (MAY)。
* The destination port for the request MUST be taken from the "port" SvcParam value, if present. Otherwise, take the default port of the CoAP transport, e.g., with regards to this specification, the default is TCP port 5684 for "coap" or UDP port 5684 for "co". This document introduces no limitations on the ports that can be used. If a malicious SVCB record allows its originator to influence message payloads, Section 12 of [RFC9460] recommends placing such restrictions in the SVCB mapping document. The records used in this document only influence the Uri-Path option. That option is only sent in the plaintext of an encrypted (D)TLS channel and thus does not warrant any limitations.
* リクエストの宛先ポートは、「port」SvcParam 値 (存在する場合) から取得する必要があります。それ以外の場合は、CoAP トランスポートのデフォルト ポートを使用します。たとえば、この仕様に関して、デフォルトは「coap」の場合は TCP ポート 5684、「co」の場合は UDP ポート 5684 です。このドキュメントでは、使用できるポートに制限はありません。悪意のある SVCB レコードにより、その発信者がメッセージ ペイロードに影響を与えることを許可する場合、[RFC9460] のセクション 12 は、SVCB マッピング文書にそのような制限を設けることを推奨しています。このドキュメントで使用されるレコードは、Uri-Path オプションにのみ影響します。このオプションは、暗号化された (D)TLS チャネルの平文でのみ送信されるため、いかなる制限も保証されません。
* The request URI's hostname component MUST be the Authentication Domain Name (ADN) when obtained through DNR and MUST be the target name of the SVCB record when obtained through a _dns query (if AliasMode is used to the target name of the AliasMode record). This can be achieved efficiently by setting that name in TLS Server Name Indication (SNI) [RFC8446] or by setting the Uri-Host option on each request.
* リクエスト URI のホスト名コンポーネントは、DNR を通じて取得する場合は認証ドメイン名 (ADN) でなければならず、_dns クエリを通じて取得する場合は SVCB レコードのターゲット名でなければなりません (AliasMode レコードのターゲット名に AliasMode が使用されている場合)。これは、TLS Server Name Indication (SNI) [RFC8446] でその名前を設定するか、各リクエストで Uri-Host オプションを設定することによって効率的に実現できます。
* For each element in the CBOR sequence of the "docpath" SvcParam value, a Uri-Path option MUST be added to the request.
* 「docpath」SvcParam 値の CBOR シーケンス内の各要素に対して、Uri-Path オプションをリクエストに追加する必要があります。
* If the request constructed this way receives a response, the same SVCB record MUST be used for construction of future DoC queries. If not, or if the endpoint becomes unreachable, the algorithm repeats with the SVCB RR or DNR Encrypted DNS option with the next highest Service Priority as a fallback (see Sections 2.4.1 and 3 of [RFC9460]).
* この方法で構築されたリクエストがレスポンスを受信した場合、同じ SVCB レコードを将来の DoC クエリの構築に使用しなければなりません (MUST)。そうでない場合、またはエンドポイントが到達不能になった場合、アルゴリズムはフォールバックとして次に高いサービス優先度を持つ SVCB RR または DNR 暗号化 DNS オプションを使用して繰り返されます ([RFC9460] のセクション 2.4.1 および 3 を参照)。
A more generalized construction algorithm for any CoAP request can be found in [TRANSPORT-IND].
CoAP リクエストのより一般化された構築アルゴリズムは、[TRANSPORT-IND] にあります。
A typical SVCB resource record response for a DoC server at the root path "/" of the server looks like the following (the "docpath" SvcParam is the last 4 bytes 00 0a 00 00 in the binary):
サーバーのルート パス「/」にある DoC サーバーに対する一般的な SVCB リソース レコードの応答は次のようになります (「docpath」の SvcParam はバイナリの最後の 4 バイト 00 0a 00 00 です)。
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 06 28 00 1e 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f 00 0a 00 00
Resource record (human-readable):
_dns.example.org. 1576 IN SVCB 1 dns.example.org (
alpn=co docpath )
The root path is RECOMMENDED but not required. Here are two examples where the "docpath" represents paths of varying depth. First, "/dns" is provided in the following example (the last 8 bytes 00 0a 00 04 03 64 6e 73):
ルート パスは推奨されますが、必須ではありません。「docpath」がさまざまな深さのパスを表す 2 つの例を次に示します。まず、次の例では「/dns」が指定されています (最後の 8 バイト 00 0a 00 04 03 64 6e 73)。
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 00 55 00 22 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f 00 0a 00 04 03 64 6e 73
Resource record (human-readable):
_dns.example.org. 85 IN SVCB 1 dns.example.org (
alpn=co docpath=dns )
Second, see an example for the path "/n/s" (the last 8 bytes 00 0a 00 04 01 6e 01 73):
次に、パス「/n/s」(最後の 8 バイト 00 0a 00 04 01 6e 01 73) の例を参照してください。
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 06 6b 00 22 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f 00 0a 00 04 01 6e 01 73
Resource record (human-readable):
_dns.example.org. 1643 IN SVCB 1 dns.example.org (
alpn=co docpath=n,s )
If the server also provides DNS over HTTPS, "dohpath" and "docpath" MAY coexist:
サーバーが HTTPS 経由で DNS も提供する場合、「dohpath」と「docpath」が共存してもよいです。
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 01 ad 00 2c 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 06 02 68 33 02 63 6f 00 07 00 07 2f 7b 3f
64 6e 73 7d 00 0a 00 00
Resource record (human-readable):
_dns.example.org. 429 IN SVCB 1 dns.example.org (
alpn=h3,co dohpath=/{?dns} docpath )
This document defines a CoAP Content-Format ID for the Internet media type "application/dns-message" to be the mnemonic 553, based on the port assignment of DNS. This media type is defined as in Section 6 of [RFC8484], i.e., a single DNS message encoded in the DNS on-the-wire format [STD13]. Both DoC client and DoC server MUST be able to parse contents in the "application/dns-message" Content-Format. This document only specifies OPCODE 0 (Query) for DNS over CoAP messages. Future documents can provide considerations for additional OPCODEs or extend its specification (e.g., by describing whether other CoAP codes need to be used for which OPCODE). Unless another error takes precedence, a DoC server uses RCODE = 4, NotImp [STD13], in its response to a query with an OPCODE that it does not implement (see also Section 4.3.3).
この文書では、DNS のポート割り当てに基づいて、インターネット メディア タイプ「application/dns-message」の CoAP コンテンツ フォーマット ID をニーモニック 553 として定義します。このメディア タイプは、[RFC8484] のセクション 6 で定義されています。つまり、DNS オンザワイヤ フォーマット [STD13] でエンコードされた単一の DNS メッセージです。DoC クライアントと DoC サーバーは両方とも、「application/dns-message」コンテンツ形式のコンテンツを解析できなければなりません。この文書では、DNS over CoAP メッセージに対して OPCODE 0 (クエリ) のみを指定します。将来の文書では、追加の OPCODE に関する考慮事項を提供したり、その仕様を拡張したりする可能性があります (たとえば、どの OPCODE に他の CoAP コードを使用する必要があるかを説明することによって)。別のエラーが優先されない限り、DoC サーバーは、実装していない OPCODE を含むクエリへの応答で RCODE = 4、NotImp [STD13] を使用します (セクション 4.3.3 も参照)。
A DoC client encodes a single DNS query in one or more CoAP request messages that use the CoAP FETCH [RFC8132] request method. Requests SHOULD include an Accept option to indicate the type of content that can be parsed in the response.
DoC クライアントは、CoAP FETCH [RFC8132] リクエスト メソッドを使用する 1 つ以上の CoAP リクエスト メッセージで単一の DNS クエリをエンコードします。リクエストには、応答で解析できるコンテンツのタイプを示す Accept オプションを含める必要があります (SHOULD)。
Since CoAP provides reliability at the message layer (e.g., through Confirmable messages), the retransmission mechanism of the DNS protocol as defined in [STD13] is not needed.
CoAP はメッセージ層で (確認可能なメッセージなどを介して) 信頼性を提供するため、[STD13] で定義されている DNS プロトコルの再送信メカニズムは必要ありません。
When sending a CoAP request, a DoC client MUST include the DNS query in the body of the CoAP request. As specified in Section 2.3.1 of [RFC8132], the type of content of the body MUST be indicated using the Content-Format option. This document specifies the usage of Content-Format "application/dns-message" (for details, see Section 4.1).
CoAP リクエストを送信するとき、DoC クライアントは CoAP リクエストの本文に DNS クエリを含める必要があります。[RFC8132] のセクション 2.3.1 に規定されているように、本文のコンテンツのタイプは Content-Format オプションを使用して指定しなければなりません (MUST)。この文書では、Content-Format「application/dns-message」の使用法を指定します (詳細については、セクション 4.1 を参照)。
The DoC client SHOULD set the ID field of the DNS header to 0 to enable a CoAP cache (e.g., a CoAP proxy en route) to respond to the same DNS queries with a cache entry. This ensures that the CoAP Cache-Key (see [RFC8132], Section 2) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issued. Apart from losing these caching benefits, there is no harm in not setting it to 0, e.g., when the query was received from somewhere else. In any instance, a DoC server MUST copy the ID from the query in its response to that query.
DoC クライアントは、CoAP キャッシュ (例: 途中の CoAP プロキシ) がキャッシュ エントリで同じ DNS クエリに応答できるように、DNS ヘッダーの ID フィールドを 0 に設定すべきです (SHOULD)。これにより、CoAP リクエストで運ばれる同じ DNS データに対する複数の DNS クエリが発行された場合でも、CoAP キャッシュ キー ([RFC8132] のセクション 2 を参照) が変更されないことが保証されます。これらのキャッシュの利点が失われることを除けば、クエリが他の場所から受信された場合など、0 に設定しなくても問題はありません。どのような場合でも、DoC サーバーはクエリへの応答でクエリから ID をコピーしなければなりません (MUST)。
The following example illustrates the usage of a CoAP message to resolve "example.org. IN AAAA" based on the URI "coaps://[2001:db8::1]/". The CoAP body is encoded in the "application/dns-message" Content-Format.
次の例は、URI "coaps://[2001:db8::1]/" に基づいて "example.org. IN AAAA" を解決するための CoAP メッセージの使用法を示しています。CoAP 本文は、「application/dns-message」コンテンツ形式でエンコードされます。
FETCH coaps://[2001:db8::1]/
Content-Format: 553 (application/dns-message)
Accept: 553 (application/dns-message)
Payload (binary):
00 00 01 00 00 01 00 00 00 00 00 00 07 65 78 61
6d 70 6c 65 03 6f 72 67 00 00 1c 00 01
Payload (human-readable):
;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.org. IN AAAA
Each DNS query-response pair is mapped to a CoAP request-response operation. DNS responses are provided in the body of the CoAP response, i.e., it is also possible to transfer them using block-wise transfer [RFC7959]. A DoC server MUST be able to produce responses in the "application/dns-message" Content-Format (for details, see Section 4.1) when requested. The use of the Accept option in the request is OPTIONAL. However, all DoC clients MUST be able to parse an "application/dns-message" response (see also Section 4.1). Any response Content-Format other than "application/dns-message" MUST be indicated with the Content-Format option by the DoC server.
各 DNS クエリと応答のペアは、CoAP 要求と応答の動作にマッピングされます。DNS 応答は CoAP 応答の本文で提供されます。つまり、ブロック単位の転送 [RFC7959] を使用して DNS 応答を転送することも可能です。DoC サーバーは、要求されたときに、「application/dns-message」コンテンツ形式 (詳細についてはセクション 4.1 を参照) で応答を生成できなければなりません (MUST)。リクエストでの Accept オプションの使用はオプションです。ただし、すべての DoC クライアントは、「application/dns-message」応答を解析できなければなりません (セクション 4.1 も参照)。「application/dns-message」以外の応答 Content-Format は、DoC サーバーによって Content-Format オプションで示されなければなりません (MUST)。
A DNS response indicates either success or failure in the RCODE of the DNS header (see [STD13]). It is RECOMMENDED that CoAP responses that carry a parsable DNS response use a 2.05 (Content) response code.
DNS 応答は、DNS ヘッダーの RCODE で成功または失敗を示します ([STD13] を参照)。解析可能な DNS 応答を伝送する CoAP 応答では、2.05 (コンテンツ) 応答コードを使用することが推奨されます。
CoAP responses using non-successful response codes MUST NOT contain a DNS response and MUST only be used for errors in the CoAP layer or when a request does not fulfill the requirements of the DoC protocol.
失敗した応答コードを使用する CoAP 応答には DNS 応答を含めてはならず、CoAP 層のエラーまたは要求が DoC プロトコルの要件を満たさない場合にのみ使用しなければなりません (MUST)。
Communication errors with an upstream DNS server (e.g., timeouts) MUST be indicated by including a DNS response with the appropriate RCODE in a successful CoAP response, i.e., using a 2.xx response code. When an error occurs at the CoAP layer, e.g., if an unexpected request method or an unsupported Content-Format in the request are used, the DoC server SHOULD respond with an appropriate CoAP error.
上流の DNS サーバーとの通信エラー (タイムアウトなど) は、成功した CoAP 応答に適切な RCODE を含む DNS 応答を含めることによって、つまり 2.xx 応答コードを使用して示されなければなりません (MUST)。CoAP 層でエラーが発生した場合、たとえば、リクエスト内で予期しないリクエストメソッドやサポートされていないコンテンツフォーマットが使用されている場合、DoC サーバーは適切な CoAP エラーで応答する必要があります (SHOULD)。
A DoC client might try to repeat a non-successful exchange unless otherwise prohibited. The DoC client might also decide to repeat a non-successful exchange with a different URI, for instance, when the response indicates an unsupported Content-Format.
DoC クライアントは、別途禁止されていない限り、失敗した交換を繰り返そうとする可能性があります。DoC クライアントは、たとえば、サポートされていない Content-Format が応答に示されている場合など、別の URI との失敗した交換を繰り返すことを決定する場合もあります。
For reliability and energy-saving measures, content decoupling (such as en-route caching on proxies) takes a far greater role than it does in HTTP. Likewise, CoAP makes it possible to use cache validation to refresh stale cache entries to reduce the number of large response messages. For cache validation, CoAP implementations regularly use hashing over the message content for ETag generation (see [RFC7252], Section 5.10.6). As such, the approach to guarantee the same cache key for DNS responses as proposed in DoH ([RFC8484], Section 5.1) is not sufficient and needs to be updated so that the TTLs in the response are more often the same regardless of query time.
信頼性と省エネ対策の観点から、コンテンツの分離 (プロキシでの途中キャッシュなど) は、HTTP よりもはるかに大きな役割を果たします。同様に、CoAP では、キャッシュ検証を使用して古いキャッシュ エントリを更新し、大きな応答メッセージの数を減らすことができます。キャッシュ検証のために、CoAP 実装は定期的に ETag 生成のためにメッセージ内容のハッシュを使用します ([RFC7252]、セクション 5.10.6 を参照)。したがって、DoH ([RFC8484]、セクション 5.1) で提案されているように、DNS 応答に対して同じキャッシュキーを保証するアプローチは十分ではなく、クエリ時間に関係なく応答内の TTL がより多くの場合同じになるように更新する必要があります。
The DoC server MUST ensure that the sum of the Max-Age value of a CoAP response and any TTL in the DNS response is less than or equal to the corresponding TTL received from an upstream DNS server. This also includes the default Max-Age value of 60 seconds (see Section 5.10.5 of [RFC7252]) when no Max-Age option is provided. The DoC client MUST then add the Max-Age value of the carrying CoAP response to all TTLs in a DNS response on reception and use these calculated TTLs for the associated records.
DoC サーバーは、CoAP 応答の Max-Age 値と DNS 応答内の TTL の合計が、上流の DNS サーバーから受信した対応する TTL 以下であることを保証しなければなりません (MUST)。これには、Max-Age オプションが指定されていない場合のデフォルトの Max-Age 値 60 秒も含まれます ([RFC7252] のセクション 5.10.5 を参照)。その後、DoC クライアントは、受信時の DNS 応答内のすべての TTL に、伝送する CoAP 応答の Max-Age 値を追加し、これらの計算された TTL を関連するレコードに使用しなければなりません (MUST)。
To meet the requirement for DoC, the RECOMMENDED algorithm for a DoC server is as follows: Set the Max-Age option of a response to the minimum TTL of a DNS response and subtract this value from all TTLs of that DNS response. This prevents expired records from unintentionally being served from an intermediate CoAP cache. Additionally, if the ETag for cache validation is based on the content of the response, it allows that ETag not to change. This then remains the case even if the TTL values are updated by an upstream DNS cache. If only one record set per DNS response is assumed, a simplification of this algorithm is to just set all TTLs in the response to 0 and set the TTLs at the DoC client to the value of the Max-Age option.
DoC の要件を満たすために、DoC サーバーの推奨アルゴリズムは次のとおりです。 応答の Max-Age オプションを DNS 応答の最小 TTL に設定し、その DNS 応答のすべての TTL からこの値を減算します。これにより、期限切れのレコードが意図せずに中間 CoAP キャッシュから提供されるのを防ぎます。さらに、キャッシュ検証の ETag が応答の内容に基づいている場合、その ETag を変更しないことが許可されます。これは、TTL 値が上流の DNS キャッシュによって更新された場合でも変わりません。DNS 応答ごとに 1 つのレコード セットのみが想定されている場合、このアルゴリズムを単純化すると、応答内のすべての TTL を 0 に設定し、DoC クライアントの TTL を Max-Age オプションの値に設定するだけになります。
If shorter caching periods are plausible, e.g., if the RCODE of the message indicates an error that should only be cached for a minimal duration, the value for the Max-Age option SHOULD be set accordingly. This value might be 0, but if the DoC server knows that the error will persist, greater values are also conceivable, depending on the projected duration of the error. The same applies for DNS responses that, for any reason, do not carry any records with a TTL.
より短いキャッシュ期間が妥当な場合、たとえば、メッセージの RCODE が最小限の期間のみキャッシュすべきエラーを示している場合、Max-Age オプションの値はそれに応じて設定すべきである (SHOULD)。この値は 0 である可能性がありますが、エラーが継続することを DoC サーバーが認識している場合は、予想されるエラーの継続時間に応じて、より大きな値も考えられます。何らかの理由で TTL を持つレコードを送信しない DNS 応答にも同じことが当てはまります。
The following example illustrates the response to the query "example.org. IN AAAA record", with recursion turned on. Successful responses carry one answer record including the address 2001:db8:1:0:1:2:3:4 and TTL 79689.
次の例は、再帰をオンにした場合のクエリ「example.org. IN AAAA Record」に対する応答を示しています。成功した応答には、アドレス 2001:db8:1:0:1:2:3:4 および TTL 79689 を含む 1 つのアンサー レコードが含まれます。
A successful response:
成功した応答:
2.05 Content
Content-Format: 553 (application/dns-message)
Max-Age: 58719
Payload (human-readable):
;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.org. IN AAAA
;; ANSWER SECTION:
;example.org. 79689 IN AAAA 2001:db8:1:0:1:2:3:4
When a DNS error - NxDomain (RCODE = 3) for "does.not.exist" in this case - is noted in the DNS response, the CoAP response still indicates success.
DNS エラー (この場合は「does.not.exist」の NxDomain (RCODE = 3)) が DNS 応答に記録されている場合でも、CoAP 応答は成功を示します。
2.05 Content
Content-Format: 553 (application/dns-message)
Payload (human-readable):
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;does.not.exist. IN AAAA
As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if it does not support an OPCODE - in this case, it errors on a DNS Update (OPCODE = 5) for "example.org".
セクション 4.1 で説明したように、DoC サーバーは OPCODE をサポートしていない場合に NotImp (RCODE = 4) を使用します。この場合、「example.org」の DNS 更新 (OPCODE = 5) でエラーが発生します。
2.05 Content
Content-Format: 553 (application/dns-message)
Payload (human-readable):
;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;example.org. IN AAAA
When an error occurs at the CoAP layer, the DoC server responds with an appropriate CoAP error, for instance, 4.15 (Unsupported Content-Format) if the Content-Format option in the request was not set to "application/dns-message" and the Content-Format is not otherwise supported by the server.
CoAP 層でエラーが発生すると、DoC サーバーは適切な CoAP エラーで応答します。たとえば、リクエストの Content-Format オプションが「application/dns-message」に設定されておらず、Content-Format がサーバーでサポートされていない場合は、4.15 (サポートされていない Content-Format) です。
4.15 Unsupported Content-Format
[no payload]
DNS Push Notifications [RFC8765] provide the capability to asynchronously notify clients about resource record changes. However, it results in additional overhead, which conflicts with constrained resources. This is the reason why it is RECOMMENDED to use CoAP Observe [RFC7641] instead of DNS Push in the DoC domain. This is particularly useful if a short-lived record is requested frequently. The DoC server SHOULD provide Observe capabilities on its DoC resource and do as follows.
DNS プッシュ通知 [RFC8765] は、リソース レコードの変更についてクライアントに非同期に通知する機能を提供します。ただし、追加のオーバーヘッドが発生し、制約されたリソースと競合します。これが、DoC ドメインで DNS プッシュの代わりに CoAP Observe [RFC7641] を使用することが推奨される理由です。これは、有効期間の短いレコードが頻繁に要求される場合に特に便利です。DoC サーバーは、その DoC リソース上で監視機能を提供し、次のように実行する必要があります (SHOULD)。
If a DoC client wants to observe a resource record, a DoC server can respond with a notification and add the client to its list of observers for that resource in accordance with [RFC7641]. The DoC server MAY subscribe to DNS Push Notifications for that record. This involves sending a DNS Subscribe message (see Section 6.2 of [RFC8765]), instead of a classic DNS query to fetch the information on behalf of the DoC client.
DoC クライアントがリソース レコードを監視したい場合、DoC サーバーは通知で応答し、[RFC7641] に従ってそのリソースのオブザーバーのリストにクライアントを追加できます。DoC サーバーは、そのレコードの DNS プッシュ通知をサブスクライブしてもよい (MAY)。これには、DoC クライアントに代わって情報を取得するための従来の DNS クエリの代わりに、DNS サブスクライブ メッセージ ([RFC8765] のセクション 6.2 を参照) を送信することが含まれます。
After the list of observers for a particular DNS query has become empty (by explicit or implicit cancellation of the observation as per Section 3.6 of [RFC7641]), and no other reason to subscribe to that request is present, the DoC server SHOULD cancel the corresponding subscription. This can involve sending a DNS Unsubscribe message or closing the session (see Section 6.4 of [RFC8765]). As there is no CoAP observer anymore from the perspective of the DoC server, a failure to unsubscribe or close the session cannot be communicated back to any DoC observer. As such, error handling (if any) needs to be resolved between the DoC server and the upstream DNS infrastructure.
特定の DNS クエリのオブザーバのリストが空になり ([RFC7641] のセクション 3.6 に従ってオブザベーションを明示的または暗黙的にキャンセルすることによって)、そのリクエストをサブスクライブする他の理由が存在しない場合、DoC サーバーは対応するサブスクリプションをキャンセルする必要があります(SHOULD)。これには、DNS Unsubscribe メッセージの送信やセッションの終了が含まれる場合があります ([RFC8765] のセクション 6.4 を参照)。DoC サーバーの観点からは CoAP オブザーバーがもう存在しないため、サブスクライブ解除またはセッションの終了に失敗しても、どの DoC オブザーバーにも通信できません。そのため、エラー処理 (存在する場合) は、DoC サーバーと上流の DNS インフラストラクチャの間で解決する必要があります。
Whenever the DoC server receives a DNS Push message from the DNS infrastructure for an observed resource record, the DoC server sends an appropriate Observe notification response to the DoC client.
DoC サーバーは、監視されたリソース レコードの DNS インフラストラクチャから DNS プッシュ メッセージを受信するたびに、適切な監視通知応答を DoC クライアントに送信します。
A server that responds with notifications (i.e., sends the Observe option) needs to have the means of obtaining current resource records. This may happen through DNS Push or also by upstream polling or implicit circumstances (e.g., if the DoC server is the authoritative name server for the record and wants to notify about changes).
通知で応答する (つまり、Observe オプションを送信する) サーバーには、現在のリソース レコードを取得する手段が必要です。これは、DNS プッシュを通じて、またはアップストリーム ポーリングや暗黙的な状況 (たとえば、DoC サーバーがレコードの権威ネーム サーバーであり、変更について通知したい場合) によって発生する場合があります。
It is RECOMMENDED to carry DNS messages protected using OSCORE [RFC8613] between the DoC client and the DoC server. The establishment and maintenance of the OSCORE security context is out of the scope of this document.
OSCORE [RFC8613] を使用して保護された DNS メッセージを DoC クライアントと DoC サーバー間で伝送することが推奨されます。OSCORE セキュリティ コンテキストの確立と維持については、このドキュメントの範囲外です。
[CACHEABLE-OSCORE] describes a method to allow cache retrieval of OSCORE responses and discusses the corresponding implications on message sizes and security properties.
[CACHEABLE-OSCORE] は、OSCORE 応答のキャッシュ取得を可能にする方法を説明し、メッセージ サイズとセキュリティ プロパティに対する対応する影響について議論します。
This document provides no specification on how to map between DoC and DoH, e.g., at a CoAP-to-HTTP proxy. Such a direct mapping is NOT RECOMMENDED: Rewriting the FETCH method (Section 4.2) and TTL (Section 4.3.2) as specified in this document would be non-trivial. It is RECOMMENDED to use a DNS forwarder to map between DoC and DoH, as would be the case for mapping between any other pair of DNS transports.
この文書では、CoAP から HTTP プロキシなどで DoC と DoH の間をマッピングする方法についての仕様は提供されていません。このような直接マッピングは推奨されません。この文書で指定されているように FETCH メソッド (セクション 4.2) と TTL (セクション 4.3.2) を書き直すことは簡単ではありません。DNS トランスポートの他のペア間のマッピングの場合と同様に、DoC と DoH の間のマッピングには DNS フォワーダーを使用することが推奨されます。
The use of DoC without confidentiality and integrity protection is NOT RECOMMENDED. Without secure communication, many possible attacks need to be evaluated in the context of the application's threat model. This includes known threats for unprotected DNS [RFC3833] [RFC9076] and CoAP (Section 11 of [RFC7252]). While DoC does not use the random ID of the DNS header (see Section 4.2.2), equivalent protection against off-path poisoning attacks is achieved by using random large token values for unprotected CoAP requests. If a DoC message is unprotected, it MUST use a random token with a length of at least 2 bytes to mitigate this kind of poisoning attack.
機密性と完全性を保護せずに DoC を使用することは推奨されません。安全な通信がなければ、考えられる多くの攻撃をアプリケーションの脅威モデルのコンテキストで評価する必要があります。これには、保護されていない DNS [RFC3833] [RFC9076] および CoAP ([RFC7252] のセクション 11) に対する既知の脅威が含まれます。DoC は DNS ヘッダーのランダム ID を使用しませんが (セクション 4.2.2 を参照)、オフパス ポイズニング攻撃に対する同等の保護は、保護されていない CoAP リクエストに対してランダムな大きなトークン値を使用することによって実現されます。DoC メッセージが保護されていない場合、この種のポイズニング攻撃を軽減するために、少なくとも 2 バイトの長さのランダム トークンを使用しなければなりません (MUST)。
General CoAP security considerations ([RFC7252], Section 11) apply to DoC. DoC also inherits the security considerations of the protocols used for secure communication, e.g., OSCORE ([RFC8613], Section 12) as well as DTLS 1.2 or newer ([RFC6347], Section 5 and [RFC9147], Section 11). Additionally, DoC uses request patterns that require the maintenance of long-lived security contexts. Section 2.9 of [CoAP-CORR-CLAR] provides insights on what can be done when those are resumed from a new endpoint.
CoAP セキュリティに関する一般的な考慮事項 ([RFC7252]、セクション 11) が DoC に適用されます。DoC はまた、安全な通信に使用されるプロトコル、たとえば OSCORE ([RFC8613]、セクション 12) や DTLS 1.2 以降 ([RFC6347]、セクション 5 および [RFC9147]、セクション 11) のセキュリティに関する考慮事項も継承します。さらに、DoC は、長期間存続するセキュリティ コンテキストの維持を必要とするリクエスト パターンを使用します。[CoAP-CORR-CLAR] のセクション 2.9 では、新しいエンドポイントから再開するときに何ができるかについての洞察が提供されます。
Though DTLS v1.2 [RFC6347] was obsoleted by DTLS v1.3 [RFC9147], there are many CoAP implementations that still use v1.2 at the time of writing. As such, this document also accounts for the usage of DTLS v1.2 even though newer versions are RECOMMENDED when using DTLS to secure CoAP.
DTLS v1.2 [RFC6347] は DTLS v1.3 [RFC9147] によって廃止されましたが、執筆時点ではまだ v1.2 を使用している CoAP 実装が多数あります。そのため、CoAP を保護するために DTLS を使用する場合は新しいバージョンが推奨されていますが、このドキュメントでは DTLS v1.2 の使用についても説明しています。
When using unprotected CoAP (see Section 6), setting the ID of a DNS message to 0 as specified in Section 4.2.2 opens the DNS cache of a DoC client to cache poisoning attacks via response spoofing. This document requires an unpredictable CoAP token in each DoC query from the client when CoAP is not secured to mitigate such an attack over DoC (see Section 6).
保護されていない CoAP (セクション 6 を参照) を使用する場合、セクション 4.2.2 で指定されているように DNS メッセージの ID を 0 に設定すると、DoC クライアントの DNS キャッシュが開き、応答スプーフィングによるポイズニング攻撃をキャッシュします。この文書では、CoAP がセキュリティで保護されていない場合に、DoC を介したこのような攻撃を軽減するために、クライアントからの各 DoC クエリで予測不可能な CoAP トークンを要求します (セクション 6 を参照)。
For secure communication via (D)TLS or OSCORE, an unpredictable ID to protect against spoofing is not necessary. Both (D)TLS and OSCORE offer mechanisms to harden against injecting spoofed responses in their protocol design. Consequently, the ID of the DNS message can be set to 0 without any concern in order to leverage the advantages of CoAP caching.
(D)TLS または OSCORE を介した安全な通信の場合、スプーフィングから保護するための予測不可能な ID は必要ありません。(D)TLS と OSCORE はどちらも、プロトコル設計でスプーフィングされた応答の注入を強化するメカニズムを提供します。したがって、CoAP キャッシュの利点を活用するために、DNS メッセージの ID を問題なく 0 に設定できます。
A DoC client must be aware that the DoC server may communicate unprotected with the upstream DNS infrastructure, e.g., using DNS over UDP. DoC can only guarantee confidentiality and integrity of communication between parties for which the security context is exchanged. The DoC server may use another security context to communicate upstream with both confidentiality and integrity (e.g., DNS over QUIC [RFC9250]); however, while recommended, this is opaque to the DoC client on the protocol level. Record integrity can also be ensured upstream using DNSSEC [BCP237].
DoC クライアントは、DoC サーバーが、例えば DNS over UDP を使用して、保護されずに上流の DNS インフラストラクチャと通信する可能性があることを認識する必要があります。DoC は、セキュリティ コンテキストが交換される当事者間の通信の機密性と整合性のみを保証できます。DoC サーバーは、別のセキュリティ コンテキストを使用して、機密性と完全性の両方を備えたアップストリーム通信を行うことができます (例: DNS over QUIC [RFC9250])。ただし、これは推奨されていますが、プロトコル レベルでは DoC クライアントに対して不透明です。レコードの整合性は、DNSSEC [BCP237] を使用してアップストリームでも保証できます。
A DoC client may not be able to perform DNSSEC validation, e.g., due to code size constraints or the size of the responses. It may trust its DoC server to perform DNSSEC validation; how that trust is expressed is out of the scope of this document. For instance, a DoC client may be configured to use a particular credential by which it recognizes an eligible DoC server. That information can also imply trust in the DNSSEC validation by that DoC server.
コード サイズの制約や応答のサイズなどにより、DoC クライアントは DNSSEC 検証を実行できない場合があります。DoC サーバーを信頼して DNSSEC 検証を実行する場合があります。その信頼がどのように表現されるかについては、この文書の範囲外です。たとえば、DoC クライアントは、適格な DoC サーバーを認識する特定の資格情報を使用するように構成できます。この情報は、その DoC サーバーによる DNSSEC 検証に対する信頼を暗示することもできます。
IANA has assigned a CoAP Content-Format ID for the "application/dns-message" media type in the "CoAP Content-Formats" registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group [RFC7252]; this corresponds to the "application/dns-message" media type from the "Media Types" registry (see [RFC8484]).
IANA は、「Constrained RESTful Environments (CoRE) Parameters」レジストリ グループ [RFC7252] の「CoAP Content-Formats」レジストリで「application/dns-message」メディア タイプに CoAP Content-Format ID を割り当てました。これは、「Media Types」レジストリの「application/dns-message」メディア タイプに対応します ([RFC8484] を参照)。
+=========================+=====+===================+
| Content Type | ID | Reference |
+=========================+=====+===================+
| application/dns-message | 553 | [RFC8484] and RFC |
| | | 9953, Section 4.1 |
+-------------------------+-----+-------------------+
Table 1: CoAP Content-Format ID
表 1: CoAP コンテンツ形式 ID
IANA has added the following entry to the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry in the "DNS Service Bindings (SVCB)" registry group. The definition of this parameter can be found in Section 3.
IANA は、「DNS Service Bindings (SVCB)」レジストリ グループの「DNS SVCB Service Parameter Keys (SvcParamKeys)」レジストリに次のエントリを追加しました。このパラメータの定義についてはセクション 3 を参照してください。
+========+=========+===============+===================+===========+
| Number | Name | Meaning | Change Controller | Reference |
+========+=========+===============+===================+===========+
| 10 | docpath | DNS over CoAP | IETF | RFC 9953, |
| | | resource path | | Section 3 |
+--------+---------+---------------+-------------------+-----------+
Table 2: Value for SvcParamKeys
表 2: SvcParamKeys の値
IANA has added "core.dns" to the "Resource Type (rt=) Link Target Attribute Values" registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANA は、「制約付き RESTful 環境 (CoRE) パラメーター」レジストリ グループの「リソース タイプ (rt=) リンク ターゲット属性値」レジストリに「core.dns」を追加しました。
+==========+========================+=====================+
| Value | Description | Reference |
+==========+========================+=====================+
| core.dns | DNS over CoAP resource | RFC 9953, Section 3 |
+----------+------------------------+---------------------+
Table 3: Resource Type (rt=) Link Target Attribute
表 3: リソース タイプ (rt=) リンク ターゲット属性
Many DNS transports may coexist on the DoC server, such as DNS over UDP [STD13], DNS over (D)TLS [RFC7858] [RFC8094], DNS over HTTPS [RFC8484], or DNS over QUIC [RFC9250]. In principle, transports employing channel or object security should be preferred. In constrained scenarios, DNS over CoAP is preferable to DNS over DTLS. The final decision regarding the preference, however, heavily depends on the use case and is therefore left to the implementers or users and is not defined in this document.
DNS over UDP [STD13]、DNS over (D)TLS [RFC7858] [RFC8094]、DNS over HTTPS [RFC8484]、DNS over QUIC [RFC9250] など、多くの DNS トランスポートが DoC サーバー上で共存できます。原則として、チャネルまたはオブジェクトのセキュリティを採用したトランスポートが優先されるべきです。制約のあるシナリオでは、DNS over DTLS よりも DNS over CoAP の方が適しています。ただし、優先度に関する最終決定はユースケースに大きく依存するため、実装者またはユーザーに委ねられており、このドキュメントでは定義されていません。
CoAP supports Confirmable and Non-Confirmable messages [RFC7252] to deploy different levels of reliability. However, this document does not enforce any of these message types, as the decision on which one is appropriate depends on the characteristics of the network where DoC is deployed.
CoAP は、さまざまなレベルの信頼性を展開するために、確認可能メッセージと非確認可能メッセージ [RFC7252] をサポートしています。ただし、どのメッセージ タイプが適切であるかは DoC が展開されているネットワークの特性に依存するため、この文書ではこれらのメッセージ タイプを強制するものではありません。
Application-layer redirects (e.g., HTTP) redirect a client to a new server. In the case of DoC, this leads to a new DNS server. This new DNS server may provide different answers to the same DNS query than the previous DNS server. At the time of writing, CoAP does not support redirection. Future specifications of CoAP redirect may need to consider the impact of different results between previous and new DNS servers.
アプリケーション層のリダイレクト (HTTP など) は、クライアントを新しいサーバーにリダイレクトします。DoC の場合、これは新しい DNS サーバーにつながります。この新しい DNS サーバーは、同じ DNS クエリに対して以前の DNS サーバーとは異なる回答を提供する可能性があります。この記事の執筆時点では、CoAP はリダイレクトをサポートしていません。CoAP リダイレクトの将来の仕様では、以前の DNS サーバーと新しい DNS サーバー間の異なる結果の影響を考慮する必要がある可能性があります。
Mistakes might lead to CoAP proxies forming infinite loops. Using the CoAP Hop-Limit option [RFC8768] mitigates such loops.
間違いがあると、CoAP プロキシが無限ループを形成する可能性があります。CoAP ホップ制限オプション [RFC8768] を使用すると、このようなループが軽減されます。
Section 4.3.1 specifies that DNS operational errors should be reported back to a DoC client using the appropriate DNS RCODE. If a DoC client did not receive any successful DNS messages from a DoC server for a while, it might indicate that the DoC server lost connectivity to the upstream DNS infrastructure. The DoC client should handle this error case like a recursive resolver that lost connectivity to the upstream DNS infrastructure. In case of CoAP errors, the usual mechanisms for CoAP response codes apply.
セクション 4.3.1 では、適切な DNS RCODE を使用して DNS 操作エラーを DoC クライアントに報告する必要があると規定しています。DoC クライアントが DoC サーバーから成功した DNS メッセージをしばらく受信しなかった場合は、DoC サーバーが上流の DNS インフラストラクチャへの接続を失ったことを示している可能性があります。DoC クライアントは、アップストリーム DNS インフラストラクチャへの接続を失った再帰リゾルバーと同様に、このエラー ケースを処理する必要があります。CoAP エラーの場合、CoAP 応答コードの通常のメカニズムが適用されます。
DNS extensions that are specific to the choice of transport, such as described in [RFC7828], are not applicable to DoC.
[RFC7828] で説明されているような、トランスポートの選択に固有の DNS 拡張は、DoC には適用できません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
[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>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020,
<https://www.rfc-editor.org/info/rfc8765>.
[RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop-Limit Option", RFC 8768,
DOI 10.17487/RFC8768, March 2020,
<https://www.rfc-editor.org/info/rfc8768>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers",
RFC 9461, DOI 10.17487/RFC9461, November 2023,
<https://www.rfc-editor.org/info/rfc9461>.
[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>.
[RFC9952] Lenders, M. S., Amsüss, C., Schmidt, T. C., and M.
Wählisch, "Application-Layer Protocol Negotiation (ALPN)
ID for CoAP over DTLS", RFC 9952, DOI 10.17487/RFC9952,
March 2026, <https://www.rfc-editor.org/info/rfc9952>.
[STD13] Internet Standard 13,
<https://www.rfc-editor.org/info/std13>.
At the time of writing, this STD comprises the following:
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[BCP219] Best Current Practice 219,
<https://www.rfc-editor.org/info/bcp219>.
At the time of writing, this BCP comprises the following:
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[BCP237] Best Current Practice 237,
<https://www.rfc-editor.org/info/bcp237>.
At the time of writing, this BCP comprises the following:
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[CACHEABLE-OSCORE]
Amsüss, C. and M. Tiloca, "End-to-End Protected and
Cacheable Responses for the Constrained Application
Protocol (CoAP) using Group Object Security for
Constrained RESTful Environments (Group OSCORE)", Work in
Progress, Internet-Draft, draft-ietf-core-cacheable-
oscore-01, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
cacheable-oscore-01>.
[CoAP-CORR-CLAR]
Bormann, C., "Constrained Application Protocol (CoAP):
Corrections and Clarifications", Work in Progress,
Internet-Draft, draft-ietf-core-corr-clar-04, 19 March
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
core-corr-clar-04>.
[CRI] Bormann, C. and H. Birkholz, "Constrained Resource
Identifiers", Work in Progress, Internet-Draft, draft-
ietf-core-href-30, 21 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
href-30>.
[DoC-paper]
Lenders, M. S., Amsüss, C., Gündogan, C., Nawrocki, M.,
Schmidt, T., and M. Wählisch, "Securing Name Resolution in
the IoT: DNS over CoAP", Proceedings of the ACM on
Networking, vol. 1, no. CoNEXT2, pp. 1-25,
DOI 10.1145/3609423, September 2023,
<https://doi.org/10.1145/3609423>.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000,
<https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7228bis]
Bormann, C., Ersue, M., Keränen, A., and C. Gomez,
"Terminology for Constrained-Node Networks", Work in
Progress, Internet-Draft, draft-ietf-iotops-7228bis-05, 14
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-iotops-7228bis-05>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016,
<https://www.rfc-editor.org/info/rfc7828>.
[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>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/info/rfc9076>.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/info/rfc9176>.
[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>.
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/info/rfc9528>.
[TRANSPORT-IND]
Amsüss, C. and M. S. Lenders, "CoAP Transport Indication",
Work in Progress, Internet-Draft, draft-ietf-core-
transport-indication-09, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
transport-indication-09>.
The authors of this document presented the design, implementation, and analysis of DoC in their paper "Securing Name Resolution in the IoT: DNS over CoAP" [DoC-paper].
このドキュメントの著者は、論文「IoT における名前解決の保護: CoAP 上の DNS」[DoC 論文] で DoC の設計、実装、および分析を紹介しました。
The authors of this document want to thank Mike Bishop, Carsten Bormann, Mohamed Boucadair, Deb Cooley, Vladimír Čunát, Roman Danyliw, Elwyn B. Davies, Esko Dijk, Gorry Fairhurst, Thomas Fossati, Mikolai Gütschow, Todd Herr, Tommy Pauly, Jan Romann, Ben Schwartz, Orie Steele, Marco Tiloca, Éric Vyncke, Tim Wicinski, and Paul Wouters for their feedback and comments.
この文書の著者は、Mike Bishop、Carsten Bormann、Mohamed Boucadair、Deb Cooley、Vladimír Čunát、Roman Danyliw、Elwyn B. Davies、Esko Dijk、Gorry Fairhurst、Thomas Fossati、Mikolai Gütschow、Todd Herr、Tommy Pauly、Jan Romann、Ben Schwartz、Orie Steele、Marco に感謝します。Tiloca、Éric Vyncke、Tim Wicinski、Paul Wouters からフィードバックとコメントをいただきました。
This work was supported in parts by the German Federal Ministry of Research, Technology and Space (BMFTR) under the grant numbers 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the research project PIVOT and under the grant numbers 16KIS1694K (TU Dresden) and 16KIS1695 (HAW Hamburg) within the research project C-ray4edge.
この研究は、研究プロジェクト PIVOT 内の助成金番号 16KIS1386K (TU ドレスデン) および 16KIS1387 (HAW ハンブルク) に基づき、研究プロジェクト C-ray4edge 内の助成金番号 16KIS1694K (TU ドレスデン) および 16KIS1695 (HAW ハンブルク) に基づき、ドイツ連邦研究技術宇宙省 (BMFTR) によって部分的に支援されました。
Martine Sophie Lenders
TUD Dresden University of Technology
Helmholtzstr. 10
D-01069 Dresden
Germany
Email: martine.lenders@tu-dresden.de
Christian Amsüss
Email: christian@amsuess.com
Cenk Gündoğan
NeuralAgent GmbH
Mies-van-der-Rohe-Straße 6
D-80807 Munich
Germany
Email: cenk.gundogan@neuralagent.ai
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
D-20099 Hamburg
Germany
Email: t.schmidt@haw-hamburg.de
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
Helmholtzstr. 10
D-01069 Dresden
Germany
Email: m.waehlisch@tu-dresden.de