[要約] RFC 6804は、マルチキャストDNSクエリをサポートするための仕様であり、マルチキャストDNSのクエリと応答の動作を定義しています。このRFCの目的は、ネットワーク上のデバイスがマルチキャストDNSを使用してサービスを発見できるようにすることです。
Independent Submission B. Manning
Request for Comments: 6804 November 2012
Category: Historic
ISSN: 2070-1721
DISCOVER: Supporting Multicast DNS Queries
発見：マルチキャストDNSクエリのサポート
Abstract
概要
This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.
このドキュメントでは、リソースディスカバリにマルチキャストクエリを使用するためのドメインネームシステム（DNS）の実験的な拡張であるDISCOVERオペコードについて説明します。このオペコードは、トポロジベースドメイン検索（TBDS）プロジェクトの1995年と1996年に実行された実験でテストされました。このプロジェクトは現在アクティブではなく、再起動する現在の計画はありません。 TBDSは、DNSのマルチキャストトランスポートの最初の既知の使用法でした。クライアントは、DISCOVERオペコードを使用してDNSクエリをマルチキャストし、結果として生じる可能性のある複数の応答を処理します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはInternet Standards Trackの仕様ではありません。歴史的な記録として掲載されています。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの歴史的ドキュメントを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6804.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6804で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
The TBDS project developed extensions to existing network services to enable software for clients and servers of an application to become more resilient to changes in topology by dynamically sensing changes and switching between client/server and peer-peer methods for both end-system-to-server and server-to-server communications.
TBDSプロジェクトは、既存のネットワークサービスの拡張機能を開発し、アプリケーションのクライアントとサーバー用のソフトウェアが動的に変化を検知し、クライアント/サーバーとピアピア方式を切り替えてエンドシステムからサーバーおよびサーバー間通信。
The first existing network service to be investigated was the Domain Name Systems (DNS), which is used to map symbolic Internet names to numeric Internet addresses. Based upon a hierarchical tree structure, the DNS relies upon uninterrupted connectivity of nodes to a special set of static, manually configured root servers. To improve the robustness and availability of the DNS service, TBDS developed and defined enhancements that enable nodes to map names to numbers without the need for uninterrupted connectivity to the Internet root servers. These techniques were automated, allowing transition between connected and unconnected operations to be done without direct human intervention.
調査される最初の既存のネットワークサービスは、ドメインネームシステム（DNS）でした。これは、シンボルインターネット名を数値インターネットアドレスにマップするために使用されます。階層ツリー構造に基づいて、DNSは、手動で構成された静的なルートサーバーの特別なセットへのノードの中断のない接続に依存しています。 DNSサービスの堅牢性と可用性を向上させるために、TBDSは、ノードがインターネットルートサーバーへの接続を中断することなく名前を番号にマッピングできるようにする拡張機能を開発および定義しました。これらの技術は自動化されており、接続された操作と接続されていない操作の間の移行を、人間が直接介入することなく実行できます。
These enhancements to the DNS server code are based on the open source BIND to support reception and processing of multicast packets.
DNSサーバーコードに対するこれらの機能強化は、マルチキャストパケットの受信と処理をサポートするオープンソースのBINDに基づいています。
Proof-of-concept modifications to BIND 8.1.2 were made to show that multicast awareness could be added to BIND. An analysis was made of the existing DNS code deployment and the schedule of new feature deployment so that we could synchronize TBDS with a more appropriate code base. Testing identified a race condition due to overloading the semantics of the DNS opcode that was used to communicate to servers.
BIND 8.1.2に対する概念実証の変更は、マルチキャスト認識がBINDに追加できることを示すために行われました。 TBDSをより適切なコードベースと同期できるように、既存のDNSコードの展開と新機能の展開のスケジュールを分析しました。テストでは、サーバーとの通信に使用されたDNSオペコードのセマンティクスの過負荷による競合状態が特定されました。
This race condition was explored within the IETF regarding use of existing DNS opcodes. Discussion within the team and with others in the IETF led to the idea that we needed a new opcode that would not overload the semantics of existing opcodes. The original DNS design specification presumes that few clients exist that would share common DNS data. To correct this problem, a new opcode was designed to disambiguate TBDS requests from normal nameserver requests.
この競合状態は、既存のDNSオペコードの使用に関してIETF内で調査されました。チーム内およびIETF内の他のメンバーとの議論により、既存のオペコードのセマンティクスを過負荷にしない新しいオペコードが必要であるという考えが導き出されました。元のDNS設計仕様では、一般的なDNSデータを共有するクライアントはほとんど存在しないと想定しています。この問題を修正するために、通常のネームサーバー要求からTBDS要求を明確にするために、新しいオペコードが設計されました。
In the standard Domain Name System (DNS) [1] [2], queries are always unicast using the QUERY opcode. The TBDS research project [5], funded under DARPA grant F30602-99-1-0523, explored the use of multicast DNS [1] [2] queries for resource discovery by autonomous, mobile nodes in disconnected networks. The operations model is covered in the TBDS documentation. Multicast queries may return multiple replies, while the standard DNS QUERY operation (see Sections 3.7, 4.3, and 5 of RFC 1034 [1]; and Section 4.1.1 of RFC 1035 [2]) expects a single reply. Instead of extending the QUERY
標準のドメインネームシステム（DNS）[1] [2]では、クエリは常にQUERYオペコードを使用してユニキャストされます。 DARPAの助成金F30602-99-1-0523で資金提供されたTBDS研究プロジェクト[5]は、切断されたネットワーク内の自律モバイルノードによるリソース検出のためのマルチキャストDNS [1] [2]クエリの使用を調査しました。運用モデルはTBDSのドキュメントで説明されています。マルチキャストクエリは複数の応答を返す可能性がありますが、標準のDNSクエリ操作（RFC 1034 [1]のセクション3.7、4.3、および5、およびRFC 1035 [2]のセクション4.1.1を参照）は単一の応答を期待します。クエリを拡張する代わりに
opcode, the project developed and tested a new query operation, DISCOVER, that was designed to accommodate multiple responses from a multicast query. The ability to accept multiple replies provides a basis for discrimination of man-in-the-middle attacks, which succeed by being the first to respond. Use of DISCOVER requires the use of caching in the receiver, so the ephemeral nature of stub resolvers is precluded.
opcode、プロジェクトは、マルチキャストクエリからの複数の応答に対応するように設計された新しいクエリ操作DISCOVERを開発してテストしました。複数の応答を受け入れる機能は、最初に応答することで成功する中間者攻撃を区別するための基礎を提供します。 DISCOVERを使用するには、レシーバーでキャッシングを使用する必要があるため、スタブリゾルバーの一時的な性質は排除されます。
This memo documents the processing rules for DISCOVER, for possible incorporation in a future revision of the DNS specification.
このメモは、DNS仕様の将来の改訂に組み込まれる可能性があるため、DISCOVERの処理規則を文書化しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [3]で説明されているように解釈されます。
A requester will send a DISCOVER query message to a multicast destination address, with some particular multicast scope. The requester must be prepared to receive multiple replies from multiple responders, although we expect that there will be a single reply per responder.
リクエスタは、特定のマルチキャストスコープを使用して、DISCOVERクエリメッセージをマルチキャスト宛先アドレスに送信します。リクエスタごとに1つの応答があると予想されますが、リクエスタは複数のレスポンダから複数の応答を受信する準備をする必要があります。
DISCOVER responses (i.e., response messages from DISCOVER queries) have standard Answer, Authority, and Additional sections. For example, the DISCOVER response is the same as the response to a QUERY operation. Zero-content answers should not be sent, to avoid badly formed or unfulfilled requests. Responses should be sent to the unicast address of the requester, and the source address should reflect the unicast address of the responder. DISCOVER responses may echo the request's Question section or leave it blank, just as for QUERY.
DISCOVER応答（つまり、DISCOVERクエリからの応答メッセージ）には、標準のAnswer、Authority、およびAdditionalセクションがあります。たとえば、DISCOVER応答はQUERY操作に対する応答と同じです。不正な形式のリクエストや満たされていないリクエストを回避するために、ゼロコンテンツの回答は送信しないでください。応答はリクエスタのユニキャストアドレスに送信され、送信元アドレスはレスポンダのユニキャストアドレスを反映している必要があります。 DISCOVER応答は、QUERYの場合と同様に、要求の質問セクションをエコーするか、空白のままにすることができます。
DISCOVER works like QUERY, with the following exceptions:
DISCOVERはQUERYのように機能しますが、次の例外があります。
1. The Question section of a DISCOVER operation contains <QNAME=zonename,QTYPE=SOA> tuples, if the section is present.
1. DISCOVER操作の質問セクションには、セクションが存在する場合、<QNAME = zonename、QTYPE = SOA>タプルが含まれています。
Within TBDS, this structure was augmented with: <QNAME=service,QTYPE=SRV>. While this worked, it would be cleaner to ask the SRV question in a separate pass; any future work should take this into consideration.
TBDS内では、この構造に<QNAME = service、QTYPE = SRV>が追加されました。これは機能しましたが、別のパスでSRVの質問をする方がきれいです。今後の作業では、これを考慮に入れる必要があります。
2. If QDCOUNT equals 0, then only servers willing to do recursion should answer; other servers must silently discard a DISCOVER request with QDCOUNT equals 0.
2. QDCOUNTが0の場合、再帰を実行するサーバーだけが応答する必要があります。他のサーバーは、QDCOUNTが0のDISCOVER要求をサイレントに破棄する必要があります。
3. If QDCOUNT is not equal to 0, then only servers that are authoritative for the zones named by some QNAME should answer.
3. QDCOUNTが0に等しくない場合は、一部のQNAMEによって指定されたゾーンに対して権限を持つサーバーのみが応答する必要があります。
Hence, replies to DISCOVER queries will always be authoritative or else have RA (Recursion Available) set.
したがって、DISCOVERクエリへの返信は常に信頼できるものになるか、RA（再帰利用可能）が設定されます。
To perform a hostname lookup using DISCOVER, a node could:
DISCOVERを使用してホスト名ルックアップを実行するには、ノードで次のことができます。
o Compute the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain.
o 囲んでいるin-addr.arpa、ip6.int、またはip6.arpaドメインのゾーン名を計算します。
o DISCOVER whether any in-scope server(s) are authoritative for this zone.
o スコープ内のサーバーがこのゾーンに対して権限があるかどうかを検出します。
If so, query these authoritative servers for local in-addr/ip6 names.
その場合は、これらの権限のあるサーバーにローカルのaddr / ip6名を照会します。
o If not, DISCOVER whether there are recursive servers available.
o そうでない場合は、利用可能な再帰サーバーがあるかどうかを調べます。
If so, query these recursive servers for local in-addr/ip6 names.
その場合は、これらの再帰サーバーにローカルのaddr / ip6名を照会します。
The requester can determine from the replies whether there are any DNS servers that are authoritative (or support recursion) for the zone.
リクエスターは、ゾーンに対して権限のある（または再帰をサポートする）DNSサーバーがあるかどうかを応答から判別できます。
o Once the host's Fully Qualified Domain Name (FQDN) is known, repeat the process to discover the closest enclosing authoritative server for this local name.
o ホストの完全修飾ドメイン名（FQDN）がわかったら、プロセスを繰り返して、このローカル名に最も近い権限のあるサーバーを検出します。
o Cache all NS and A data learned in this process, respecting Times To Live (TTLs).
o このプロセスで学習したすべてのNSおよびAデータをキャッシュし、Times To Live（TTL）を尊重します。
To lookup a service name using DISCOVER, the following steps may be used:
DISCOVERを使用してサービス名を検索するには、次の手順を使用できます。
o Use DISCOVER as outlined in Section 3.1 to perform gethostbyaddr() and then gethostbyname() on one's own link-local address. This gives a list of local authoritative servers.
o セクション3.1で概説されているようにDISCOVERを使用して、自分のリンクローカルアドレスに対してgethostbyaddr()を実行し、次にgethostbyname()を実行します。これにより、ローカルの信頼できるサーバーの一覧が表示されます。
o Assume that the closest enclosing zone for which an authoritative server responds to an in-scope DISCOVER message is this host's "parent domain", and compute the SRV name as
o 権限のあるサーバーがスコープ内のDISCOVERメッセージに応答する最も近い囲みゾーンは、このホストの「親ドメイン」であり、SRV名を次のように計算するとします。
_service._transport.*.parentdomain.
_service._transport。*。parentdomain。
This is a change to the definition provided in RFC 1034 [1]. A wildcard label ("*") in the QNAME used in a DNS message with the opcode DISCOVER should be evaluated with special rules: the wildcard should match any label for which the DNS server data is authoritative. For example 'x.*.example.com.' would match 'x.y.example.com.' and 'x.yy.example.com.', provided that the server was authoritative for 'example.com.'
これは、RFC 1034 [1]で提供されている定義に対する変更です。オペコードDISCOVERのDNSメッセージで使用されるQNAMEのワイルドカードラベル（ "*"）は、特別なルールで評価する必要があります。ワイルドカードは、DNSサーバーデータが信頼できるすべてのラベルと一致する必要があります。たとえば、「x。*。example.com。」 「x.y.example.com」と一致しますおよび「x.yy.example.com。」（ただし、サーバーが「example.com」に対して権限を持っている場合）
o Finally, send an SRV query for this SRV name to the discovered local authoritative servers to complete the getservbyname() call.
o 最後に、このSRV名のSRVクエリを検出されたローカルの信頼できるサーバーに送信して、getservbyname()呼び出しを完了します。
This call returns a structure that can be populated by response values, as follows:
この呼び出しは、次のように、応答値を入力できる構造を返します。
s_name The name of the service, "_service" without the preceding underscore.
s_nameアンダースコアを除いたサービスの名前「_service」。
s_aliases The names returned in the SRV Resource Records (RRs) in replies to the query.
s_aliasesクエリへの応答でSRVリソースレコード（RR）に返される名前。
s_port The port number in the SRV RRs replies to the query. If these port numbers do not match, one of the port numbers is chosen, and only those names that correspond are returned.
s_port SRV RRのポート番号はクエリに応答します。これらのポート番号が一致しない場合、ポート番号の1つが選択され、対応する名前のみが返されます。
s_proto The transport protocol passed from the DNS process using the "_transport" label, without the preceding underscore.
s_proto前のアンダースコアなしで、「_ transport」ラベルを使用してDNSプロセスから渡されたトランスポートプロトコル。
DISCOVER allows discovery of a host (for example, a printer offering LPD services) whose DNS server answers authoritatively for a domain name that hasn't been delegated to it, but is defined within some local scope. Since DISCOVER is explicitly defined to discover undelegated zones for tightly scoped queries, this behavior isn't a violation of DNS's coherency principles. Note that a responder to DISCOVER might not be traditional DNS software, it could be special-purpose software.
DISCOVERを使用すると、委任されていないが、ローカルスコープ内で定義されているドメイン名に対してDNSサーバーが正式に応答するホスト（LPDサービスを提供するプリンターなど）を検出できます。 DISCOVERは、厳密にスコープされたクエリの委任されていないゾーンを検出するように明示的に定義されているため、この動作はDNSの一貫性の原則に違反しません。 DISCOVERへの応答側は、従来のDNSソフトウェアではなく、専用のソフトウェアである可能性があることに注意してください。
DISCOVER usage for disconnected networks with no authoritative servers can be achieved using the following conditions:
権限のあるサーバーがない切断されたネットワークのDISCOVERの使用は、次の条件を使用して実現できます。
o Hosts run a "stub authoritative server" that acts as though its FQDN were a zone name.
o ホストは、FQDNがゾーン名であるかのように機能する「スタブ権限サーバー」を実行します。
o The computed SOA gives the host's FQDN as the MNAME, "." as the ANAME, seconds-since-1Jan2000 as the SERIAL, and low constants for EXPIRE and the other SOA timers.
o 計算されたSOAは、ホストのFQDNをMNAMEとして提供します。 ANAMEとして、seconds-since-1Jan2000をSERIALとして、EXPIREおよびその他のSOAタイマー用の低定数。
o NS is used as the host's FQDN.
o NSはホストのFQDNとして使用されます。
o The glue is computed as the host's link-local address, or hosts may run a "DNS stub server" that acts as though its FQDN were a zone name.
o 接着剤は、ホストのリンクローカルアドレスとして計算されます。または、ホストは、そのFQDNがゾーン名であるかのように機能する「DNSスタブサーバー」を実行する場合があります。
The rules governing the behavior of this server consist of a single change to the method of use, and no change whatsoever to the current format of DNS packets. Specifically, this extension allows UDP DNS queries, as documented in RFC 1035, Sections 4.1.1, 4.1.2, and 4.2.1, to be addressed to port 53 of statically assigned relative offset -4 within the range of multicast addresses defined as "administratively scoped" by Section 9 of RFC 2365 [6]. Within the full /8 of administratively scoped addresses, this corresponds to the destination address 239.255.255.251. Until the Multicast-Scope Zone Announcement Protocol (MZAP) or a similar protocol is implemented to allow hosts to discover the extent of the local multicast scopes that enclose them, it is anticipated that implementations will simply utilize the destination address 239.255.255.251. Queries sent via multicast MUST NOT request recursion.
このサーバーの動作を管理するルールは、使用方法の1つの変更で構成されており、DNSパケットの現在の形式はまったく変更されていません。具体的には、この拡張機能により、RFC 1035、セクション4.1.1、4.1.2、および4.2.1に記載されているUDP DNSクエリを、次のように定義されたマルチキャストアドレスの範囲内で静的に割り当てられた相対オフセット-4のポート53にアドレス指定できます。 RFC 2365 [6]のセクション9による「管理用スコープ」。管理スコープアドレスの完全な/ 8内で、これは宛先アドレス239.255.255.251に対応します。マルチキャストスコープゾーンアナウンスプロトコル（MZAP）または同様のプロトコルが実装されて、ホストがそれらを囲むローカルマルチキャストスコープの範囲を検出できるようになるまで、実装は宛先アドレス239.255.255.251を単に利用すると予想されます。マルチキャスト経由で送信されたクエリは、再帰を要求してはなりません。
In order to receive multicasted queries, DNS server implementations MUST listen on the -4 offset to their local scope (as above, in the absence of a method of determining the scope, this will be assumed to be relative to the full /8 allocated for administratively scoped multicast use, or 239.255.255.251) and respond via ordinary unicast UDP to ONLY those queries for which they have a positive answer that originated within a locally-configured zone file. That is, a server MUST NOT answer a multicasted query with cached information that it received from another server, nor may it request further resolution from other servers on behalf of a multicasted query. A multicast-capable server may, however, utilize multicast queries to perform further resolution on behalf of queries received via ordinary unicast. This is referred to as "proxy" operation. Multicast-enabled DNS servers MUST answer multicasted queries non-authoritatively. That is, when responding to a query that was received via multicast, they MUST NOT include an NS record that contains data that resolves back to their own IP address and MUST NOT set the AA bit.
マルチキャストされたクエリを受信するために、DNSサーバーの実装はローカルスコープへの-4オフセットをリッスンする必要があります（上記のように、スコープを決定する方法がない場合、これは割り当てられた完全な/ 8に関連していると想定されます）管理的にスコープされたマルチキャストの使用、または239.255.255.251）を行い、通常のユニキャストUDPを介して、ローカルに構成されたゾーンファイル内で発生した肯定的な応答があるクエリのみに応答します。つまり、サーバーは、別のサーバーから受信したキャッシュされた情報でマルチキャストクエリに応答してはならず、マルチキャストクエリに代わって他のサーバーにさらなる解決を要求してはなりません。ただし、マルチキャスト対応サーバーは、マルチキャストクエリを利用して、通常のユニキャスト経由で受信したクエリに代わってさらに解決を行うことができます。これは「プロキシ」操作と呼ばれます。マルチキャスト対応のDNSサーバーは、権限のない方法でマルチキャストクエリに応答する必要があります。つまり、マルチキャストを介して受信されたクエリに応答するとき、それらは自身のIPアドレスに解決されるデータを含むNSレコードを含めてはならず、AAビットを設定してはなりません（MUST NOT）。
Resolvers MUST anticipate receiving no replies to some multicasted queries, in the event that no multicast-enabled DNS server implementations are active within the local scope, or in the event that no positive responses exist to the transmitted query. That is, a query for the MX record for host.domain.com would go unanswered if no local server was able to resolve that request, if no MX record exists for host.domain.com, or if no local servers were capable of receiving multicast queries. The resolver that initiated the query MUST treat such non-response as a non-cacheable negative response. Since this multicast transmission does not provide reliable delivery, resolvers MAY repeat the transmission of a query in order to assure themselves that is has been received by any hosts capable of answering; however, any resolvers that repeat a query MUST increase the interval by a factor of two between each repetition. It is more likely, however, that any repeated queries will be performed under the explicit direction of the application driving the query, rather than autonomously by the resolver implementation.
リゾルバーは、マルチキャストが有効なDNSサーバーの実装がローカルスコープ内でアクティブでない場合、または送信されたクエリに対する肯定的な応答が存在しない場合に、一部のマルチキャストクエリに対する応答を受信しないことを期待する必要があります。つまり、host.domain.comのMXレコードのクエリは、ローカルサーバーがその要求を解決できなかった場合、host.domain.comのMXレコードが存在しない場合、または受信できるローカルサーバーがない場合、応答しなくなります。マルチキャストクエリ。クエリを開始したリゾルバは、そのような非応答をキャッシュ不可の否定応答として扱う必要があります。このマルチキャスト送信は信頼できる配信を提供しないため、リゾルバは、応答可能なホストによって受信されたことを確認するために、クエリの送信を繰り返すことができます。ただし、クエリを繰り返すリゾルバは、各繰り返しの間隔を2倍にする必要があります。ただし、リゾルバー実装によって自律的にではなく、クエリを実行するアプリケーションの明示的な指示の下で、繰り返されるクエリが実行される可能性が高くなります。
It will often be the case that multicast queries will result in responses from multiple servers. In the event that the multicast query was generated via a current API such as gethostbyname, or as the result of a proxy operation, the first response received must be passed to the requesting application or host, and all subsequently received responses must be discarded. Future multicast-aware APIs that use DISCOVER should anticipate receiving multiple independent RR sets in response to queries and using external heuristics for selecting the most appropriate RR set.
多くの場合、マルチキャストクエリが複数のサーバーからの応答になります。マルチキャストクエリがgethostbynameなどの現在のAPIを介して、またはプロキシ操作の結果として生成された場合、受信した最初の応答を要求元のアプリケーションまたはホストに渡し、その後受信したすべての応答を破棄する必要があります。 DISCOVERを使用する将来のマルチキャスト対応APIは、クエリに応答して複数の独立したRRセットを受信し、外部ヒューリスティックを使用して最も適切なRRセットを選択することを期待する必要があります。
Such servers should answer DISCOVER packets for its zone, and will be found by the iterative "discover closest enclosing authority server" by DISCOVER clients, in either the gethostbyname() or SRV cases described above. Note that stub servers answer only with zone names that exactly match QNAME's, not with zone names that are owned by QNAME's.
このようなサーバーは、そのゾーンのDISCOVERパケットに応答する必要があり、前述のgethostbyname()またはSRVのいずれかの場合に、DISCOVERクライアントによって反復「最も近い囲んでいる認証サーバーを検出」によって検出されます。スタブサーバーは、QNAMEと完全に一致するゾーン名でのみ応答し、QNAMEが所有するゾーン名では応答しないことに注意してください。
At such time as this idea might be considered for a future addition to the DNS protocol, IANA would need to assign a value for the opcode.
このアイデアが将来DNSプロトコルに追加される可能性があるため、IANAはオペコードに値を割り当てる必要があります。
The following paragraph on security considerations was written very early in the use and exploration of IP multicast and, as such, represents a fairly naive view on the type and scope of exploits that are enabled through the use of IP multicast. A more up-to-date understanding of multicast security considerations may be found in RFC 5294 [4].
セキュリティの考慮事項に関する次の段落は、IPマルチキャストの使用と調査の非常に早い段階で記述されたものであり、IPマルチキャストの使用によって可能になる悪用の種類と範囲については非常にナイーブな見方を表しています。マルチキャストセキュリティの考慮事項のより最新の理解は、RFC 5294 [4]にあります。
No new security considerations are known to be introduced with a new DNS query operation. However, using multicast for service discovery has the potential for denial of service from flooding attacks. How to scope multicast is not part of the DISCOVER processing rules. It may also be possible to enable deliberate misconfiguration of clients simply by running a malicious DNS server that falsely claims to be authoritative for delegations. One possible way to mitigate this threat is to use credentials, such as CERT resource records within an RR set. The TBDS project took this approach. TBDS did not directly utilize DNS Security (DNSSEC), so possible interactions with DNSSEC-aware/-capable servers are unknown.
新しいDNSクエリ操作で導入される新しいセキュリティの考慮事項は知られていません。ただし、サービス検出にマルチキャストを使用すると、フラッディング攻撃によるサービス拒否の可能性があります。マルチキャストのスコープ方法は、DISCOVER処理ルールの一部ではありません。また、委任に対して権限があると偽って主張する悪意のあるDNSサーバーを実行するだけで、クライアントの意図的な誤構成を有効にすることもできます。この脅威を軽減する1つの可能な方法は、RRセット内のCERTリソースレコードなどの資格情報を使用することです。 TBDSプロジェクトはこのアプローチを採用しました。 TBDSはDNSセキュリティ（DNSSEC）を直接利用していなかったため、DNSSEC対応/対応サーバーとの相互作用の可能性は不明です。
This material was generated in discussions on the mdns mailing list hosted by Zocalo in March 2000 and updated by discussions in September/October 2003 on a closed mailing list. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, and Erik Guttman were active contributors. Suzanne Woolf was part of the original implementation team and an invaluable sanity checker. Funding for the RFC Editor function is currently provided by the Internet Society.
この資料は、2000年3月にZocaloがホストするmdnsメーリングリストでのディスカッションで生成され、クローズドメーリングリストでの2003年9月/ 10月のディスカッションで更新されました。デビッド・ローレンス、スコット・ローズ、スチュアート・チェシャー、ビル・ウッドコック、エリック・ガットマンが積極的に貢献しました。 Suzanne Woolfは元の実装チームの一員であり、非常に貴重な健全性チェッカーでした。 RFC Editor機能への資金提供は、現在Internet Societyから提供されています。
[1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P。、「DOMAIN NAMES-CONCEPTS AND FACILITIES」、STD 13、RFC 1034、1987年11月。
[2] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", STD 13, RFC 1035, November 1987.
[2] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008.
[4] Savola、P。およびJ. Lingard、「ホストからの脅威、プロトコルに依存しないマルチキャスト（PIM）」、RFC 5294、2008年8月。
[5] Manning, B., "Topology Based Domain Search (TBDS)", Final Report, June 2002, <http://www.dtic.mil/docs/citations/ADA407598>.
[5] Manning、B。、「Topology Based Domain Search（TBDS）」、最終報告、2002年6月、<http://www.dtic.mil/docs/citations/ADA407598>。
[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[6] Meyer、D。、「Administratively Scoped IP Multicast」、BCP 23、RFC 2365、1998年7月。
Authors' Addresses
著者のアドレス
Bill Manning PO 12317 Marina del Rey, CA. 90295 United States
ビルマニングPO 12317マリナデルレイ、カリフォルニア。 90295アメリカ合衆国
EMail: bmanning@sfc.keio.ac.jp