[要約] RFC 8766は、マルチキャストDNSベースのサービスディスカバリのためのディスカバリプロキシに関する規格です。このRFCの目的は、ネットワーク内のデバイスがマルチキャストDNSを使用してサービスを発見できるようにすることです。
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 8766 Apple Inc.
Category: Standards Track June 2020
ISSN: 2070-1721
Discovery Proxy for Multicast DNS-Based Service Discovery
マルチキャストDNSベースのサービスディスカバリ用のディスカバリプロキシ
Abstract
概要
This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link.
このドキュメントでは、マルチキャストDNSを使用して、広域ユニキャストドメインネームシステムの名前空間に、ローカルリンクで見つかったデバイスとサービスを説明するレコードを自動的に設定するネットワークプロキシを指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8766.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8766で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Operational Analogy
3. Conventions and Terminology Used in This Document
4. Compatibility Considerations
5. Discovery Proxy Operation
5.1. Delegated Subdomain for DNS-based Service Discovery Records
5.2. Domain Enumeration
5.2.1. Domain Enumeration via Unicast Queries
5.2.2. Domain Enumeration via Multicast Queries
5.3. Delegated Subdomain for LDH Host Names
5.4. Delegated Subdomain for Reverse Mapping
5.5. Data Translation
5.5.1. DNS TTL Limiting
5.5.2. Suppressing Unusable Records
5.5.3. NSEC and NSEC3 Queries
5.5.4. No Text-Encoding Translation
5.5.5. Application-Specific Data Translation
5.6. Answer Aggregation
6. Administrative DNS Records
6.1. DNS SOA (Start of Authority) Record
6.2. DNS NS Records
6.3. DNS Delegation Records
6.4. DNS SRV Records
6.5. Domain Enumeration Records
7. DNSSEC Considerations
7.1. Online Signing Only
7.2. NSEC and NSEC3 Records
8. IPv6 Considerations
9. Security Considerations
9.1. Authenticity
9.2. Privacy
9.3. Denial of Service
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Implementation Status
A.1. Already Implemented and Deployed
A.2. Already Implemented
A.3. Partially Implemented
Acknowledgments
Author's Address
Multicast DNS [RFC6762] and its companion technology DNS-based Service Discovery [RFC6763] were created to provide IP networking with the ease of use and autoconfiguration for which AppleTalk was well known [RFC6760] [ZC] [ROADMAP].
マルチキャストDNS [RFC6762]とその関連テクノロジであるDNSベースのサービスディスカバリ[RFC6763]は、AppleTalkがよく知られた[RFC6760] [ZC] [ROADMAP]の使いやすさと自動構成をIPネットワーキングに提供するために作成されました。
For a small home network consisting of just a single link (or a few physical links bridged together to appear as a single logical link from the point of view of IP), Multicast DNS [RFC6762] is sufficient for client devices to look up the ".local" host names of peers on the same home network, and to use Multicast DNS-based Service Discovery (DNS-SD) [RFC6763] to discover services offered on that home network.
単一のリンク（またはIPの観点からは単一の論理リンクとして表示されるようにブリッジされたいくつかの物理リンク）のみで構成される小さなホームネットワークの場合、マルチキャストDNS [RFC6762]でクライアントデバイスは「同じホームネットワーク上のピアの.local "ホスト名。マルチキャストDNSベースのサービス検出（DNS-SD）[RFC6763]を使用して、そのホームネットワークで提供されるサービスを検出します。
For a larger network consisting of multiple links that are interconnected using IP-layer routing instead of link-layer bridging, link-local Multicast DNS alone is insufficient because link-local Multicast DNS packets, by design, are not propagated onto other links.
リンクレイヤーブリッジングの代わりにIPレイヤールーティングを使用して相互接続された複数のリンクで構成される大規模なネットワークでは、リンクローカルマルチキャストDNSパケットは設計上、他のリンクに伝播されないため、リンクローカルマルチキャストDNSだけでは不十分です。
Using link-local multicast packets for Multicast DNS was a conscious design choice [RFC6762]. Even when limited to a single link, multicast traffic is still generally considered to be more expensive than unicast, because multicast traffic impacts many devices instead of just a single recipient. In addition, with some technologies like Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and less reliable than unicast, because Wi-Fi multicast traffic is sent at lower data rates, and is not acknowledged [MCAST]. Increasing the amount of expensive multicast traffic by flooding it across multiple links would make the traffic load even worse.
マルチキャストDNSにリンクローカルマルチキャストパケットを使用することは、意識的な設計上の選択でした[RFC6762]。マルチキャストトラフィックが単一の受信者だけでなく多くのデバイスに影響を与えるため、単一のリンクに制限されている場合でも、マルチキャストトラフィックは一般的にユニキャストよりも高価であると見なされています。さらに、Wi-Fi [IEEE-11]などの一部のテクノロジーでは、Wi-Fiマルチキャストトラフィックはより低いデータレートで送信され、確認されないため、マルチキャストトラフィックは本質的にユニキャストよりも効率が悪く、信頼性が低くなります[MCAST]。高価なマルチキャストトラフィックを複数のリンクにフラッディングして量を増やすと、トラフィックの負荷がさらに悪化します。
Partitioning the network into many small links curtails the spread of expensive multicast traffic but limits the discoverability of services. At the opposite end of the spectrum, using a very large local link with thousands of hosts enables better service discovery but at the cost of larger amounts of multicast traffic.
ネットワークを多くの小さなリンクに分割すると、高価なマルチキャストトラフィックの拡散が抑制されますが、サービスの検出可能性が制限されます。スペクトラムの反対側では、数千のホストとの非常に大きなローカルリンクを使用すると、サービスの検出が向上しますが、大量のマルチキャストトラフィックが発生します。
Performing DNS-based Service Discovery using purely Unicast DNS is more efficient and doesn't require large multicast domains but does require that the relevant data be available in the Unicast DNS namespace. The Unicast DNS namespace in question could fall within a traditionally assigned globally unique domain name, or it could be within a private local unicast domain name such as ".home.arpa" [RFC8375].
純粋にユニキャストDNSを使用してDNSベースのサービスディスカバリを実行することは、より効率的であり、大規模なマルチキャストドメインを必要としませんが、関連データがユニキャストDNS名前空間で利用可能である必要があります。問題のユニキャストDNS名前空間は、従来割り当てられていたグローバルに一意のドメイン名、または ".home.arpa" [RFC8375]などのプライベートローカルユニキャストドメイン名に含まれる可能性があります。
In the DNS-SD specification [RFC6763], Section 10 ("Populating the DNS with Information") discusses various possible ways that a service's PTR, SRV, TXT, and address records can make their way into the Unicast DNS namespace, including manual zone file configuration [RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007], and proxies of various kinds.
DNS-SD仕様[RFC6763]のセクション10（「DNSへの情報の入力」）では、サービスのPTR、SRV、TXT、およびアドレスレコードが手動ゾーンを含むユニキャストDNS名前空間に到達するためのさまざまな方法について説明していますファイル構成[RFC1034] [RFC1035]、DNSアップデート[RFC2136] [RFC3007]、およびさまざまな種類のプロキシ。
One option is to make the relevant data available in the Unicast DNS namespace by manual DNS configuration. This option has been used for many years at IETF meetings to advertise the IETF terminal room printer. Details of this example are given in Appendix A of the Roadmap document [ROADMAP]. However, this manual DNS configuration is labor intensive, error prone, and requires a reasonable degree of DNS expertise.
1つのオプションは、手動のDNS構成により、関連データをユニキャストDNS名前空間で利用できるようにすることです。このオプションは、IETFミーティングで長年、IETF端末ルームプリンターを宣伝するために使用されていました。この例の詳細は、ロードマップドキュメント[ROADMAP]の付録Aに記載されています。ただし、この手動のDNS構成は労働集約的でエラーが発生しやすく、適度なDNSの専門知識が必要です。
Another option is to populate the Unicast DNS namespace by having the devices offering the services do that themselves, using DNS Update [REG-PROT] [DNS-UL]. However, this requires configuration of DNS Update keys on those devices, which has proven onerous and impractical for simple devices like printers and network cameras.
別のオプションは、DNSアップデート[REG-PROT] [DNS-UL]を使用して、サービスを提供するデバイスにそれ自体を実行させることにより、ユニキャストDNS名前空間を設定することです。ただし、これにはそれらのデバイスでのDNS更新キーの構成が必要であり、プリンターやネットワークカメラなどの単純なデバイスでは面倒で非実用的であることが証明されています。
Hence, to facilitate efficient and reliable DNS-based Service Discovery, a hybrid is needed that combines the ease of use of Multicast DNS with the efficiency and scalability of Unicast DNS.
したがって、効率的で信頼性の高いDNSベースのサービスディスカバリを促進するには、マルチキャストDNSの使いやすさとユニキャストDNSの効率とスケーラビリティを組み合わせたハイブリッドが必要です。
This document specifies a type of proxy called a "Discovery Proxy" that uses Multicast DNS [RFC6762] to discover Multicast DNS records on its local link on demand, and makes corresponding DNS records visible in the Unicast DNS namespace.
このドキュメントでは、マルチキャストDNS [RFC6762]を使用してローカルリンク上のマルチキャストDNSレコードをオンデマンドで検出し、対応するDNSレコードをユニキャストDNS名前空間で表示できるようにする「検出プロキシ」と呼ばれるプロキシのタイプを指定します。
In principle, similar mechanisms could be defined for other local discovery protocols, by creating a proxy that (i) uses the protocol in question to discover local information on demand, and then (ii) makes corresponding DNS records visible in the Unicast DNS namespace. Such mechanisms for other local discovery protocols could be addressed in future documents.
原則として、（i）問題のプロトコルを使用してローカル情報をオンデマンドで検出するプロキシを作成し、（ii）対応するDNSレコードをユニキャストDNS名前空間に表示するプロキシを作成することにより、他のローカル検出プロトコルに対して同様のメカニズムを定義できます。他のローカル検出プロトコルのそのようなメカニズムは、将来のドキュメントで対処される可能性があります。
The design of the Discovery Proxy is guided by the previously published DNS-based Service Discovery requirements document [RFC7558].
Discovery Proxyの設計は、以前に発行されたDNSベースのサービスディスカバリ要件ドキュメント[RFC7558]に基づいています。
In simple terms, a descriptive DNS name is chosen for each link in an organization. Using a DNS NS record, responsibility for that DNS name is delegated to a Discovery Proxy physically attached to that link. When a remote client issues a unicast query for a name falling within the delegated subdomain, the normal DNS delegation mechanism results in the unicast query arriving at the Discovery Proxy, since it has been declared authoritative for those names. Now, instead of consulting a textual zone file on disk to discover the answer to the query as a traditional authoritative DNS server would, a Discovery Proxy consults its local link, using Multicast DNS, to find the answer to the question.
簡単に言うと、説明的なDNS名が組織内のリンクごとに選択されます。 DNS NSレコードを使用して、そのDNS名の責任は、そのリンクに物理的に接続されているDiscovery Proxyに委任されます。リモートクライアントが委任されたサブドメイン内にある名前に対してユニキャストクエリを発行すると、通常のDNS委任メカニズムにより、それらの名前に対して信頼できると宣言されているため、ディスカバリープロキシにユニキャストクエリが到着します。これで、ディスク上のテキストゾーンファイルを調べて、従来の信頼できるDNSサーバーのようにクエリへの回答を見つける代わりに、ディスカバリプロキシがマルチキャストDNSを使用してローカルリンクを調べ、質問への回答を見つけます。
For fault tolerance reasons, there may be more than one Discovery Proxy serving a given link.
フォールトトレランスの理由から、特定のリンクを提供する複数のDiscovery Proxyが存在する場合があります。
Note that the Discovery Proxy uses a "pull" model. Until some remote client has requested data, the local link is not queried using Multicast DNS. In the idle state, in the absence of client requests, the Discovery Proxy sends no packets and imposes no burden on the network. It operates purely "on demand".
Discovery Proxyは「プル」モデルを使用することに注意してください。一部のリモートクライアントがデータを要求するまで、ローカルDNSはマルチキャストDNSを使用して照会されません。アイドル状態では、クライアント要求がない場合、ディスカバリプロキシはパケットを送信せず、ネットワークに負荷をかけません。純粋に「オンデマンド」で動作します。
An alternative proposal that has been discussed is a proxy that performs DNS updates to a remote DNS server on behalf of the Multicast DNS devices on the local network. The difficulty with this is that Multicast DNS devices do not routinely announce their records on the network. Generally, they remain silent until queried. This means that the complete set of Multicast DNS records in use on a link can only be discovered by active querying, not by passive listening. Because of this, a proxy can only know what names exist on a link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names exist and which do not, there is no reasonable way for a proxy to programmatically learn all the answers it would need to push up to the remote DNS server using DNS Update. Even if such a mechanism were possible, it would risk generating high load on the network continuously, even when there are no clients with any interest in that data.
議論されている代替案は、ローカルネットワーク上のマルチキャストDNSデバイスに代わってリモートDNSサーバーへのDNS更新を実行するプロキシです。これの難しさは、マルチキャストDNSデバイスが定期的にネットワーク上のレコードをアナウンスしないことです。一般に、照会されるまでそれらは沈黙します。つまり、リンクで使用されているマルチキャストDNSレコードの完全なセットは、パッシブリスニングではなく、アクティブなクエリによってのみ検出できます。このため、プロキシはクエリを発行することによってリンクに存在する名前のみを知ることができます。存在する名前と存在しない名前を見つけるためにすべての可能な名前に対してクエリを発行することは現実的ではないため、合理的ではありません。プロキシがDNSアップデートを使用してリモートDNSサーバーにプッシュアップするために必要なすべての回答をプログラムで学習する方法。このようなメカニズムが可能であったとしても、そのデータに関心のあるクライアントがいない場合でも、ネットワークに高負荷が継続的に発生するリスクがあります。
Hence, having a model where the query comes to the Discovery Proxy is much more efficient than a model where the Discovery Proxy pushes the answers out to some other remote DNS server.
したがって、クエリがDiscovery Proxyに到達するモデルを使用すると、Discovery Proxyが他のリモートDNSサーバーに回答をプッシュするモデルよりもはるかに効率的です。
A client seeking to discover services and other information performs this by sending traditional DNS queries to the Discovery Proxy or by sending DNS Push Notification subscription requests [RFC8765].
サービスやその他の情報を発見しようとするクライアントは、従来のDNSクエリをDiscovery Proxyに送信するか、DNSプッシュ通知サブスクリプション要求を送信することによってこれを実行します[RFC8765]。
How a client discovers what domain name(s) to use for its DNS-based Service Discovery queries (and, consequently, what Discovery Proxy or Proxies to use) is described in Section 5.2.
クライアントがDNSベースのサービスディスカバリクエリに使用するドメイン名を発見する方法（およびその結果、使用するディスカバリプロキシまたはプロキシ）については、セクション5.2で説明します。
The diagram below illustrates a network topology using a Discovery Proxy to provide discovery service to a remote client.
次の図は、ディスカバリプロキシを使用してリモートクライアントにディスカバリサービスを提供するネットワークトポロジを示しています。
+--------+ Unicast +-----------+ +---------+ +---------+
| Remote | Communication | Discovery | | Network | | Network |
| Client |---- . . . ----| Proxy | | Printer | | Camera |
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
Multicast-capable LAN segment (e.g., Ethernet)
Figure 1: Example Deployment
図1：配置例
Note that there need not be any Discovery Proxy on the link to which the remote client is directly attached. The remote client communicates directly with the Discovery Proxy using normal unicast TCP/IP communication mechanisms, potentially spanning multiple IP hops, possibly including VPN tunnels and other similar long-distance communication channels.
リモートクライアントが直接接続されているリンクにDiscovery Proxyが存在する必要はないことに注意してください。リモートクライアントは、通常のユニキャストTCP / IP通信メカニズムを使用してディスカバリプロキシと直接通信します。複数のIPホップにまたがる可能性があり、VPNトンネルやその他の類似の長距離通信チャネルが含まれる可能性があります。
A Discovery Proxy does not operate as a multicast relay or multicast forwarder. There is no danger of multicast forwarding loops that result in traffic storms, because no multicast packets are forwarded. A Discovery Proxy operates as a _proxy_ for remote clients, performing queries on their behalf and reporting the results back.
ディスカバリプロキシは、マルチキャストリレーまたはマルチキャストフォワーダとして動作しません。マルチキャストパケットが転送されないため、トラフィックストームを引き起こすマルチキャスト転送ループの危険はありません。 Discovery Proxyは、リモートクライアントの_proxy_として動作し、クライアントに代わってクエリを実行し、結果を報告します。
A reasonable analogy is making a telephone call to a colleague at your workplace and saying, "I'm out of the office right now. Would you mind bringing up a printer browser window and telling me the names of the printers you see?" That entails no risk of a forwarding loop causing a traffic storm, because no multicast packets are sent over the telephone call.
合理的な例えは、職場の同僚に電話をかけて、「今オフィスにいません。プリンターのブラウザーウィンドウを開いて、表示されているプリンターの名前を教えていただけませんか？」マルチキャストパケットは電話で送信されないため、転送ループがトラフィックストームを引き起こすリスクはありません。
A similar analogy, instead of enlisting another human being to initiate the service discovery operation on your behalf, is to log in to your own desktop work computer using screen sharing and then run the printer browser yourself to see the list of printers. Or, log in using Secure Shell (ssh) and type "dns-sd -B _ipp._tcp" and observe the list of discovered printer names. In neither case is there any risk of a forwarding loop causing a traffic storm, because no multicast packets are being sent over the screen-sharing or ssh connection.
同様の例えは、別の人間に依頼してサービス検出操作を開始する代わりに、画面共有を使用して自分のデスクトップ作業コンピューターにログインし、自分でプリンターブラウザーを実行してプリンターのリストを表示することです。または、Secure Shell（ssh）を使用してログインし、「dns-sd -B _ipp._tcp」と入力して、検出されたプリンター名のリストを確認します。どちらの場合も、画面共有またはssh接続を介してマルチキャストパケットが送信されていないため、転送ループがトラフィックストームを引き起こすリスクはありません。
The Discovery Proxy provides another way of performing remote queries, which uses a different protocol instead of screen sharing or ssh. The Discovery Proxy mechanism can be thought of as a custom Remote Procedure Call (RPC) protocol that allows a remote client to exercise the Multicast DNS APIs on the Discovery Proxy device, just as a local client running on the Discovery Proxy device would use those APIs.
Discovery Proxyは、リモートクエリを実行する別の方法を提供します。これは、画面共有やsshではなく、異なるプロトコルを使用します。 Discovery Proxyメカニズムは、Discovery Proxyデバイスで実行されているローカルクライアントがそれらのAPIを使用するのと同じように、リモートクライアントがDiscovery ProxyデバイスでマルチキャストDNS APIを実行できるようにするカスタムリモートプロシージャコール（RPC）プロトコルと考えることができます。 。
When the Discovery Proxy software performs Multicast DNS operations, the exact same Multicast DNS caching mechanisms are applied as when any other client software on that Discovery Proxy device performs Multicast DNS operations, regardless of whether that be running a printer browser client locally, a remote user running the printer browser client via a screen-sharing connection, a remote user logged in via ssh running a command-line tool like "dns-sd", or a remote user sending DNS requests that cause a Discovery Proxy to perform discovery operations on its behalf.
Discovery ProxyソフトウェアがマルチキャストDNS操作を実行するとき、プリンターブラウザークライアントをローカルで実行しているかどうか、リモートユーザーに関係なく、そのDiscovery Proxyデバイス上の他のクライアントソフトウェアがマルチキャストDNS操作を実行するときとまったく同じマルチキャストDNSキャッシングメカニズムが適用されます。画面共有接続を介してプリンターブラウザークライアントを実行する、「dns-sd」などのコマンドラインツールを実行するsshを介してログインするリモートユーザー、またはディスカバリープロキシにディスカバリー操作を実行させるDNSリクエストを送信するリモートユーザー代理。
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]で説明されているように解釈されます。
The Discovery Proxy builds on Multicast DNS, which works between hosts on the same link. For the purposes of this document, a set of hosts is considered to be "on the same link" if:
Discovery Proxyは、同じリンク上のホスト間で機能するマルチキャストDNS上に構築されています。このドキュメントでは、次の場合に一連のホストが「同じリンク上にある」と見なされます。
* when any host from that set sends a packet to any other host in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified, and
* そのセットのいずれかのホストが、ユニキャスト、マルチキャスト、またはブロードキャストを使用して、そのセット内の他のホストにパケットを送信すると、リンク層パケットペイロード全体が変更されずに到着します。
* a broadcast sent over that link, by any host from that set of hosts, can be received by every other host in that set.
* ホストのセットからの任意のホストによってそのリンクを介して送信されたブロードキャストは、そのセット内の他のすべてのホストによって受信できます。
The link-layer _header_ may be modified, such as in Token Ring Source Routing [IEEE-5], but not the link-layer _payload_. In particular, if any device forwarding a packet modifies any part of the IP header or IP payload, then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as repeaters, bridges, hubs, or switches and still be considered to be on the same link for the purpose of this document, but not through a device such as an IP router that decrements the IP TTL or otherwise modifies the IP header.
リンク層_header_は、トークンリングソースルーティング[IEEE-5]などで変更できますが、リンク層_payload_では変更できません。特に、パケットを転送するデバイスがIPヘッダーまたはIPペイロードの一部を変更した場合、そのパケットは同じリンク上にあるとは見なされなくなります。つまり、パケットはリピーター、ブリッジ、ハブ、スイッチなどのデバイスを通過しても、このドキュメントでは同じリンク上にあると見なされますが、IPルーターなどのIPを減少させるデバイスは通過しません。 TTLまたはその他の方法でIPヘッダーを変更します。
No changes to existing devices are required to work with a Discovery Proxy.
Discovery Proxyを使用するために既存のデバイスを変更する必要はありません。
Existing devices that advertise services using Multicast DNS work with a Discovery Proxy.
マルチキャストDNSを使用してサービスをアドバタイズする既存のデバイスは、ディスカバリプロキシで動作します。
Existing clients that support DNS-based Service Discovery over Unicast DNS work with a Discovery Proxy. DNS-based Service Discovery over Unicast DNS was introduced in Mac OS X 10.4 Tiger in April 2005 and has been included in Apple products introduced since then, including the iPhone and iPad. It has also been included in products from other vendors, such as Microsoft Windows 10.
ユニキャストDNSを介したDNSベースのサービスディスカバリをサポートする既存のクライアントは、ディスカバリプロキシと連携します。ユニキャストDNSを介したDNSベースのサービスディスカバリは、2005年4月にMac OS X 10.4 Tigerで導入され、それ以降、iPhoneやiPadを含むApple製品に含まれています。また、Microsoft Windows 10など、他のベンダーの製品にも含まれています。
An overview of the larger collection of associated DNS-based Service Discovery technologies, and how the Discovery Proxy technology relates to those, is given in the Service Discovery Road Map document [ROADMAP].
関連するDNSベースのサービスディスカバリテクノロジーのより大きなコレクションの概要、およびディスカバリプロキシテクノロジーがそれらにどのように関連するかは、サービスディスカバリロードマップドキュメント[ROADMAP]に記載されています。
In a typical configuration, a Discovery Proxy is configured to be authoritative [RFC1034] [RFC1035] for four or more DNS subdomains, listed below. Authority for these subdomains is delegated from the parent domain to the Discovery Proxy in the usual way for DNS delegation, via NS records.
一般的な構成では、ディスカバリプロキシは、以下にリストされている4つ以上のDNSサブドメインに対して権威を持つ[RFC1034] [RFC1035]になるように構成されます。これらのサブドメインの権限は、NSレコードを介して、DNS委任の通常の方法で親ドメインからDiscovery Proxyに委任されます。
A DNS subdomain for DNS-based Service Discovery records. This subdomain name may contain rich text, including spaces and other punctuation. This is because this subdomain name is used only in graphical user interfaces, where rich text is appropriate.
DNSベースのサービス検出レコードのDNSサブドメイン。このサブドメイン名には、スペースやその他の句読点を含むリッチテキストが含まれる場合があります。これは、このサブドメイン名がリッチテキストが適切なグラフィカルユーザーインターフェイスでのみ使用されるためです。
A DNS subdomain for host name records. This subdomain name SHOULD be limited to letters, digits, and hyphens in order to facilitate the convenient use of host names in command-line interfaces.
ホスト名レコードのDNSサブドメイン。コマンドラインインターフェイスでホスト名を簡単に使用できるようにするため、このサブドメイン名は文字、数字、ハイフンに限定する必要があります。
One or more DNS subdomains for IPv4 Reverse Mapping records. These subdomains will have names that end in "in-addr.arpa".
IPv4リバースマッピングレコードの1つ以上のDNSサブドメイン。これらのサブドメインの名前は「in-addr.arpa」で終わります。
One or more DNS subdomains for IPv6 Reverse Mapping records. These subdomains will have names that end in "ip6.arpa".
IPv6リバースマッピングレコードの1つ以上のDNSサブドメイン。これらのサブドメインの名前は「ip6.arpa」で終わります。
In an enterprise network, the naming and delegation of these subdomains is typically performed by conscious action of the network administrator. In a home network, naming and delegation would typically be performed using some automatic configuration mechanism such as Home Networking Control Protocol (HNCP) [RFC7788].
企業ネットワークでは、これらのサブドメインの命名と委任は、通常、ネットワーク管理者の意識的な行動によって行われます。ホームネットワークでは、名前付けと委任は通常、ホームネットワーク制御プロトコル（HNCP）[RFC7788]などの自動構成メカニズムを使用して実行されます。
These three varieties of delegated subdomains (service discovery, host names, and reverse mapping) are described below in Sections 5.1, 5.3, and 5.4.
これらの3種類の委任サブドメイン（サービス検出、ホスト名、および逆マッピング）については、以下のセクション5.1、5.3、および5.4で説明します。
How a client discovers where to issue its DNS-based Service Discovery queries is described in Section 5.2.
クライアントがDNSベースのサービスディスカバリクエリを発行する場所を検出する方法については、セクション5.2で説明しています。
In its simplest form, each link in an organization is assigned a unique Unicast DNS domain name such as "Building 1.example.com" or "2nd Floor.Building 3.example.com". Grouping multiple links under a single Unicast DNS domain name is to be specified in a future companion document, but for the purposes of this document, assume that each link has its own unique Unicast DNS domain name. In a graphical user interface these names are not displayed as strings with dots as shown above, but something more akin to a typical file browser graphical user interface (which is harder to illustrate in a text-only document) showing folders, subfolders, and files in a file system.
最も単純な形式では、組織内の各リンクには、「Building 1.example.com」や「2nd Floor.Building 3.example.com」などの一意のユニキャストDNSドメイン名が割り当てられます。単一のユニキャストDNSドメイン名の下に複数のリンクをグループ化することは、将来の関連ドキュメントで指定される予定ですが、このドキュメントでは、各リンクに独自の一意のユニキャストDNSドメイン名があると想定します。グラフィカルユーザーインターフェイスでは、これらの名前は上記のようにドットの付いた文字列として表示されませんが、フォルダー、サブフォルダー、ファイルを表示する一般的なファイルブラウザーのグラフィカルユーザーインターフェイス（テキストのみのドキュメントではわかりにくい）に似ています。ファイルシステム内。
+---------------+--------------+-------------+-------------------+
| *example.com* | Building 1 | 1st Floor | Alice's printer |
| | Building 2 | *2nd Floor* | Bob's printer |
| | *Building 3* | 3rd Floor | Charlie's printer |
| | Building 4 | 4th Floor | |
| | Building 5 | | |
| | Building 6 | | |
+---------------+--------------+-------------+-------------------+
Figure 2: Illustrative GUI
図2：実例となるGUI
Each named link in an organization has one or more Discovery Proxies that serve it. This Discovery Proxy function could be performed by a device like a router or switch that is physically attached to that link. In the parent domain, NS records are used to delegate ownership of each defined link name (e.g., "Building 1.example.com") to one or more Discovery Proxies that serve the named link. In other words, the Discovery Proxies are the authoritative name servers for that subdomain. As in the rest of DNS-based Service Discovery, all names are represented as-is using plain UTF-8 encoding and, as described in Section 5.5.4, no text-encoding translations are performed.
組織内の各名前付きリンクには、それを処理する1つ以上のディスカバリープロキシがあります。このDiscovery Proxy機能は、そのリンクに物理的に接続されているルーターやスイッチなどのデバイスによって実行できます。親ドメインでは、NSレコードを使用して、定義された各リンク名（「Building 1.example.com」など）の所有権を、指定されたリンクを提供する1つ以上のディスカバリープロキシに委任します。つまり、ディスカバリプロキシは、そのサブドメインの権威ネームサーバーです。他のDNSベースのサービスディスカバリと同様に、すべての名前はそのままUTF-8エンコーディングを使用して表され、セクション5.5.4で説明されているように、テキストエンコーディング変換は実行されません。
With appropriate VLAN configuration [IEEE-1Q], a single Discovery Proxy device could have a logical presence on many links and serve as the Discovery Proxy for all those links. In such a configuration, the Discovery Proxy device would have a single physical Ethernet [IEEE-3] port, configured as a VLAN trunk port, which would appear to software on that device as multiple virtual Ethernet interfaces, one connected to each of the VLAN links.
適切なVLAN構成[IEEE-1Q]を使用すると、単一のDiscovery Proxyデバイスが多くのリンクに論理的に存在し、それらすべてのリンクのDiscovery Proxyとして機能できます。このような構成では、Discovery Proxyデバイスには、VLANトランクポートとして構成された単一の物理イーサネット[IEEE-3]ポートがあり、そのデバイス上のソフトウェアからは、各VLANに接続された複数の仮想イーサネットインターフェイスとして認識されます。リンク。
As an alternative to using VLAN technology, using a Multicast DNS Discovery Relay [RELAY] is another way that a Discovery Proxy can have a "virtual" presence on a remote link.
VLANテクノロジーを使用する代わりに、マルチキャストDNSディスカバリリレー[RELAY]を使用することは、ディスカバリプロキシがリモートリンク上に「仮想」プレゼンスを持つことができる別の方法です。
When a DNS-SD client issues a Unicast DNS query to discover services in a particular Unicast DNS subdomain (e.g., "_ipp._tcp.Building 1.example.com. PTR ?"), the normal DNS delegation mechanism results in that query being forwarded until it reaches the delegated authoritative name server for that subdomain, namely, the Discovery Proxy on the link in question. Like a conventional Unicast DNS server, a Discovery Proxy implements the usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP. However, unlike a conventional Unicast DNS server that generates answers from the data in its manually configured zone file, a Discovery Proxy learns answers using Multicast DNS. A Discovery Proxy does this by consulting its Multicast DNS cache and/or issuing Multicast DNS queries, as appropriate according to the usual protocol rules of Multicast DNS [RFC6762], for the corresponding Multicast DNS name, type, and class, with the delegated zone part of the name replaced with ".local" (e.g., in this case, "_ipp._tcp.local. PTR ?"). Then, from the received Multicast DNS data, the Discovery Proxy synthesizes the appropriate Unicast DNS response, with the ".local" top-level label of the owner name replaced with the name of the delegated zone. Further details of the name translation rules are described in Section 5.5. Rules specifying how long the Discovery Proxy should wait to accumulate Multicast DNS responses before sending its unicast reply are described in Section 5.6.
DNS-SDクライアントがユニキャストDNSクエリを発行して特定のユニキャストDNSサブドメイン（たとえば、「_ ipp._tcp.Building 1.example.com。PTR？」）のサービスを検出すると、通常のDNS委任メカニズムにより、そのクエリは次のようになります。そのサブドメインの委任された権威あるネームサーバー、つまり問題のリンク上のDiscovery Proxyに到達するまで転送されます。従来のユニキャストDNSサーバーと同様に、ディスカバリープロキシは、UDPおよびTCPを介して通常のユニキャストDNSプロトコル[RFC1034] [RFC1035]を実装します。ただし、手動で構成されたゾーンファイルのデータから回答を生成する従来のユニキャストDNSサーバーとは異なり、ディスカバリープロキシはマルチキャストDNSを使用して回答を学習します。ディスカバリプロキシは、対応するマルチキャストDNSの名前、タイプ、およびクラスについて、マルチキャストDNS [RFC6762]の通常のプロトコルルールに応じて、マルチキャストDNSキャッシュを調べたり、マルチキャストDNSクエリを発行したりして、これを行います。名前の一部を ".local"で置き換えます（この場合、 "_ ipp._tcp.local。PTR？"など）。次に、検出プロキシは受信したマルチキャストDNSデータから、所有者名の「.local」トップレベルラベルを委任されたゾーンの名前に置き換えて、適切なユニキャストDNS応答を合成します。名前変換ルールの詳細については、セクション5.5で説明します。ディスカバリプロキシがユニキャスト応答を送信する前にマルチキャストDNS応答を蓄積するまで待機する時間を指定するルールについては、セクション5.6で説明しています。
The existing Multicast DNS caching mechanism is used to minimize unnecessary Multicast DNS queries on the wire. The Discovery Proxy is acting as a client of the underlying Multicast DNS subsystem and benefits from the same caching and efficiency measures as any other client using that subsystem.
既存のマルチキャストDNSキャッシングメカニズムは、ネットワーク上の不要なマルチキャストDNSクエリを最小限に抑えるために使用されます。 Discovery Proxyは、基盤となるマルチキャストDNSサブシステムのクライアントとして機能し、そのサブシステムを使用する他のクライアントと同じキャッシングと効率の測定から恩恵を受けます。
Note that the contents of the delegated zone, generated as it is by performing ".local" Multicast DNS queries, mirrors the records available on the local link via Multicast DNS very closely, but not precisely. There is not a full bidirectional equivalence between the two. Certain records that are available via Multicast DNS may not have equivalents in the delegated zone possibly because they are invalid or not relevant in the delegated zone or because they are being suppressed because they are unusable outside the local link (see Section 5.5.2). Conversely, certain records that appear in the delegated zone may not have corresponding records available on the local link via Multicast DNS. In particular, there are certain administrative SRV records (see Section 6) that logically fall within the delegated zone but semantically represent metadata _about_ the zone rather than records _within_ the zone. Consequently, these administrative records in the delegated zone do not have any corresponding counterparts in the Multicast DNS namespace of the local link.
「.local」マルチキャストDNSクエリを実行することによって生成された委任されたゾーンの内容は、マルチキャストDNSを介してローカルリンクで利用可能なレコードを非常に厳密にミラーリングしますが、正確ではないことに注意してください。 2つの間に完全な双方向の等価性はありません。マルチキャストDNSを介して利用できる特定のレコードは、委任されたゾーンでは無効であるか関連がないため、またはローカルリンクの外では使用できないために抑制されているため、委任されたゾーンで同等のレコードがない場合があります（セクション5.5.2を参照）。逆に、委任されたゾーンに表示される特定のレコードには、マルチキャストDNS経由のローカルリンクで利用可能な対応するレコードがない場合があります。特に、委任されたゾーンに論理的に分類されるが、意味的にはゾーン内のレコードではなくゾーンについてメタデータを意味的に表す特定の管理SRVレコード（セクション6を参照）があります。したがって、委任されたゾーンのこれらの管理レコードには、ローカルリンクのマルチキャストDNS名前空間に対応する対応するレコードがありません。
A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR queries, using both unicast and multicast.
DNS-SDクライアントは、ユニキャストとマルチキャストの両方を使用して、特定のPTRクエリを介してドメイン列挙[RFC6763]を実行します。
If a DNS-SD client receives a Domain Name configuration via DHCP then it issues unicast queries derived from this domain name. It also issues unicast queries using names derived from its IPv4 subnet address(es) and IPv6 prefix(es). These unicast Domain Enumeration queries are described in Section 5.2.1. A DNS-SD client also issues multicast Domain Enumeration queries in the "local" domain [RFC6762], as described in Section 5.2.2. The results of all the Domain Enumeration queries are combined for DNS-based Service Discovery purposes.
DNS-SDクライアントがDHCP経由でドメイン名構成を受信すると、このドメイン名から派生したユニキャストクエリを発行します。また、IPv4サブネットアドレスとIPv6プレフィックスから派生した名前を使用してユニキャストクエリを発行します。これらのユニキャストドメイン列挙クエリについては、セクション5.2.1で説明します。セクション5.2.2で説明されているように、DNS-SDクライアントは、「ローカル」ドメイン[RFC6762]でマルチキャストドメイン列挙クエリも発行します。すべてのドメイン列挙クエリの結果は、DNSベースのサービス検出のために結合されます。
The (human or automated) administrator creates Unicast DNS Domain Enumeration PTR records [RFC6763] to inform clients of available service discovery domains. Two varieties of such Unicast DNS Domain Enumeration PTR records exist: those with names derived from the domain name communicated to the clients via DHCP option 15 [RFC2132], and those with names derived from either IPv4 subnet address(es) or IPv6 prefix(es) in use by the clients. Below is an example showing the name-based variety, where the DHCP server configured the client with the domain name "example.com":
（人間または自動化された）管理者は、ユニキャストDNSドメイン列挙PTRレコード[RFC6763]を作成して、クライアントに利用可能なサービス検出ドメインを通知します。このようなユニキャストDNSドメイン列挙PTRレコードには2種類あります。DHCPオプション15 [RFC2132]を介してクライアントに通知されたドメイン名から派生した名前を持つレコードと、IPv4サブネットアドレスまたはIPv6プレフィックスから派生した名前を持つレコードです。 ）クライアントが使用中。以下は、名前ベースの種類を示す例です。DHCPサーバーは、ドメイン名 "example.com"でクライアントを構成しています。
b._dns-sd._udp.example.com. PTR Building 1.example.com. PTR Building 2.example.com. PTR Building 3.example.com. PTR Building 4.example.com.
b._dns-sd._udp.example.com。 PTR Building 1.example.com。 PTR Building 2.example.com。 PTR Building 3.example.com。 PTR Building 4.example.com。
db._dns-sd._udp.example.com. PTR Building 1.example.com.
db._dns-sd._udp.example.com。 PTR Building 1.example.com。
lb._dns-sd._udp.example.com. PTR Building 1.example.com.
lb._dns-sd._udp.example.com。 PTR Building 1.example.com。
The meaning of these records is defined in the DNS-based Service Discovery specification [RFC6763] but, for convenience, is repeated here. The "b" ("browse") records tell the client device the list of browsing domains to display for the user to select from. The "db" ("default browse") record tells the client device which domain in that list should be selected by default. The "db" domain MUST be one of the domains in the "b" list; if not, then no domain is selected by default. The "lb" ("legacy browse") record tells the client device which domain to automatically browse on behalf of applications that don't implement user interface for multi-domain browsing (which is most of them at the time of writing). The "lb" domain is often the same as the "db" domain, or sometimes the "db" domain plus one or more others that should be included in the list of automatic browsing domains for legacy clients.
これらのレコードの意味は、DNSベースのサービスディスカバリ仕様[RFC6763]で定義されていますが、便宜上、ここで繰り返します。 "b"（ "browse"）レコードは、ユーザーが選択するために表示するブラウジングドメインのリストをクライアントデバイスに通知します。 「db」（「デフォルトの参照」）レコードは、そのリストのどのドメインをデフォルトで選択する必要があるかをクライアントデバイスに通知します。 「db」ドメインは、「b」リストのドメインの1つでなければなりません。そうでない場合、デフォルトではドメインは選択されていません。 「lb」（「レガシーブラウズ」）レコードは、マルチドメインブラウジングのユーザーインターフェースを実装していないアプリケーションに代わって自動的にブラウジングするドメインをクライアントデバイスに通知します（執筆時点ではほとんど）。 「lb」ドメインは、「db」ドメインと同じである場合が多く、「db」ドメインと、レガシークライアントの自動ブラウジングドメインのリストに含める必要のある1つ以上の他のドメインと同じ場合もあります。
Note that in the example above, for clarity, space characters in names are shown as actual spaces. If this data is manually entered into a textual zone file for authoritative server software such as BIND, care must be taken because the space character is used as a field separator, and other characters like dot ('.'), semicolon (';'), dollar ('$'), backslash ('\'), etc., also have special meaning. These characters have to be escaped when entered into a textual zone file, following the rules in Section 5.1 of the DNS specification [RFC1035]. For example, a literal space in a name is represented in the textual zone file using '\032', so "Building 1.example.com" is entered as "Building\0321.example.com".
上記の例では、わかりやすくするために、名前のスペース文字は実際のスペースとして示されていることに注意してください。このデータをBINDなどの信頼できるサーバーソフトウェアのテキストゾーンファイルに手動で入力する場合は、スペース文字がフィールドセパレーターとして使用され、ドット（ '。'）、セミコロン（ ';'など）が使用されるため、注意が必要です。 ）、ドル（ '$'）、バックスラッシュ（ '\'）なども特別な意味を持っています。これらの文字は、DNS仕様[RFC1035]のセクション5.1のルールに従って、テキストゾーンファイルに入力するときにエスケープする必要があります。たとえば、名前のリテラルスペースは「\ 032」を使用してテキストゾーンファイルで表されるため、「Building 1.example.com」は「Building \ 0321.example.com」として入力されます。
DNS responses are limited to a maximum size of 65535 bytes. This limits the maximum number of domains that can be returned for a Domain Enumeration query as follows:
DNS応答の最大サイズは65535バイトに制限されています。これにより、ドメイン列挙クエリで返されるドメインの最大数が次のように制限されます。
A DNS response header is 12 bytes. That's typically followed by a single qname (up to 256 bytes) plus qtype (2 bytes) and qclass (2 bytes), leaving 65275 for the Answer Section.
DNS応答ヘッダーは12バイトです。通常、その後に単一のqname（最大256バイト）とqtype（2バイト）およびqclass（2バイト）が続き、回答セクションには65275が残ります。
An Answer Section Resource Record consists of:
アンサーセクションリソースレコードは、次のもので構成されます。
* Owner name, encoded as a compression pointer, 2 bytes * RRTYPE (type PTR), 2 bytes * RRCLASS (class IN), 2 bytes * TTL, 4 bytes * RDLENGTH, 2 bytes * RDATA (domain name), up to 256 bytes
* 所有者名、圧縮ポインターとしてエンコード、2バイト* RRTYPE（タイプPTR）、2バイト* RRCLASS（クラスIN）、2バイト* TTL、4バイト* RDLENGTH、2バイト* RDATA（ドメイン名）、最大256バイト
This means that each Resource Record in the Answer Section can take up to 268 bytes total, which means that the Answer Section can contain, in the worst case, no more than 243 domains.
つまり、回答セクションの各リソースレコードは合計で最大268バイトを使用できます。つまり、回答セクションには、最悪の場合、243ドメインまでしか含めることができません。
In a more typical scenario, where the domain names are not all maximum-sized names, and there is some similarity between names so that reasonable name compression is possible, each Answer Section Resource Record may average 140 bytes, which means that the Answer Section can contain up to 466 domains.
ドメイン名がすべて最大サイズの名前ではなく、合理的な名前の圧縮が可能になるように名前間にある程度の類似性がある、より一般的なシナリオでは、各回答セクションのリソースレコードは平均140バイトになる可能性があります。最大466のドメインを含みます。
It is anticipated that this should be sufficient for even a large corporate network or university campus.
これは、大規模な企業ネットワークや大学のキャンパスでも十分なはずです。
In the case where Discovery Proxy functionality is widely deployed within an enterprise (either by having a Discovery Proxy physically on each link, or by having a Discovery Proxy with a remote "virtual" presence on each link using VLANs or Multicast DNS Discovery Relays [RELAY]), this offers an additional way to provide Domain Enumeration configuration data for clients.
ディスカバリープロキシ機能が企業内で広く展開されている場合（各リンクにディスカバリープロキシを物理的に配置するか、VLANまたはマルチキャストDNSディスカバリーリレーを使用して各リンクにリモートの「仮想」プレゼンスを持つディスカバリープロキシを配置することによって[リレー] ]）、これはクライアントにドメイン列挙構成データを提供する追加の方法を提供します。
Note that this function of the Discovery Proxy is supplementary to the primary purpose of the Discovery Proxy, which is to facilitate _remote_ clients discovering services on the Discovery Proxy's local link. This publication of Domain Enumeration configuration data via link-local multicast on the Discovery Proxy's local link is performed for the benefit of _local_ clients attached to that link, and typically directs those clients to contact other distant Discovery Proxies attached to other links. Generally, a client does not need to use the local Discovery Proxy on its own link, because a client is generally able to perform its own Multicast DNS queries on that link. (The exception to this is when the local Wi-Fi access point is blocking or filtering local multicast traffic, requiring even local clients to use their local Discovery Proxy to perform local discovery.)
Discovery Proxyのこの機能は、Discovery Proxyの主な目的を補足するものであることに注意してください。これは、_remote_クライアントがDiscovery Proxyのローカルリンクでサービスを発見するのを容易にすることです。このDiscovery Proxyのローカルリンクでのリンクローカルマルチキャストによるドメイン列挙構成データの公開は、そのリンクに接続されている_local_クライアントの利益のために実行され、通常、これらのクライアントに、他のリンクに接続されている他の遠方のDiscoveryプロキシに接続するように指示します。一般に、クライアントはそのリンクで独自のマルチキャストDNSクエリを実行できるため、クライアントは独自のリンクでローカルのDiscovery Proxyを使用する必要はありません。 （これの例外は、ローカルWi-Fiアクセスポイントがローカルマルチキャストトラフィックをブロックまたはフィルタリングしている場合で、ローカルクライアントでさえ、ローカルディスカバリプロキシを使用してローカルディスカバリを実行する必要があります。）
A Discovery Proxy can be configured to generate Multicast DNS responses for the following Multicast DNS Domain Enumeration queries issued by clients:
検出プロキシは、クライアントが発行した次のマルチキャストDNSドメイン列挙クエリに対してマルチキャストDNS応答を生成するように構成できます。
b._dns-sd._udp.local. PTR ? db._dns-sd._udp.local. PTR ? lb._dns-sd._udp.local. PTR ?
b._dns-sd._udp.local。 PTR？ db._dns-sd._udp.local。 PTR？ lb._dns-sd._udp.local。 PTR？
This provides the ability for Discovery Proxies to indicate recommended browsing domains to DNS-SD clients on a per-link granularity. In some enterprises, it may be preferable to provide this per-link configuration information in the form of Discovery Proxy configuration data rather than by populating the Unicast DNS servers with the same data (in the "ip6.arpa" or "in-addr.arpa" domains).
これにより、ディスカバリープロキシは、推奨されるブラウジングドメインをリンクごとの粒度でDNS-SDクライアントに示すことができます。一部の企業では、このリンクごとの構成情報を、ユニキャストDNSサーバーに同じデータ（「ip6.arpa」または「in-addr。」に入力するのではなく、Discovery Proxy構成データの形式で提供することが望ましい場合があります。 arpa」ドメイン）。
Regardless of how the network operator chooses to provide this configuration data, clients will perform Domain Enumeration via both unicast and multicast queries and then combine the results of these queries.
ネットワークオペレーターがこの構成データを提供することを選択した方法に関係なく、クライアントはユニキャストクエリとマルチキャストクエリの両方を介してドメイン列挙を実行し、これらのクエリの結果を結合します。
DNS-SD service instance names and domains are allowed to contain arbitrary Net-Unicode text [RFC5198], encoded as precomposed UTF-8 [RFC3629].
DNS-SDサービスのインスタンス名とドメインには、事前に構成されたUTF-8 [RFC3629]としてエンコードされた任意のNet-Unicodeテキスト[RFC5198]を含めることができます。
Users typically interact with service discovery software by viewing a list of discovered service instance names on a display and selecting one of them by pointing, touching, or clicking. Similarly, in software that provides a multi-domain DNS-SD user interface, users view a list of offered domains on the display and select one of them by pointing, touching, or clicking. To use a service, users don't have to remember domain or instance names, or type them; users just have to be able to recognize what they see on the display and touch or click on the thing they want.
ユーザーは通常、ディスカバーされたサービスインスタンス名のリストをディスプレイに表示し、それらのいずれかをポイント、タッチ、またはクリックして選択することにより、サービスディスカバリソフトウェアと対話します。同様に、マルチドメインDNS-SDユーザーインターフェイスを提供するソフトウェアでは、ユーザーは提供されたドメインのリストをディスプレイに表示し、ポイント、タッチ、またはクリックすることでドメインの1つを選択します。サービスを使用するために、ユーザーはドメイン名やインスタンス名を覚えたり、入力したりする必要はありません。ユーザーは、ディスプレイに表示されているものを認識し、必要なものをタッチまたはクリックする必要があります。
In contrast, host names are often remembered and typed. Also, host names have historically been used in command-line interfaces where spaces can be inconvenient. For this reason, host names have traditionally been restricted to letters, digits, and hyphens (LDH) with no spaces or other punctuation.
対照的に、ホスト名はしばしば記憶され、入力されます。また、ホスト名は、スペースが不便なコマンドラインインターフェイスで使用されてきました。このため、ホスト名は従来、スペースやその他の句読点のない文字、数字、ハイフン（LDH）に制限されていました。
While we do want to allow rich text for DNS-SD service instance names and domains, it is advisable, for maximum compatibility with existing usage, to restrict host names to the traditional letter-digit-hyphen rules. This means that while the service name "My Printer._ipp._tcp.Building 1.example.com" is acceptable and desirable (it is displayed in a graphical user interface as an instance called "My Printer" in the domain "Building 1" at "example.com"), the host name "My-Printer.Building 1.example.com" is less desirable (because of the space in "Building 1").
DNS-SDサービスのインスタンス名とドメインのリッチテキストを許可したいのですが、既存の使用法との互換性を最大にするために、ホスト名を従来の文字桁ハイフンルールに制限することをお勧めします。これは、サービス名「My Printer._ipp._tcp.Building 1.example.com」は受け入れ可能で望ましいものですが、ドメイン「Building 1」の「My Printer」というインスタンスとしてグラフィカルユーザーインターフェイスに表示されます。 「example.com」で）、ホスト名「My-Printer.Building 1.example.com」はあまり望ましくありません（「Building 1」のスペースのため）。
To accommodate this difference in allowable characters, a Discovery Proxy SHOULD support having two separate subdomains delegated to it for each link it serves: one whose name is allowed to contain arbitrary Net-Unicode text [RFC5198], and a second more constrained subdomain whose name is restricted to contain only letters, digits, and hyphens, to be used for host name records (names of 'A' and 'AAAA' address records). The restricted names may be any valid name consisting of only letters, digits, and hyphens, including Punycode-encoded names [RFC3492].
この許容文字の違いに対応するために、Discovery Proxyは、サービスを提供するリンクごとに委任された2つの別々のサブドメインをサポートする必要があります（SHOULD）。ホスト名レコード（「A」および「AAAA」アドレスレコードの名前）に使用される文字、数字、およびハイフンのみを含むように制限されています。制限された名前は、Punycodeでエンコードされた名前[RFC3492]を含む、文字、数字、ハイフンのみで構成される有効な名前です。
For example, a Discovery Proxy could have the two subdomains "Building 1.example.com" and "bldg-1.example.com" delegated to it. The Discovery Proxy would then translate these two Multicast DNS records:
たとえば、Discovery Proxyには、2つのサブドメイン「Building 1.example.com」と「bldg-1.example.com」を委任することができます。次に、Discovery Proxyはこれらの2つのマルチキャストDNSレコードを変換します。
My Printer._ipp._tcp.local. SRV 0 0 631 prnt.local. prnt.local. A 203.0.113.2
私のPrinter._ipp._tcp.local。 SRV 0 0 631 prnt.local。 prnt.local。 A 203.0.113.2
into Unicast DNS records as follows:
次のようにユニキャストDNSレコードに変換します。
My Printer._ipp._tcp.Building 1.example.com. SRV 0 0 631 prnt.bldg-1.example.com. prnt.bldg-1.example.com. A 203.0.113.2
My Printer._ipp._tcp.Building 1.example.com。 SRV 0 0 631 prnt.bldg-1.example.com。 prnt.bldg-1.example.com。 A 203.0.113.2
Note that the SRV record name is translated using the rich-text domain name ("Building 1.example.com"), and the address record name is translated using the LDH domain ("bldg-1.example.com"). Further details of the name translation rules are described in Section 5.5.
SRVレコード名はリッチテキストドメイン名（ "Building 1.example.com"）を使用して変換され、アドレスレコード名はLDHドメイン（ "bldg-1.example.com"）を使用して変換されることに注意してください。名前変換ルールの詳細については、セクション5.5で説明します。
A Discovery Proxy MAY support only a single rich-text Net-Unicode domain and use that domain for all records, including 'A' and 'AAAA' address records, but implementers choosing this option should be aware that this choice may produce host names that are awkward to use in command-line environments. Whether or not this is an issue depends on whether users in the target environment are expected to be using command-line interfaces.
Discovery Proxyは単一のリッチテキストNet-Unicodeドメインのみをサポートし、「A」および「AAAA」アドレスレコードを含むすべてのレコードにそのドメインを使用できますが、このオプションを選択する実装者は、この選択により、コマンドライン環境で使用するのは面倒です。これが問題であるかどうかは、ターゲット環境のユーザーがコマンドラインインターフェイスを使用することが期待されているかどうかによって異なります。
A Discovery Proxy MUST NOT be restricted to support only a letter-digit-hyphen subdomain, because that results in an unnecessarily poor user experience.
ディスカバリープロキシは、文字、数字、ハイフンのサブドメインのみをサポートするように制限してはなりません。これは、ユーザーエクスペリエンスが不必要に低下するためです。
As described in Section 5.2.1, for clarity, in examples here space characters in names are shown as actual spaces. If this dynamically discovered data were to be manually entered into a textual zone file (which it isn't), then spaces would need to be represented using '\032', so "My Printer._ipp._tcp.Building 1.example.com" would become "My\032Printer._ipp._tcp.Building\0321.example.com".
セクション5.2.1で説明したように、わかりやすくするために、ここでは例の名前のスペース文字を実際のスペースとして示しています。この動的に検出されたデータをテキストゾーンファイルに手動で入力する場合（そうではありません）、スペースは「\ 032」を使用して表す必要があるため、「My Printer._ipp._tcp.Building 1.example。 com」は「My \ 032Printer._ipp._tcp.Building \ 0321.example.com」になります。
Note that the '\032' representation does not appear in DNS messages sent over the air. In the wire format of DNS messages, spaces are sent as spaces, not as '\032', and likewise, in a graphical user interface at the client device, spaces are shown as spaces, not as '\032'.
「\ 032」の表記は、無線で送信されるDNSメッセージには表示されないことに注意してください。 DNSメッセージのワイヤー形式では、スペースは「\ 032」ではなくスペースとして送信されます。同様に、クライアントデバイスのグラフィカルユーザーインターフェイスでは、スペースは「\ 032」ではなくスペースとして表示されます。
A Discovery Proxy can facilitate easier management of reverse mapping domains, particularly for IPv6 addresses where manual management may be more onerous than it is for IPv4 addresses.
ディスカバリープロキシは、特にIPv4アドレスよりも手動での管理が煩わしいIPv6アドレスの場合、リバースマッピングドメインの管理を容易にすることができます。
To achieve this, in the parent domain, NS records are used to delegate ownership of the appropriate reverse mapping domain to the Discovery Proxy. In other words, the Discovery Proxy becomes the authoritative name server for the reverse mapping domain. For fault tolerance reasons, there may be more than one Discovery Proxy serving a given link.
これを実現するために、親ドメインでは、NSレコードを使用して、適切な逆マッピングドメインの所有権をDiscovery Proxyに委任します。つまり、Discovery Proxyは、逆マッピングドメインの権威ネームサーバーになります。フォールトトレランスの理由から、特定のリンクを提供する複数のDiscovery Proxyが存在する場合があります。
If a given link is using the IPv4 subnet 203.0.113/24, then the domain "113.0.203.in-addr.arpa" is delegated to the Discovery Proxy for that link.
特定のリンクがIPv4サブネット203.0.113 / 24を使用している場合、ドメイン「113.0.203.in-addr.arpa」はそのリンクのディスカバリープロキシに委任されます。
If a given link is using the IPv6 prefix 2001:0DB8:1234:5678::/64, then the domain "8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa" is delegated to the Discovery Proxy for that link.
特定のリンクがIPv6プレフィックス2001：0DB8：1234：5678 :: / 64を使用している場合、ドメイン「8.7.6.5.4.3.2.1.8.bd0.1.0.0.2.ip6.arpa」は、そのリンクのディスカバリプロキシ。
When a reverse mapping query arrives at the Discovery Proxy, it issues the identical query on its local link, as a Multicast DNS query. The mechanism to force an apparently unicast name to be resolved using link-local Multicast DNS varies depending on the API set being used. For example, in the "dns_sd.h" APIs (available on macOS, iOS, Bonjour for Windows, Linux, and Android), using kDNSServiceFlagsForceMulticast indicates that the DNSServiceQueryRecord() call should perform the query using Multicast DNS. Other API sets have different ways of forcing multicast queries. When the host owning that IPv4 or IPv6 address responds with a name of the form "something.local", the Discovery Proxy rewrites it to use its configured LDH host name domain instead of ".local" and returns the response to the caller.
逆マッピングクエリがディスカバリプロキシに到着すると、マルチキャストDNSクエリとしてローカルリンクに同じクエリを発行します。リンクローカルマルチキャストDNSを使用して明らかにユニキャスト名を解決するメカニズムは、使用されているAPIセットによって異なります。たとえば、「dns_sd.h」API（macOS、iOS、Windows、Linux、AndroidのBonjourで利用可能）でkDNSServiceFlagsForceMulticastを使用すると、DNSServiceQueryRecord()呼び出しがマルチキャストDNSを使用してクエリを実行する必要があることを示します。他のAPIセットには、マルチキャストクエリを強制するさまざまな方法があります。そのIPv4またはIPv6アドレスを所有するホストが「something.local」の形式の名前で応答すると、ディスカバリプロキシは「.local」の代わりに設定済みのLDHホスト名ドメインを使用するようにホストを書き換え、応答を呼び出し元に返します。
For example, a Discovery Proxy with the two subdomains "113.0.203.in-addr.arpa" and "bldg-1.example.com" delegated to it would translate this Multicast DNS record:
たとえば、2つのサブドメイン「113.0.203.in-addr.arpa」と「bldg-1.example.com」に委任されたDiscovery Proxyは、このマルチキャストDNSレコードを変換します。
2.113.0.203.in-addr.arpa. PTR prnt.local.
2.113.0.203.in-addr.arpa。 PTR prnt.local。
into this Unicast DNS response:
このユニキャストDNS応答に：
2.113.0.203.in-addr.arpa. PTR prnt.bldg-1.example.com.
2.113.0.203.in-addr.arpa。 PTR prnt.bldg-1.example.com。
In this example the "prnt.local" host name is translated using the delegated LDH subdomain, as described in Section 5.5.
この例では、「prnt.local」ホスト名は、セクション5.5で説明されているように、委任されたLDHサブドメインを使用して変換されます。
Subsequent queries for the prnt.bldg-1.example.com address record, falling as it does within the bldg-1.example.com domain, which is delegated to this Discovery Proxy, will arrive at this Discovery Proxy where they are answered by issuing Multicast DNS queries and using the received Multicast DNS answers to synthesize Unicast DNS responses, as described above.
このprnt.bldg-1.example.comアドレスレコードに対する後続のクエリは、このDiscovery Proxyに委任されたbldg-1.example.comドメイン内と同様に、このDiscovery Proxyに到着し、そこで応答されます。上記のように、マルチキャストDNSクエリを発行し、受信したマルチキャストDNS回答を使用してユニキャストDNS応答を合成します。
Note that this description assumes that all addresses on a given IPv4 subnet or IPv6 prefix are mapped to host names using the Discovery Proxy mechanism. It would be possible to implement a Discovery Proxy that can be configured so that some address-to-name mappings are performed using Multicast DNS on the local link, while other address-to-name mappings within the same IPv4 subnet or IPv6 prefix are configured manually.
この説明では、特定のIPv4サブネットまたはIPv6プレフィックスのすべてのアドレスが、ディスカバリプロキシメカニズムを使用してホスト名にマッピングされていることを前提としています。同じIPv4サブネットまたはIPv6プレフィックス内の他のアドレスから名前へのマッピングが構成されている間に、ローカルリンクでマルチキャストDNSを使用して一部のアドレスから名前へのマッピングが実行されるように構成できるディスカバリプロキシを実装することが可能です。手動で。
For the delegated rich-text and LDH subdomains, generating appropriate Multicast DNS queries involves translating from the configured DNS domain (e.g., "Building 1.example.com") on the Unicast DNS side to ".local" on the Multicast DNS side.
委任されたリッチテキストおよびLDHサブドメインの場合、適切なマルチキャストDNSクエリの生成には、ユニキャストDNS側の構成済みDNSドメイン（たとえば、「Building 1.example.com」）からマルチキャストDNS側の「.local」への変換が含まれます。
For the delegated reverse-mapping subdomain, generating appropriate Multicast DNS queries involves using the appropriate API mechanism to indicate that a query should be performed using Multicast DNS, as described in Section 5.4.
委任された逆マッピングサブドメインの場合、適切なマルチキャストDNSクエリを生成するには、適切なAPIメカニズムを使用して、クエリがマルチキャストDNSを使用して実行される必要があることを示す必要があります。
Generating appropriate Unicast DNS responses from the received Multicast DNS answers involves translating back from ".local" to the appropriate configured Unicast DNS domain as necessary, as described below.
受信したマルチキャストDNS回答から適切なユニキャストDNS応答を生成するには、以下で説明するように、必要に応じて、「。local」から適切に構成されたユニキャストDNSドメインに変換し直す必要があります。
In the examples below, the delegated subdomains are as follows:
以下の例では、委任されたサブドメインは次のとおりです。
Delegated subdomain for rich-text names Building 1.example.com. Delegated subdomain for LDH names bldg-1.example.com. Delegated subdomain for IPv4 reverse mapping 113.0.203.in-addr.arpa.
リッチテキストの名前の委任サブドメインBuilding 1.example.com。 LDH名の委任サブドメインはbldg-1.example.comです。 IPv4リバースマッピングの委任サブドメイン113.0.203.in-addr.arpa。
Names in Multicast DNS answers that do not end in ".local" do not require any translation.
「.local」で終わらないマルチキャストDNS回答の名前は、変換を必要としません。
Names in Multicast DNS answers that end in ".local" are only meaningful on the local link, and require translation to make them useable by clients outside the local link.
「.local」で終わるマルチキャストDNS回答の名前は、ローカルリンクでのみ意味があり、ローカルリンク外のクライアントが使用できるように変換する必要があります。
Names that end in ".local" may appear both as the owner names of received Multicast DNS answer records, and in the RDATA of received Multicast DNS answer records.
「.local」で終わる名前は、受信したマルチキャストDNSアンサーレコードの所有者名としても、受信したマルチキャストDNSアンサーレコードのRDATAにも表示される場合があります。
In a received Multicast DNS answer record, if the owner name ends with ".local", then the ".local" top-level label is replaced with the name of the delegated subdomain as was used in the originating query.
受信したマルチキャストDNSアンサーレコードで、所有者名が「.local」で終わる場合、「。local」トップレベルラベルは、元のクエリで使用された委任されたサブドメインの名前に置き換えられます。
In a received Multicast DNS answer record, if a name in the RDATA ends with ".local", then the name is translated according to the delegated subdomain that was used in the originating query, as explained below.
受信したマルチキャストDNSアンサーレコードで、RDATAの名前が「.local」で終わる場合、その名前は、以下で説明するように、元のクエリで使用された委任サブドメインに従って変換されます。
For queries in subdomains delegated for LDH host names, ".local" names in RDATA are translated to that delegated LDH subdomain. For example, a query for "thing.bldg-1.example.com" will be translated to a Multicast DNS query for "thing.local". If that query returns this CNAME record:
LDHホスト名に委任されたサブドメインのクエリの場合、RDATAの「.local」名は、委任されたLDHサブドメインに変換されます。たとえば、「thing.bldg-1.example.com」のクエリは、「thing.local」のマルチキャストDNSクエリに変換されます。そのクエリがこのCNAMEレコードを返す場合：
thing.local. CNAME prnt.local.
事。ローカル。 CNAME prnt.local。
then both the owner name and the name in the RDATA are translated from ".local" to the LDH subdomain "bldg-1.example.com":
次に、所有者名とRDATA内の名前の両方が「.local」からLDHサブドメイン「bldg-1.example.com」に変換されます。
thing.bldg-1.example.com. CNAME prnt.bldg-1.example.com.
thing.bldg-1.example.com。 CNAME prnt.bldg-1.example.com。
For queries in subdomains delegated for reverse mapping names, ".local" names in RDATA are translated to the delegated LDH subdomain, if one is configured, or to the delegated rich-text subdomain otherwise. For example, consider a reverse mapping query that returns this PTR record:
リバースマッピング名に委任されたサブドメインのクエリの場合、RDATAの ".local"名は、委任されたLDHサブドメイン（構成されている場合）、または委任されたリッチテキストサブドメインに変換されます。たとえば、次のPTRレコードを返すリバースマッピングクエリを考えてみます。
2.113.0.203.in-addr.arpa. PTR prnt.local.
2.113.0.203.in-addr.arpa。 PTR prnt.local。
The owner name is not translated because it does not end in ".local". The name in the RDATA is translated from ".local" to the LDH subdomain "bldg-1.example.com":
所有者名は「.local」で終わっていないため、翻訳されません。 RDATAの名前は「.local」からLDHサブドメイン「bldg-1.example.com」に変換されます。
2.113.0.203.in-addr.arpa. PTR prnt.bldg-1.example.com.
2.113.0.203.in-addr.arpa。 PTR prnt.bldg-1.example.com。
For queries in subdomains delegated for rich-text names, ".local" names in RDATA are translated according to whether or not they represent host names (i.e., RDATA names that are the owner names of A and AAAA DNS records). RDATA names ending in ".local" that represent host names are translated to the delegated LDH subdomain, if one is configured, or to the delegated rich-text subdomain otherwise. All other RDATA names ending in ".local" are translated to the delegated rich-text subdomain. For example, consider a DNS-SD service browsing PTR query that returns this PTR record for IPP printing:
リッチテキスト名が委任されたサブドメインのクエリの場合、RDATAの「.local」名は、ホスト名を表すかどうかに応じて変換されます（つまり、AおよびAAAA DNSレコードの所有者名であるRDATA名）。ホスト名を表す「.local」で終わるRDATA名は、構成されている場合は委任されたLDHサブドメインに変換され、構成されていない場合は委任されたリッチテキストサブドメインに変換されます。 「.local」で終わる他のすべてのRDATA名は、委任されたリッチテキストサブドメインに変換されます。たとえば、IPP印刷用にこのPTRレコードを返すDNS-SDサービスブラウジングPTRクエリについて考えてみます。
_ipp._tcp.local. PTR My Printer._ipp._tcp.local.
_ipp._tcp.local。 PTR My Printer._ipp._tcp.local。
Both the owner name and the name in the RDATA are translated from ".local" to the rich-text subdomain:
所有者名とRDATA内の名前の両方が「.local」からリッチテキストサブドメインに変換されます。
_ipp._tcp.Building 1.example.com. PTR My Printer._ipp._tcp.Building 1.example.com.
_ipp._tcp.Building 1.example.com。 PTR My Printer._ipp._tcp.Building 1.example.com。
In contrast, consider a query that returns this SRV record for a specific IPP printing instance:
対照的に、特定のIPP印刷インスタンスのこのSRVレコードを返すクエリについて考えてみます。
My Printer._ipp._tcp.local. SRV 0 0 631 prnt.local.
私のPrinter._ipp._tcp.local。 SRV 0 0 631 prnt.local。
As for all queries, the owner name is translated to the delegated subdomain of the originating query, the delegated rich-text subdomain "Building 1.example.com". However, the ".local" name in the RDATA is the target host name field of an SRV record, a field that is used exclusively for host names. Consequently it is translated to the LDH subdomain "bldg-1.example.com", if configured, instead of the rich-text subdomain:
すべてのクエリと同様に、所有者名は、元のクエリの委任されたサブドメイン、委任されたリッチテキストサブドメイン「Building 1.example.com」に変換されます。ただし、RDATAの「.local」名はSRVレコードのターゲットホスト名フィールドであり、ホスト名専用に使用されるフィールドです。その結果、リッチテキストサブドメインではなく、LDHサブドメイン "bldg-1.example.com"に変換されます（構成されている場合）。
My Printer._ipp._tcp.Building 1.example.com. SRV 0 0 631 prnt.bldg-1.example.com.
My Printer._ipp._tcp.Building 1.example.com。 SRV 0 0 631 prnt.bldg-1.example.com。
Other beneficial translation and filtering operations are described below.
他の有益な変換およびフィルタリング操作を以下に説明します。
For efficiency, Multicast DNS typically uses moderately high DNS TTL values. For example, the typical TTL on DNS-SD service browsing PTR records is 75 minutes. What makes these moderately high TTLs acceptable is the cache coherency mechanisms built in to the Multicast DNS protocol, which protect against stale data persisting for too long. When a service shuts down gracefully, it sends goodbye packets to remove its service browsing PTR record(s) immediately from neighboring caches. If a service shuts down abruptly without sending goodbye packets, the Passive Observation Of Failures (POOF) mechanism described in Section 10.5 of the Multicast DNS specification [RFC6762] comes into play to purge the cache of stale data.
効率を上げるために、マルチキャストDNSは通常、適度に高いDNS TTL値を使用します。たとえば、PTRレコードを参照するDNS-SDサービスの一般的なTTLは75分です。これらの適度に高いTTLを許容できるのは、マルチキャストDNSプロトコルに組み込まれているキャッシュコヒーレンシメカニズムであり、古くなったデータが長く続くのを防ぎます。サービスが正常にシャットダウンすると、サービスは別のパケットを送信して、サービスを参照するPTRレコードを近隣のキャッシュからすぐに削除します。さようならパケットを送信せずにサービスが突然シャットダウンした場合、マルチキャストDNS仕様[RFC6762]のセクション10.5で説明されているPassive Observation of Failures（POOF）メカニズムが機能して、古いデータのキャッシュをパージします。
A traditional Unicast DNS client on a distant remote link does not get to participate in these Multicast DNS cache coherency mechanisms on the local link. For traditional Unicast DNS queries (those received without using Long-Lived Queries (LLQ) [RFC8764] or DNS Push Notification subscriptions [RFC8765]), the DNS TTLs reported in the resulting Unicast DNS response MUST be capped to be no more than ten seconds.
離れたリモートリンク上の従来のユニキャストDNSクライアントは、ローカルリンク上のこれらのマルチキャストDNSキャッシュコヒーレンシメカニズムに参加できません。従来のユニキャストDNSクエリ（長命クエリ（LLQ）[RFC8764]またはDNSプッシュ通知サブスクリプション[RFC8765]を使用せずに受信されたもの）の場合、結果のユニキャストDNS応答で報告されるDNS TTLは、10秒以内に制限する必要があります。
Similarly, for negative responses, the negative caching TTL indicated in the SOA record [RFC2308] should also be ten seconds (see Section 6.1).
同様に、否定応答の場合、SOAレコード[RFC2308]に示されている否定キャッシングTTLも10秒にする必要があります（セクション6.1を参照）。
This value of ten seconds is chosen based on user-experience considerations.
この10秒の値は、ユーザーエクスペリエンスの考慮事項に基づいて選択されます。
For negative caching, suppose a user is attempting to access a remote device (e.g., a printer), and they are unsuccessful because that device is powered off. Suppose they then place a telephone call and ask for the device to be powered on. We want the device to become available to the user within a reasonable time period. It is reasonable to expect it to take on the order of ten seconds for a simple device with a simple embedded operating system to power on. Once the device is powered on and has announced its presence on the network via Multicast DNS, we would like it to take no more than a further ten seconds for stale negative cache entries to expire from Unicast DNS caches, making the device available to the user desiring to access it.
ネガティブキャッシングの場合、ユーザーがリモートデバイス（プリンターなど）にアクセスしようとしていて、そのデバイスの電源がオフになっているために失敗したとします。次に、電話をかけ、デバイスの電源をオンにするように依頼したとします。妥当な期間内にユーザーがデバイスを使用できるようにしたいと考えています。単純な組み込みオペレーティングシステムを備えた単純なデバイスの電源がオンになるまでに10秒程度かかると予想するのは妥当です。デバイスの電源がオンになり、マルチキャストDNSを介してネットワーク上にデバイスが存在することを通知したら、ユニキャストDNSキャッシュから古いネガティブキャッシュエントリが期限切れになるまでに10秒以上かかり、ユーザーがデバイスを使用できるようにします。アクセスしたい。
Similar reasoning applies to capping positive TTLs at ten seconds. In the event of a device moving location, getting a new DHCP address, or other renumbering events, we would like the updated information to be available to remote clients in a relatively timely fashion.
同様の理由が、正のTTLを10秒に制限する場合にも当てはまります。デバイスが場所を移動したり、新しいDHCPアドレスを取得したり、その他の再番号付けイベントが発生した場合、更新された情報をリモートクライアントが比較的タイムリーに利用できるようにしたいと考えています。
However, network administrators should be aware that many recursive resolvers by default are configured to impose a minimum TTL of 30 seconds. If stale data appears to be persisting in the network to the extent that it adversely impacts user experience, network administrators are advised to check the configuration of their recursive resolvers.
ただし、ネットワーク管理者は、デフォルトで多くの再帰リゾルバが最小30秒のTTLを課すように構成されていることに注意する必要があります。古くなったデータがユーザーエクスペリエンスに悪影響を与える範囲でネットワークに残っているように見える場合、ネットワーク管理者は再帰リゾルバーの構成を確認することをお勧めします。
For received Unicast DNS queries that use LLQ [RFC8764] or DNS Push Notifications [RFC8765], the Multicast DNS record's TTL SHOULD be returned unmodified, because the notification channel exists to inform the remote client as records come and go. For further details about Long-Lived Queries and its newer replacement, DNS Push Notifications, see Section 5.6.
LLQ [RFC8764]またはDNSプッシュ通知[RFC8765]を使用する受信ユニキャストDNSクエリの場合、通知チャネルが存在し、レコードの送受信時にリモートクライアントに通知するため、マルチキャストDNSレコードのTTLは変更されずに返される必要があります。長期間有効なクエリとその新しい代替であるDNSプッシュ通知の詳細については、セクション5.6を参照してください。
A Discovery Proxy SHOULD offer a configurable option, enabled by default, to suppress Unicast DNS answers for records that are not useful outside the local link. When the option to suppress unusable records is enabled:
ディスカバリプロキシは、ローカルリンクの外部では役に立たないレコードのユニキャストDNS回答を抑制するために、デフォルトで有効になっている構成可能なオプションを提供する必要があります（SHOULD）。使用できないレコードを抑制するオプションが有効になっている場合：
* For a Discovery Proxy that is serving only clients outside the local link, DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 link-local addresses [RFC4862] SHOULD be suppressed.
* ローカルリンク外のクライアントのみにサービスを提供するディスカバリプロキシの場合、IPv4リンクローカルアドレス[RFC3927]およびIPv6リンクローカルアドレス[RFC4862]のDNS AおよびAAAAレコードは抑制されるべきです（SHOULD）。
* Similarly, for sites that have multiple private address realms [RFC1918], in cases where the Discovery Proxy can determine that the querying client is in a different address realm, private addresses SHOULD NOT be communicated to that client.
* 同様に、複数のプライベートアドレスレルム[RFC1918]を持つサイトの場合、Discovery Proxyがクエリを実行しているクライアントが別のアドレスレルムにあると判断できる場合、プライベートアドレスはそのクライアントに通信すべきではありません。
* IPv6 Unique Local Addresses [RFC4193] SHOULD be suppressed in cases where the Discovery Proxy can determine that the querying client is in a different IPv6 address realm.
* IPv6の一意のローカルアドレス[RFC4193]は、Discovery Proxyがクエリを実行しているクライアントが別のIPv6アドレスレルムにあると判断できる場合には抑制すべきです（SHOULD）。
* By the same logic, DNS SRV records that reference target host names that have no addresses usable by the requester should be suppressed, and likewise, DNS-SD service browsing PTR records that point to unusable SRV records should similarly be suppressed.
* 同じロジックにより、リクエスターが使用できるアドレスを持たないターゲットホスト名を参照するDNS SRVレコードを抑制し、同様に、使用できないSRVレコードを指すDNS-SDサービス参照PTRレコードを同様に抑制する必要があります。
Multicast DNS devices do not routinely announce their records on the network. Generally, they remain silent until queried. This means that the complete set of Multicast DNS records in use on a link can only be discovered by active querying, not by passive listening. Because of this, a Discovery Proxy can only know what names exist on a link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names exist and which do not, a Discovery Proxy cannot programmatically generate the traditional Unicast DNS NSEC [RFC4034] and NSEC3 [RFC5155] records that assert the nonexistence of a large range of names.
マルチキャストDNSデバイスは、ネットワーク上で自分のレコードを定期的にアナウンスしません。一般に、照会されるまでそれらは沈黙します。つまり、リンクで使用されているマルチキャストDNSレコードの完全なセットは、パッシブリスニングではなく、アクティブなクエリによってのみ検出できます。このため、ディスカバリープロキシは、クエリを発行することによってリンクに存在する名前のみを知ることができます。存在する名前と存在しない名前を見つけるためにすべての可能な名前に対してクエリを発行することは非現実的であるため、ディスカバリプロキシは、従来のユニキャストDNS NSEC [RFC4034]およびNSEC3 [RFC5155]レコードをプログラムで生成できません。このレコードは、広範囲の名前が存在しないことを表明しています。
When queried for an NSEC or NSEC3 record type, the Discovery Proxy issues a qtype "ANY" query using Multicast DNS on the local link and then generates an NSEC or NSEC3 response with a Type Bit Map signifying which record types do and do not exist for just the specific name queried, and no other names.
NSECまたはNSEC3のレコードタイプを照会すると、ディスカバリプロキシはローカルリンクでマルチキャストDNSを使用してqtype "ANY"クエリを発行し、タイプビットマップを使用してNSECまたはNSEC3応答を生成します。照会される特定の名前のみで、他の名前はありません。
Multicast DNS NSEC records received on the local link MUST NOT be forwarded unmodified to a unicast querier, because there are slight differences in the NSEC record data. In particular, Multicast DNS NSEC records do not have the NSEC bit set in the Type Bit Map, whereas conventional Unicast DNS NSEC records do have the NSEC bit set.
ローカルリンクで受信したマルチキャストDNS NSECレコードは、NSECレコードデータにわずかな違いがあるため、変更せずにユニキャストクエリアに転送してはなりません。特に、従来のユニキャストDNS NSECレコードにはNSECビットが設定されているのに対し、マルチキャストDNS NSECレコードにはタイプビットマップでNSECビットが設定されていません。
A Discovery Proxy does no translation between text encodings. Specifically, a Discovery Proxy does no translation between Punycode encoding [RFC3492] and UTF-8 encoding [RFC3629], either in the owner name of DNS records or anywhere in the RDATA of DNS records (such as the RDATA of PTR records, SRV records, NS records, or other record types like TXT, where it is ambiguous whether the RDATA may contain DNS names). All bytes are treated as-is with no attempt at text-encoding translation. A client implementing DNS-based Service Discovery [RFC6763] will use UTF-8 encoding for its unicast DNS-based Service Discovery queries, which the Discovery Proxy passes through without any text-encoding translation to the Multicast DNS subsystem. Responses from the Multicast DNS subsystem are similarly returned, without any text-encoding translation, back to the requesting unicast client.
Discovery Proxyは、テキストエンコーディング間の変換を行いません。具体的には、Discovery Proxyは、DNSレコードの所有者名またはDNSレコードのRDATA（PTRレコードのRDATA、SRVレコードなど）のいずれかで、Punycodeエンコーディング[RFC3492]とUTF-8エンコーディング[RFC3629]の間の変換を行いません。 、NSレコード、またはTXTのような他のレコードタイプで、RDATAにDNS名が含まれているかどうかが不明確です）。すべてのバイトは、テキストエンコーディング変換を試みずに、そのまま扱われます。 DNSベースのサービスディスカバリ[RFC6763]を実装するクライアントは、ユニキャストDNSベースのサービスディスカバリクエリにUTF-8エンコーディングを使用します。ディスカバリプロキシは、テキストエンコーディング変換を行わずにマルチキャストDNSサブシステムに渡します。マルチキャストDNSサブシステムからの応答も同様に、テキストエンコーディング変換なしで、要求元のユニキャストクライアントに返されます。
There may be cases where Application-Specific Data Translation is appropriate.
アプリケーション固有のデータ変換が適切な場合があります。
For example, AirPrint printers tend to advertise fairly verbose information about their capabilities in their DNS-SD TXT record. TXT record sizes in the range of 500-1000 bytes are not uncommon. This information is a legacy from lineprinter (LPR) printing, because LPR does not have in-band capability negotiation, so all of this information is conveyed using the DNS-SD TXT record instead. Internet Printing Protocol (IPP) printing does have in-band capability negotiation, but for convenience, printers tend to include the same capability information in their IPP DNS-SD TXT records as well. For local Multicast DNS (mDNS) use, this extra TXT record information is wasteful but not fatal. However, when a Discovery Proxy aggregates data from multiple printers on a link, and sends it via unicast (via UDP or TCP), this amount of unnecessary TXT record information can result in large responses. A DNS reply over TCP carrying information about 70 printers with an average of 700 bytes per printer adds up to about 50 kilobytes of data. Therefore, a Discovery Proxy that is aware of the specifics of an application-layer protocol such as AirPrint (which uses IPP) can elide unnecessary key/value pairs from the DNS-SD TXT record for better network efficiency.
たとえば、AirPrintプリンターは、機能に関するかなり詳細な情報をDNS-SD TXTレコードでアドバタイズする傾向があります。 500〜1000バイトの範囲のTXTレコードサイズは珍しくありません。 LPRにはインバンド機能ネゴシエーションがないため、この情報はラインプリンター（LPR）印刷のレガシーです。この情報のすべては、代わりにDNS-SD TXTレコードを使用して伝達されます。インターネット印刷プロトコル（IPP）印刷には帯域内機能ネゴシエーションがありますが、便宜上、プリンターは同じ機能情報をIPP DNS-SD TXTレコードにも含める傾向があります。ローカルマルチキャストDNS（mDNS）を使用する場合、この追加のTXTレコード情報は無駄ですが致命的ではありません。ただし、ディスカバリープロキシがリンク上の複数のプリンターからデータを集約し、ユニキャスト（UDPまたはTCP）経由で送信する場合、この量の不要なTXTレコード情報により、大きな応答が発生する可能性があります。 TCPを介したDNS応答は、70台のプリンターに関する情報を運び、1プリンターあたり平均700バイトで、合計で約50キロバイトのデータになります。したがって、AirPrint（IPPを使用）などのアプリケーション層プロトコルの詳細を認識するディスカバリープロキシは、DNS-SD TXTレコードから不要なキー/値のペアを除外して、ネットワーク効率を高めることができます。
Also, the DNS-SD TXT record for many printers contains an "adminurl" key (e.g., "adminurl=http://printername.local/status.html"). For this URL to be useful outside the local link, the embedded ".local" host name needs to be translated to an appropriate name with larger scope. It is easy to translate ".local" names when they appear in well-defined places: as a record's owner name, or in domain name fields in the RDATA of record types like PTR and SRV. In the printing case, some application-specific knowledge about the semantics of the "adminurl" key is needed for the Discovery Proxy to know that it contains a name that needs to be translated. This is somewhat analogous to the need for NAT gateways to contain ALGs (Application-Level Gateways) to facilitate the correct translation of protocols that embed addresses in unexpected places.
また、多くのプリンターのDNS-SD TXTレコードには、「adminurl」キー（「adminurl = http：//printername.local/status.html」など）が含まれています。このURLがローカルリンクの外側で役立つようにするには、埋め込まれた「.local」ホスト名を、より大きなスコープを持つ適切な名前に変換する必要があります。 ".local"の名前は、明確に定義された場所（レコードの所有者名として、またはPTRやSRVなどのレコードタイプのRDATAのドメイン名フィールド）にある場合、簡単に翻訳できます。印刷の場合、「adminurl」キーのセマンティクスに関するアプリケーション固有の知識がいくつか必要です。これは、Discovery Proxyが、翻訳する必要がある名前を含んでいることを知るためです。これは、予期しない場所にアドレスを埋め込むプロトコルの正しい変換を容易にするために、NATゲートウェイがALG（アプリケーションレベルゲートウェイ）を含む必要性にいくらか類似しています。
To avoid the need for application-specific knowledge about the semantics of particular TXT record keys, protocol designers are advised to avoid placing link-local names or link-local IP addresses in TXT record keys if translation of those names or addresses would be required for off-link operation. In the printing case, the consequence of failing to translate the "adminurl" key correctly would be that, when accessed from a different link, printing will still work, but clicking the "Admin" user interface button will fail to open the printer's administration page. Rather than duplicating the host name from the service's SRV record in its "adminurl" key, thereby having the same host name appear in two places, a better design might have been to omit the host name from the "adminurl" key and instead have the client implicitly substitute the target host name from the service's SRV record in place of a missing host name in the "adminurl" key. That way, the desired host name only appears once and is in a well-defined place where software like the Discovery Proxy is expecting to find it.
特定のTXTレコードキーのセマンティクスに関するアプリケーション固有の知識の必要性を回避するために、プロトコル設計者は、リンクローカル名またはリンクローカルIPアドレスをTXTレコードキーに配置しないようにすることをお勧めします。オフリンク操作。印刷の場合、「adminurl」キーを正しく変換できないと、別のリンクからアクセスしても印刷は機能しますが、「管理」ユーザーインターフェイスボタンをクリックしても、プリンターの管理ページを開くことができません。 。 「adminurl」キーのサービスのSRVレコードからホスト名を複製して同じホスト名を2か所に表示するのではなく、「adminurl」キーからホスト名を省略して、代わりにクライアントは、「adminurl」キーに欠落しているホスト名の代わりに、サービスのSRVレコードのターゲットホスト名を暗黙的に置き換えます。このようにして、目的のホスト名は1回だけ表示され、Discovery Proxyなどのソフトウェアがそれを見つけることを期待している明確に定義された場所にあります。
Note that this kind of Application-Specific Data Translation is expected to be very rare; it is the exception rather than the rule. This is an example of a common theme in computing. It is frequently the case that it is wise to start with a clean, layered design with clear boundaries. Then, in certain special cases, those layer boundaries may be violated where the performance and efficiency benefits outweigh the inelegance of the layer violation.
この種のアプリケーション固有のデータ変換は非常にまれであると予想されることに注意してください。ルールというよりは例外です。これは、コンピューティングにおける一般的なテーマの例です。多くの場合、明確な境界のあるクリーンなレイヤードデザインから始めるのが賢明です。次に、特定の特殊なケースで、パフォーマンスと効率のメリットがレイヤー違反の優雅さを上回る場合、それらのレイヤー境界に違反する可能性があります。
These layer violations are optional. They are done primarily for efficiency reasons and generally should not be required for correct operation. A Discovery Proxy MAY operate solely at the mDNS layer without any knowledge of semantics at the DNS-SD layer or above.
これらのレイヤー違反はオプションです。これらは主に効率上の理由で行われ、通常、正しい操作には必要ありません。 Discovery Proxyは、DNS-SDレイヤー以上のセマンティクスについての知識がなくても、mDNSレイヤーでのみ動作する場合があります。
In a simple analysis, simply gathering multicast answers and forwarding them in a unicast response seems adequate, but it raises the question of how long the Discovery Proxy should wait to be sure that it has received all the Multicast DNS answers it needs to form a complete Unicast DNS response. If it waits too little time, then it risks its Unicast DNS response being incomplete. If it waits too long, then it creates a poor user experience at the client end. In fact, there may be no time that is both short enough to produce a good user experience and at the same time long enough to reliably produce complete results.
単純な分析では、マルチキャスト応答を収集してユニキャスト応答で転送するだけで十分に思われますが、完全なものを形成するために必要なすべてのマルチキャストDNS応答を受信するために、Discovery Proxyがどれだけ待つ必要があるかという問題が生じます。ユニキャストDNS応答。待機時間が少なすぎると、ユニキャストDNS応答が不完全になるリスクがあります。待機時間が長すぎると、クライアントエンドでのユーザーエクスペリエンスが低下します。実際、優れたユーザーエクスペリエンスを実現するのに十分なほど短い時間はなく、完全な結果を確実に生成するのに十分なほど長い時間もありません。
Similarly, the Discovery Proxy (the authoritative name server for the subdomain in question) needs to decide what DNS TTL to report for these records. If the TTL is too long, then the recursive resolvers issuing queries on behalf of their clients risk caching stale data for too long. If the TTL is too short, then the amount of network traffic will be more than necessary. In fact, there may be no TTL that is both short enough to avoid undesirable stale data and, at the same time, long enough to be efficient on the network.
同様に、Discovery Proxy（問題のサブドメインの権威ネームサーバー）は、これらのレコードについて報告するDNS TTLを決定する必要があります。 TTLが長すぎる場合、クライアントに代わってクエリを発行する再帰リゾルバーは、古くなったデータを長時間キャッシュするリスクがあります。 TTLが短すぎると、ネットワークトラフィックの量が必要以上に多くなります。実際には、望ましくない古くなったデータを回避するのに十分短いと同時に、ネットワーク上で効率的になるのに十分な長さのTTLがない場合があります。
Both these dilemmas are solved by the use of DNS Long-Lived Queries (LLQ) [RFC8764] or its newer replacement, DNS Push Notifications [RFC8765].
これらのジレンマはどちらも、DNS長命クエリ（LLQ）[RFC8764]またはその新しい代替DNSプッシュ通知[RFC8765]を使用することで解決されます。
Clients supporting unicast DNS-based Service Discovery SHOULD implement DNS Push Notifications [RFC8765] for improved user experience.
ユニキャストDNSベースのサービスディスカバリをサポートするクライアントは、ユーザーエクスペリエンスを向上させるためにDNSプッシュ通知[RFC8765]を実装する必要があります（SHOULD）。
Clients and Discovery Proxies MAY support both LLQ and DNS Push Notifications, and when talking to a Discovery Proxy that supports both, the client may use either protocol, as it chooses, though it is expected that only DNS Push Notifications will continue to be supported in the long run.
クライアントとディスカバリプロキシはLLQとDNSプッシュ通知の両方をサポートする場合があり、両方をサポートするディスカバリプロキシと通信する場合、クライアントは選択したいずれかのプロトコルを使用できますが、DNSプッシュ通知のみが引き続きサポートされることが予想されます長期的には。
When a Discovery Proxy receives a query using LLQ or DNS Push Notifications, it responds immediately using the Multicast DNS records it already has in its cache (if any). This provides a good client user experience by providing a near-instantaneous response. Simultaneously, the Discovery Proxy issues a Multicast DNS query on the local link to discover if there are any additional Multicast DNS records it did not already know about. Should additional Multicast DNS responses be received, these are then delivered to the client using additional LLQ or DNS Push Notification update messages. The timeliness of such update messages is limited only by the timeliness of the device responding to the Multicast DNS query. If the Multicast DNS device responds quickly, then the update message is delivered quickly. If the Multicast DNS device responds slowly, then the update message is delivered slowly. The benefit of using multiple update messages to deliver results as they become available is that the Discovery Proxy can respond promptly because it doesn't have to deliver all the results in a single response that needs to be delayed to allow for the expected worst-case delay for receiving all the Multicast DNS responses.
ディスカバリプロキシは、LLQまたはDNSプッシュ通知を使用してクエリを受信すると、キャッシュ内にすでにあるマルチキャストDNSレコード（存在する場合）を使用して即座に応答します。これは、ほぼ瞬時の応答を提供することにより、優れたクライアントユーザーエクスペリエンスを提供します。同時に、ディスカバリプロキシはローカルリンクでマルチキャストDNSクエリを発行して、まだ知らなかった追加のマルチキャストDNSレコードがあるかどうかを検出します。追加のマルチキャストDNS応答が受信されると、それらは追加のLLQまたはDNSプッシュ通知更新メッセージを使用してクライアントに配信されます。このような更新メッセージの適時性は、マルチキャストDNSクエリに応答するデバイスの適時性によってのみ制限されます。マルチキャストDNSデバイスが迅速に応答する場合、更新メッセージは迅速に配信されます。マルチキャストDNSデバイスの応答が遅い場合、更新メッセージの配信が遅くなります。複数の更新メッセージを使用して結果が利用可能になったときに配信することの利点は、予想される最悪の場合に対応するために遅延させる必要がある単一の応答ですべての結果を配信する必要がないため、Discovery Proxyが迅速に応答できることです。すべてのマルチキャストDNS応答を受信するための遅延。
With a proxy that supported only standard DNS queries, even if it were to try to provide reliability by assuming an excessively pessimistic worst-case time (thereby giving a very poor user experience), there would still be the risk of a slow Multicast DNS device taking even longer than that worst-case time (e.g., a device that is not even powered on until ten seconds after the initial query is received), resulting in incomplete responses. Using update messages to deliver subsequent asynchronous replies solves this dilemma: even very late responses are not lost; they are delivered in subsequent update messages.
標準のDNSクエリのみをサポートするプロキシを使用すると、極端に悲観的な最悪の場合の時間を想定して信頼性を提供しようとしたとしても（非常に貧弱なユーザーエクスペリエンスを提供します）、マルチキャストDNSデバイスが低速になるリスクが依然としてあります。その最悪の場合よりもさらに時間がかかり（たとえば、最初のクエリが受信されてから10秒まで電源がオンにならないデバイス）、応答が不完全になります。更新メッセージを使用して後続の非同期応答を配信すると、このジレンマが解決されます。非常に遅い応答でさえ失われません。それらは後続の更新メッセージで配信されます。
Note that while normal DNS queries are generally received via the client's configured recursive resolver, LLQ and DNS Push Notification subscriptions may be received directly from the client.
通常のDNSクエリは通常、クライアントの構成済みの再帰リゾルバーを介して受信されますが、LLQおよびDNSプッシュ通知サブスクリプションは、クライアントから直接受信される場合があります。
There are two factors that determine how unicast responses are generated:
ユニキャスト応答の生成方法を決定する2つの要因があります。
The first factor is whether or not the Discovery Proxy already has at least one record in its cache that answers the question.
最初の要素は、Discovery Proxyがキャッシュに質問に回答するレコードを少なくとも1つすでに持っているかどうかです。
The second factor is whether the client used a normal DNS query, or established a subscription using LLQ or DNS Push Notifications. Normal DNS queries are typically used for one-shot operations like SRV or address record queries. LLQ and DNS Push Notification subscriptions are typically used for long-lived service browsing PTR queries. Normal DNS queries and LLQ each have different response timing depending on the cache state, yielding the first four cases listed below. DNS Push Notifications, the newer protocol, has uniform behavior regardless of cache state, yielding the fifth case listed below.
2番目の要素は、クライアントが通常のDNSクエリを使用したか、LLQまたはDNSプッシュ通知を使用してサブスクリプションを確立したかです。通常のDNSクエリは、通常、SRVやアドレスレコードクエリなどのワンショット操作に使用されます。 LLQおよびDNSプッシュ通知サブスクリプションは、通常、長期間有効なサービスブラウジングPTRクエリに使用されます。通常のDNSクエリとLLQはそれぞれ、キャッシュの状態に応じて異なる応答タイミングを持ち、以下にリストされている最初の4つのケースを生成します。新しいプロトコルであるDNSプッシュ通知は、キャッシュの状態に関係なく動作が統一されており、以下の5番目のケースになります。
* Standard DNS query; no answer in cache:
* 標準DNSクエリ。キャッシュに回答がありません：
Issue an mDNS query on the local link, exactly as a local client would issue an mDNS query, for the desired record name, type, and class, including retransmissions, as appropriate, according to the established mDNS retransmission schedule [RFC6762]. The Discovery Proxy awaits Multicast DNS responses.
ローカルクライアントがmDNSクエリを発行するのとまったく同じように、確立されたmDNS再送信スケジュール[RFC6762]に従って、必要に応じて再送信を含め、目的のレコード名、タイプ、およびクラスに対してmDNSクエリを発行するのと同じように、mDNSクエリをローカルリンクで発行します。 Discovery Proxyは、マルチキャストDNS応答を待ちます。
As soon as any Multicast DNS response packet is received that contains one or more positive answers to that question (with or without the Cache Flush bit [RFC6762] set) or a negative answer (signified via a Multicast DNS NSEC record [RFC6762]), the Discovery Proxy generates a Unicast DNS response message containing the corresponding (filtered and translated) answers and sends it to the remote client.
その質問に対する1つ以上の肯定的な回答（キャッシュフラッシュビット[RFC6762]が設定されているかどうかにかかわらず）または否定的な回答（マルチキャストDNS NSECレコード[RFC6762]で指定）を含むマルチキャストDNS応答パケットが受信されるとすぐに、ディスカバリプロキシは、対応する（フィルタリングおよび変換された）応答を含むユニキャストDNS応答メッセージを生成し、それをリモートクライアントに送信します。
If after six seconds no relevant Multicast DNS answers have been received, cancel the mDNS query and return a negative response to the remote client. Six seconds is enough time for the underlying Multicast DNS subsystem to transmit three mDNS queries and allow some time for responses to arrive.
6秒経過しても関連するマルチキャストDNS応答が受信されない場合は、mDNSクエリをキャンセルして、リモートクライアントに否定応答を返します。 6秒は、基盤となるマルチキャストDNSサブシステムが3つのmDNSクエリを送信し、応答が到着するまでの時間を確保するのに十分な時間です。
(Reasoning: Queries not using LLQ or Push Notifications are generally queries that expect an answer from only one device, so the first response is also the only response.)
（理由：LLQまたはプッシュ通知を使用しないクエリは、通常、1つのデバイスからの応答のみを期待するクエリであるため、最初の応答も唯一の応答です。）
DNS TTLs in responses MUST be capped to at most ten seconds.
応答のDNS TTLは、最大で10秒に制限する必要があります。
* Standard DNS query; at least one answer in cache:
* 標準DNSクエリ。キャッシュ内の少なくとも1つの回答：
No local mDNS queries are performed.
ローカルmDNSクエリは実行されません。
The Discovery Proxy generates a Unicast DNS response message containing the answer(s) from the cache right away, to minimize delay.
ディスカバリプロキシは、遅延を最小限に抑えるために、キャッシュからの回答を含むユニキャストDNS応答メッセージをすぐに生成します。
(Reasoning: Queries not using LLQ or Push Notifications are generally queries that expect an answer from only one device. Given RRSet TTL harmonization, if the proxy has one Multicast DNS answer in its cache, it can reasonably assume that it has the whole set.)
（推論：LLQまたはプッシュ通知を使用しないクエリは、通常、1つのデバイスからの応答のみを期待するクエリです。RRSetTTLの調和を考慮すると、プロキシのキャッシュにマルチキャストDNS回答が1つある場合、そのセット全体が適切であると想定できます。 ）
DNS TTLs in responses MUST be capped to at most ten seconds.
応答のDNS TTLは、最大で10秒に制限する必要があります。
* Long-Lived Query (LLQ); no answer in cache:
* 長命クエリ（LLQ）;キャッシュに回答がありません：
As in the case above with no answer in the cache, plan to perform mDNS querying for six seconds, returning an LLQ response message to the remote client as soon as any relevant mDNS response is received.
キャッシュに応答がない上記の場合のように、mDNSクエリを6秒間実行し、関連するmDNS応答が受信されるとすぐにリモートクライアントにLLQ応答メッセージを返すことを計画します。
If after six seconds no relevant mDNS answers have been received, and the client has not cancelled its Long-Lived Query, return a negative LLQ response message to the remote client.
6秒経過しても関連するmDNS応答が受信されず、クライアントがその長命のクエリをキャンセルしていない場合は、リモートクライアントに否定のLLQ応答メッセージを返します。
(Reasoning: We don't need to rush to send an empty answer.)
（理由：空の回答を急いで送信する必要はありません。）
Regardless of whether or not a relevant mDNS response is received within six seconds, the Long-Lived Query remains active for as long as the client maintains the LLQ state, and results in the ongoing transmission of mDNS queries until the Long-Lived Query is cancelled. If the set of mDNS answers changes, LLQ Event Response messages are sent.
関連するmDNS応答が6秒以内に受信されるかどうかに関係なく、クライアントがLLQ状態を維持している限り、長命クエリはアクティブなままであり、長命クエリがキャンセルされるまでmDNSクエリが継続的に送信されます。 。 mDNS応答のセットが変更されると、LLQイベント応答メッセージが送信されます。
DNS TTLs in responses are returned unmodified.
応答のDNS TTLは変更されずに返されます。
* Long-Lived Query (LLQ); at least one answer in cache:
* 長命クエリ（LLQ）;キャッシュ内の少なくとも1つの回答：
As in the case above with at least one answer in the cache, the Discovery Proxy generates a unicast LLQ response message containing the answer(s) from the cache right away, to minimize delay.
キャッシュに少なくとも1つの回答がある上記の場合と同様に、Discovery Proxyは、遅延を最小限に抑えるために、キャッシュからの回答を含むユニキャストLLQ応答メッセージをすぐに生成します。
The Long-Lived Query remains active for as long as the client maintains the LLQ state, and results in the transmission of mDNS queries (with appropriate Known Answer lists) to determine if further answers are available. If the set of mDNS answers changes, LLQ Event Response messages are sent.
長期間有効なクエリは、クライアントがLLQ状態を維持している限りアクティブなままであり、mDNSクエリ（適切な既知の回答リストを含む）を送信して、さらに回答があるかどうかを判断します。 mDNS応答のセットが変更されると、LLQイベント応答メッセージが送信されます。
(Reasoning: We want a user interface that is displayed very rapidly yet continues to remain accurate even as the network environment changes.)
（理由：非常に高速に表示され、しかもネットワーク環境が変化しても正確性を保ち続けるユーザーインターフェイスが必要です。）
DNS TTLs in responses are returned unmodified.
応答のDNS TTLは変更されずに返されます。
* Push Notification Subscription
* プッシュ通知サブスクリプション
The Discovery Proxy acknowledges the subscription request immediately.
Discovery Proxyは、サブスクリプション要求をすぐに確認します。
If one or more answers are already available in the cache, those answers are then sent in an immediately following DNS PUSH message.
1つ以上の回答が既にキャッシュで利用可能な場合、それらの回答は直後のDNS PUSHメッセージで送信されます。
The Push Notification subscription remains active until the client cancels the subscription, and results in the transmission of mDNS queries (with appropriate Known Answer lists) to determine if further answers are available. If the set of mDNS answers changes, further DNS PUSH messages are sent.
プッシュ通知サブスクリプションは、クライアントがサブスクリプションをキャンセルするまでアクティブのままで、mDNSクエリが送信され（適切な既知の回答リストを使用）、さらに回答があるかどうかが判断されます。 mDNS応答のセットが変更されると、さらにDNS PUSHメッセージが送信されます。
(Reasoning: We want a user interface that is displayed very rapidly yet continues to remain accurate even as the network environment changes.)
（理由：非常に高速に表示され、しかもネットワーク環境が変化しても正確性を保ち続けるユーザーインターフェイスが必要です。）
DNS TTLs in responses are returned unmodified.
応答のDNS TTLは変更されずに返されます。
Where the text above refers to returning "a negative response to the remote client", it is describing returning a "no error no answer" negative response, not NXDOMAIN. This is because the Discovery Proxy cannot know all the Multicast DNS domain names that may exist on a link at any given time, so any name with no answers may have child names that do exist, making it an "empty non-terminal" name.
上記のテキストが「リモートクライアントへの否定応答」を返すことについて言及している場合、NXDOMAINではなく、「エラーなし、応答なし」否定応答を返すことを説明しています。これは、ディスカバリプロキシが常にリンク上に存在する可能性があるすべてのマルチキャストDNSドメイン名を認識できないためです。そのため、応答のない名前には存在する子名があり、「空の非端末」名になる場合があります。
Note that certain aspects of the behavior described here do not have to be implemented overtly by the Discovery Proxy; they occur naturally as a result of using existing Multicast DNS APIs.
ここで説明する動作の特定の側面は、Discovery Proxyによって明示的に実装する必要がないことに注意してください。これらは、既存のマルチキャストDNS APIを使用した結果として自然に発生します。
For example, in the first case above (standard DNS query and no answers in the cache), if a new Multicast DNS query is requested (either by a local client on the Discovery Proxy device, or by the Discovery Proxy software on that device on behalf of a remote client), and there is not already an identical Multicast DNS query active and there are no matching answers already in the Multicast DNS cache on the Discovery Proxy device, then this will cause a series of Multicast DNS query packets to be issued with exponential backoff. The exponential backoff sequence in some implementations starts at one second and then doubles for each retransmission (0, 1, 3, 7 seconds, etc.), and in others, it starts at one second and then triples for each retransmission (0, 1, 4, 13 seconds, etc.). In either case, if no response has been received after six seconds, that is long enough that the underlying Multicast DNS implementation will have sent three query packets without receiving any response. At that point, the Discovery Proxy cancels its Multicast DNS query (so no further Multicast DNS query packets will be sent for this query) and returns a negative response to the remote client via unicast.
たとえば、上記の最初のケース（標準DNSクエリでキャッシュに応答がない）で、新しいマルチキャストDNSクエリが要求された場合（Discovery ProxyデバイスのローカルクライアントまたはそのデバイスのDiscovery Proxyソフトウェアのいずれか）リモートクライアントに代わって）、アクティブな同一のマルチキャストDNSクエリがまだなく、ディスカバリプロキシデバイスのマルチキャストDNSキャッシュに一致する回答がまだない場合、これにより一連のマルチキャストDNSクエリパケットが発行されます。指数バックオフあり。一部の実装では、指数バックオフシーケンスは1秒から始まり、再送信ごとに2倍になり（0、1、3、7秒など）、1秒から始まり、再送信ごとに3倍になります（0、1 、4、13秒など）。どちらの場合も、6秒後に応答が受信されない場合、基礎となるマルチキャストDNS実装が応答を受信せずに3つのクエリパケットを送信するのに十分な時間です。その時点で、ディスカバリプロキシはマルチキャストDNSクエリをキャンセルし（このクエリに対してマルチキャストDNSクエリパケットがそれ以上送信されなくなります）、ユニキャストを介してリモートクライアントに否定応答を返します。
The six-second delay is chosen to be long enough to give enough time for devices to respond, yet short enough not to be too onerous for a human user waiting for a response. For example, using the "dig" DNS debugging tool, the current default settings result in it waiting a total of 15 seconds for a reply (three transmissions of the DNS UDP query packet, with a wait of 5 seconds after each packet), which is ample time for it to have received a negative reply from a Discovery Proxy after six seconds.
6秒の遅延は、デバイスが応答するのに十分な時間を与えるのに十分な長さであるが、応答を待っている人間のユーザーにとって煩わしくないほど短く選択されています。たとえば、「dig」DNSデバッグツールを使用すると、現在のデフォルト設定では、応答を合計15秒待機します（DNS UDPクエリパケットを3回送信し、各パケットの後に5秒待機します）。 6秒後にDiscovery Proxyから否定応答を受け取った十分な時間です。
The text above states that for a standard DNS query, if at least one answer is already available in the cache, then a Discovery Proxy should not issue additional mDNS query packets. This also occurs naturally as a result of using existing Multicast DNS APIs. If a new Multicast DNS query is requested (either locally, or by the Discovery Proxy on behalf of a remote client) for which there are relevant answers already in the Multicast DNS cache on the Discovery Proxy device, and after the answers are delivered the Multicast DNS query is immediately cancelled, then no Multicast DNS query packets will be generated for this query.
上記のテキストは、標準のDNSクエリの場合、少なくとも1つの回答がすでにキャッシュで利用可能な場合、Discovery Proxyは追加のmDNSクエリパケットを発行しないことを示しています。これは、既存のマルチキャストDNS APIを使用した結果としても自然に発生します。新しいマルチキャストDNSクエリが要求された場合（ローカルで、またはリモートクライアントに代わってDiscovery Proxyによって）、関連する回答が既にDiscovery ProxyデバイスのマルチキャストDNSキャッシュにあり、回答が配信された後DNSクエリは直ちにキャンセルされ、このクエリに対してマルチキャストDNSクエリパケットは生成されません。
The MNAME field SHOULD contain the host name of the Discovery Proxy device (i.e., the same domain name as the RDATA of the NS record delegating the relevant zone(s) to this Discovery Proxy device).
NAMEフィールドには、Discovery Proxyデバイスのホスト名（つまり、関連するゾーンをこのDiscovery Proxyデバイスに委任するNSレコードのDATAと同じドメイン名）を含める必要があります（SHOULD）。
The RNAME field SHOULD contain the mailbox of the person responsible for administering this Discovery Proxy device.
NAMEフィールドには、このDiscovery Proxyデバイスの管理を担当する人物のメールボックスを含める必要があります（SHOULD）。
The SERIAL field MUST be zero.
SERIALフィールドはゼロでなければなりません。
Zone transfers are undefined for Discovery Proxy zones, and consequently, the REFRESH, RETRY, and EXPIRE fields have no useful meaning for Discovery Proxy zones. These fields SHOULD contain reasonable default values. The RECOMMENDED values are: REFRESH 7200, RETRY 3600, and EXPIRE 86400.
ゾーン転送はディスカバリープロキシゾーンでは定義されていないため、REFRESH、RETRY、およびEXPIREフィールドはディスカバリープロキシゾーンにとって有用な意味を持ちません。これらのフィールドには、妥当なデフォルト値が含まれている必要があります（SHOULD）。推奨値は、REFRESH 7200、RETRY 3600、およびEXPIRE 86400です。
The MINIMUM field (used to control the lifetime of negative cache entries) SHOULD contain the value 10. This value is chosen based on user-experience considerations (see Section 5.5.1).
MINIMUMフィールド（ネガティブキャッシュエントリの有効期間を制御するために使用）には値10を含める必要があります。この値は、ユーザーエクスペリエンスの考慮事項に基づいて選択されます（5.5.1項を参照）。
In the event that there are multiple Discovery Proxy devices on a link for fault tolerance reasons, this will result in clients receiving inconsistent SOA records (different MNAME and possibly RNAME) depending on which Discovery Proxy answers their SOA query. However, since clients generally have no reason to use the MNAME or RNAME data, this is unlikely to cause any problems.
フォールトトレランスの理由でリンク上に複数のDiscovery Proxyデバイスが存在する場合、これにより、どのDiscovery ProxyがSOAクエリに応答するかに応じて、クライアントが一貫性のないSOAレコード（異なるMNAMEおよび場合によってはRNAME）を受信します。ただし、クライアントは通常MNAMEまたはRNAMEデータを使用する理由がないため、これが問題を引き起こすことはほとんどありません。
In the event that there are multiple Discovery Proxy devices on a link for fault tolerance reasons, the parent zone MUST be configured with NS records giving the names of all the Discovery Proxy devices on the link.
フォールトトレランスの理由でリンク上に複数のDiscovery Proxyデバイスがある場合、親ゾーンは、リンク上のすべてのDiscovery Proxyデバイスの名前を示すNSレコードで構成する必要があります。
Each Discovery Proxy device MUST be configured to answer NS queries for the zone apex name by giving its own NS record, and the NS records of its fellow Discovery Proxy devices on the same link, so that it can return the correct answers for NS queries.
各Discovery Proxyデバイスは、独自のNSレコードと、同じリンク上のその仲間のDiscovery ProxyデバイスのNSレコードを提供することにより、ゾーン頂点名のNSクエリに応答するように構成する必要があります。これにより、NSクエリの正しい回答を返すことができます。
The target host name in the RDATA of an NS record MUST NOT reference a name that falls within any zone delegated to a Discovery Proxy. Apart from the zone apex name, all other host names (names of A and AAAA DNS records) that fall within a zone delegated to a Discovery Proxy correspond to local Multicast DNS host names, which logically belong to the respective Multicast DNS hosts defending those names, not the Discovery Proxy. Generally speaking, the Discovery Proxy does not own or control the delegated zone; it is merely a conduit to the corresponding ".local" namespace, which is controlled by the Multicast DNS hosts on that link. If an NS record were to reference a manually determined host name that falls within a delegated zone, that manually determined host name may inadvertently conflict with a corresponding ".local" host name that is owned and controlled by some device on that link.
NSレコードのRDATA内のターゲットホスト名は、Discovery Proxyに委任されたゾーン内にある名前を参照してはなりません（MUST NOT）。ゾーンの頂点名を除いて、ディスカバリプロキシに委任されたゾーン内にある他のすべてのホスト名（AおよびAAAA DNSレコードの名前）は、ローカルのマルチキャストDNSホスト名に対応し、これらの名前を防御するそれぞれのマルチキャストDNSホストに論理的に属します、ディスカバリプロキシではありません。一般的に、Discovery Proxyは委任されたゾーンを所有または制御しません。これは、対応する「.local」名前空間への単なるパイプであり、そのリンク上のマルチキャストDNSホストによって制御されます。 NSレコードが委任されたゾーン内にある手動で決定されたホスト名を参照する場合、その手動で決定されたホスト名は、そのリンク上のデバイスによって所有および制御されている対応する「.local」ホスト名と誤って競合する可能性があります。
Since the Multicast DNS specification [RFC6762] states that there can be no delegation (subdomains) within a ".local" namespace, this implies that any name within a zone delegated to a Discovery Proxy (except for the zone apex name itself) cannot have any answers for any DNS queries for RRTYPEs SOA, NS, or DS. Consequently:
マルチキャストDNS仕様[RFC6762]では、「。local」ネームスペース内に委任（サブドメイン）は存在できないと規定されているため、ディスカバリプロキシに委任されたゾーン内の名前（ゾーンの頂点名自体を除く）は、 RRTYPEs SOA、NS、またはDSのDNSクエリに対する回答。結果として：
* for any query for the zone apex name of a zone delegated to a Discovery Proxy, the Discovery Proxy MUST generate the appropriate immediate answers as described above, and
* Discovery Proxyに委任されたゾーンのゾーン頂点名のクエリの場合、Discovery Proxyは上記の適切な即時応答を生成する必要があります。
* for any query for any name below the zone apex, for RRTYPEs SOA, NS, or DS, the Discovery Proxy MUST generate an immediate negative answer.
* ゾーンの頂点より下の名前に対するクエリの場合、RRTYPEs SOA、NS、またはDSの場合、ディスカバリプロキシは即時否定応答を生成する必要があります。
There are certain special DNS records that logically fall within the delegated Unicast DNS subdomain, but rather than mapping to their corresponding ".local" namesakes, they actually contain metadata pertaining to the operation of the delegated Unicast DNS subdomain itself. They do not exist in the corresponding ".local" namespace of the local link. For these queries, a Discovery Proxy MUST generate immediate answers, whether positive or negative, to avoid delays while clients wait for their query to be answered.
論理的に委任されたユニキャストDNSサブドメイン内にある特定の特別なDNSレコードがありますが、対応する「.local」の名前にマッピングするのではなく、実際には委任されたユニキャストDNSサブドメイン自体の操作に関連するメタデータが含まれます。ローカルリンクの対応する「.local」名前空間には存在しません。これらのクエリの場合、クライアントがクエリへの応答を待機する間の遅延を回避するために、ディスカバリプロキシはポジティブかネガティブかにかかわらず、即時の回答を生成する必要があります。
For example, if a Discovery Proxy implements Long-Lived Queries [RFC8764], then it MUST positively respond to "_dns-llq._udp.<zone> SRV" queries, "_dns-llq._tcp.<zone> SRV" queries, and "_dns-llq-tls._tcp.<zone> SRV" queries as appropriate. If it does not implement Long-Lived Queries, it MUST return an immediate negative answer for those queries, instead of passing those queries through to the local network as Multicast DNS queries and then waiting unsuccessfully for answers that will not be forthcoming.
たとえば、ディスカバリプロキシが長期間のクエリ[RFC8764]を実装する場合、「_ dns-llq._udp。<zone> SRV」クエリ、「_ dns-llq._tcp。<zone> SRV」クエリに積極的に応答する必要があります。および「_dns-llq-tls._tcp。<zone> SRV」クエリを適宜使用します。長期間有効なクエリを実装しない場合は、それらのクエリをマルチキャストDNSクエリとしてローカルネットワークに渡し、今後は返されない回答を失敗するのではなく、それらのクエリに対して即時否定応答を返す必要があります。
If a Discovery Proxy implements DNS Push Notifications [RFC8765], then it MUST positively respond to "_dns-push-tls._tcp.<zone>" queries. Otherwise, it MUST return an immediate negative answer for those queries.
Discovery ProxyがDNSプッシュ通知[RFC8765]を実装する場合、 "_ dns-push-tls._tcp。<zone>"クエリに積極的に応答する必要があります。それ以外の場合は、それらのクエリに対して即時否定応答を返す必要があります。
A Discovery Proxy MUST return an immediate negative answer for "_dns-update._udp.<zone> SRV" queries, "_dns-update._tcp.<zone> SRV" queries, and "_dns-update-tls._tcp.<zone> SRV" queries, since using DNS Update [RFC2136] to change zones generated dynamically from local Multicast DNS data is not possible.
Discovery Proxyは、「_ dns-update._udp。<zone> SRV」クエリ、「_ dns-update._tcp。<zone> SRV」クエリ、および「_dns-update-tls._tcp。<zone > SRV "クエリ。DNSアップデート[RFC2136]を使用してローカルマルチキャストDNSデータから動的に生成されたゾーンを変更することはできないためです。
If the network operator chooses to use address-based unicast Domain Enumeration queries for client configuration (see Section 5.2.1), and the network operator also chooses to delegate the enclosing reverse mapping subdomain to a Discovery Proxy, then that Discovery Proxy becomes responsible for serving the answers to those address-based unicast Domain Enumeration queries.
ネットワークオペレーターがクライアント構成（セクション5.2.1を参照）にアドレスベースのユニキャストドメイン列挙クエリを使用することを選択し、ネットワークオペレーターが包含リバースマッピングサブドメインを探索プロキシに委任することを選択した場合、その探索プロキシはこれらのアドレスベースのユニキャストドメイン列挙クエリへの回答を提供します。
As with the SRV metadata records described above, a Discovery Proxy configured with delegated reverse mapping subdomains is responsible for generating immediate (positive or negative) answers for address-based unicast Domain Enumeration queries, rather than passing them though to the underlying Multicast DNS subsystem and then waiting unsuccessfully for answers that will not be forthcoming.
上記のSRVメタデータレコードと同様に、委任された逆マッピングサブドメインで構成されたディスカバリープロキシは、アドレスベースのユニキャストドメイン列挙クエリに対する即時（正または負）の応答を生成します。次に、今後は行われない回答を待って失敗します。
The Discovery Proxy acts as the authoritative name server for designated subdomains, and if DNSSEC is to be used, the Discovery Proxy needs to possess a copy of the signing keys in order to generate authoritative signed data from the local Multicast DNS responses it receives. Offline signing is not applicable to Discovery Proxy.
Discovery Proxyは、指定されたサブドメインの信頼できるネームサーバーとして機能します。DNSSECを使用する場合、Discovery Proxyは、受信するローカルマルチキャストDNS応答から信頼できる署名付きデータを生成するために、署名鍵のコピーを所有する必要があります。オフライン署名はDiscovery Proxyには適用されません。
In DNSSEC, NSEC and NSEC3 records are used to assert the nonexistence of certain names, also described as "authenticated denial of existence" [RFC4034] [RFC5155].
DNSSECでは、NSECおよびNSEC3レコードを使用して、特定の名前が存在しないことを表明します。これは、「認証された存在の拒否」[RFC4034] [RFC5155]とも呼ばれます。
Since a Discovery Proxy only knows what names exist on the local link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names exist and which do not, a Discovery Proxy cannot programmatically synthesize the traditional NSEC and NSEC3 records that assert the nonexistence of a large range of names. Instead, when generating a negative response, a Discovery Proxy programmatically synthesizes a single NSEC record asserting the nonexistence of just the specific name queried and no others. Since the Discovery Proxy has the zone signing key, it can do this on demand. Since the NSEC record asserts the nonexistence of only a single name, zone walking is not a concern, and NSEC3 is therefore not necessary.
Discovery Proxyは、ローカルリンクに存在する名前をそれらのクエリを発行することによってしか認識せず、存在する名前と存在しない名前を見つけるためにすべての可能な名前に対してクエリを発行することは非現実的であるため、Discovery Proxyはプログラムで合成できません広範囲の名前の非存在を主張する従来のNSECおよびNSEC3レコード。代わりに、否定応答を生成するときに、Discovery Proxyは、特定の名前のみが存在し、他の名前は存在しないことを表明する単一のNSECレコードをプログラムで合成します。 Discovery Proxyにはゾーン署名鍵があるため、これをオンデマンドで実行できます。 NSECレコードは名前が1つだけ存在しないことを表明しているため、ゾーンウォーキングは問題ではなく、したがってNSEC3は必要ありません。
Note that this applies only to traditional immediate DNS queries, which may return immediate negative answers when no immediate positive answer is available. When used with a DNS Push Notification subscription [RFC8765], there are no negative answers, merely the absence of answers so far, which may change in the future if answers become available.
これは従来の即時DNSクエリにのみ適用されることに注意してください。これは、即時肯定応答が利用できない場合に即時否定応答を返す可能性があります。 DNSプッシュ通知サブスクリプション[RFC8765]と一緒に使用すると、否定的な回答はありません。これまでのところ回答が存在しないだけで、回答が利用可能になれば将来的に変更される可能性があります。
An IPv4-only host and an IPv6-only host behave as "ships that pass in the night". Even if they are on the same Ethernet [IEEE-3], neither is aware of the other's traffic. For this reason, each link may have _two_ unrelated ".local." zones: one for IPv4 and one for IPv6. Since, for practical purposes, a group of IPv4-only hosts and a group of IPv6-only hosts on the same Ethernet act as if they were on two entirely separate Ethernet segments, it is unsurprising that their use of the ".local." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments.
IPv4専用ホストとIPv6専用ホストは、「夜を過ごす船」として動作します。同じイーサネット[IEEE-3]上にある場合でも、どちらも相手のトラフィックを認識していません。このため、各リンクには無関係な「.local」が2つある場合があります。ゾーン：1つはIPv4用、もう1つはIPv6用です。実際には、同じイーサネット上のIPv4のみのホストのグループとIPv6のみのホストのグループは、2つのまったく別のイーサネットセグメント上にあるかのように動作するため、「。local」の使用は当然のことです。ゾーンは、2つの完全に別個のイーサネットセグメントに実際に存在する場合とまったく同じように発生します。
It will be desirable to have a mechanism to "stitch" together these two unrelated ".local." zones so that they appear as one. Such a mechanism will need to be able to differentiate between a dual-stack (v4/v6) host participating in both ".local." zones, and two different hosts: one IPv4-only and the other IPv6-only, which are both trying to use the same name(s). Such a mechanism will be specified in a future companion document.
これらの2つの無関係な「.local」を一緒に「ステッチ」するメカニズムを持つことが望ましいでしょう。ゾーンとして表示されます。このようなメカニズムは、両方の「.local」に参加しているデュアルスタック（v4 / v6）ホストを区別できる必要があります。ゾーン、および2つの異なるホスト：1つはIPv4のみ、もう1つはIPv6のみで、どちらも同じ名前を使用しようとしています。このようなメカニズムは、将来の関連ドキュメントで指定されます。
At present, it is RECOMMENDED that a Discovery Proxy be configured with a single domain name for both the IPv4 and IPv6 ".local." zones on the local link, and when a unicast query is received, it should issue Multicast DNS queries using both IPv4 and IPv6 on the local link and then combine the results.
現時点では、IPv4とIPv6の両方の「.local」に対して、1つのドメイン名でDiscovery Proxyを構成することをお勧めします。ローカルリンク上のゾーン、およびユニキャストクエリを受信すると、ローカルリンク上でIPv4とIPv6の両方を使用してマルチキャストDNSクエリを発行し、結果を組み合わせる必要があります。
A service proves its presence on a link by its ability to answer link-local multicast queries on that link. If greater security is desired, then the Discovery Proxy mechanism should not be used, and something with stronger security should be used instead such as authenticated secure DNS Update [RFC2136] [RFC3007].
サービスは、そのリンク上のリンクローカルマルチキャストクエリに応答する機能によって、リンク上での存在を証明します。より高いセキュリティが必要な場合は、ディスカバリプロキシメカニズムを使用しないでください。代わりに、認証された安全なDNSアップデート[RFC2136] [RFC3007]などのより強力なセキュリティを使用する必要があります。
The Domain Name System is, generally speaking, a global public database. Records that exist in the Domain Name System name hierarchy can be queried by name from, in principle, anywhere in the world. If services on a mobile device (like a laptop computer) are made visible via the Discovery Proxy mechanism, then when those services become visible in a domain such as "My House.example.com", it might indicate to (potentially hostile) observers that the mobile device is in the owner's home. When those services disappear from "My House.example.com", that change could be used by observers to infer when the mobile device (and possibly its owner) may have left the house. The privacy of this information may be protected using techniques like firewalls, split-view DNS, and Virtual Private Networks (VPNs), as are customarily used today to protect the privacy of corporate DNS information.
ドメインネームシステムは、一般的に言えば、グローバルなパブリックデータベースです。ドメインネームシステムの名前階層に存在するレコードは、原則として世界中のどこからでも名前でクエリできます。モバイルデバイス（ラップトップコンピューターなど）のサービスがDiscovery Proxyメカニズムを介して表示される場合、それらのサービスが「My House.example.com」などのドメインで表示されると、（潜在的に敵意のある）オブザーバーに示される可能性がありますモバイルデバイスが所有者の家にあること。これらのサービスが "My House.example.com"から消えると、オブザーバーはその変更を使用して、モバイルデバイス（およびおそらくその所有者）が家を出た可能性があることを推測できます。この情報のプライバシーは、ファイアウォール、スプリットビューDNS、仮想プライベートネットワーク（VPN）などの手法を使用して保護できます。これは、企業DNS情報のプライバシーを保護するために今日慣習的に使用されているものです。
The privacy issue is particularly serious for the IPv4 and IPv6 reverse zones. If the public delegation of the reverse zones points to the Discovery Proxy, and the Discovery Proxy is reachable globally, then it could leak a significant amount of information. Attackers could discover hosts that otherwise might not be easy to identify, and learn their host names. Attackers could also discover the existence of links where hosts frequently come and go.
プライバシーの問題は、IPv4およびIPv6の逆ゾーンでは特に深刻です。逆ゾーンのパブリック委任がディスカバリープロキシを指し、ディスカバリープロキシがグローバルに到達可能な場合、大量の情報が漏洩する可能性があります。攻撃者は、他の方法では識別が難しいホストを発見し、ホスト名を知る可能性があります。攻撃者は、ホストが頻繁に行き来するリンクの存在を発見する可能性もあります。
The Discovery Proxy could provide sensitive records only to authenticated users. This is a general DNS problem, not specific to the Discovery Proxy. Work is underway in the IETF to tackle this problem [RFC7626].
Discovery Proxyは、認証されたユーザーにのみ機密レコードを提供できます。これは一般的なDNSの問題であり、Discovery Proxyに固有のものではありません。 IETFでこの問題に取り組むための作業が進行中です[RFC7626]。
A remote attacker could use a rapid series of unique Unicast DNS queries to induce a Discovery Proxy to generate a rapid series of corresponding Multicast DNS queries on one or more of its local links. Multicast traffic is generally more expensive than unicast traffic, especially on Wi-Fi links [MCAST], which makes this attack particularly serious. To limit the damage that can be caused by such attacks, a Discovery Proxy (or the underlying Multicast DNS subsystem that it utilizes) MUST implement Multicast DNS query rate limiting appropriate to the link technology in question. For today's 802.11b/g/n/ac Wi-Fi links (for which approximately 200 multicast packets per second is sufficient to consume approximately 100% of the wireless spectrum), a limit of 20 Multicast DNS query packets per second is RECOMMENDED. On other link technologies like Gigabit Ethernet, higher limits may be appropriate. A consequence of this rate limiting is that a rogue remote client could issue an excessive number of queries resulting in denial of service to other legitimate remote clients attempting to use that Discovery Proxy. However, this is preferable to a rogue remote client being able to inflict even greater harm on the local network, which could impact the correct operation of all local clients on that network.
リモートの攻撃者は、一連の迅速な一意のユニキャストDNSクエリを使用して、Discovery Proxyに1つ以上のローカルリンクで対応する一連のマルチキャストDNSクエリを迅速に生成させる可能性があります。マルチキャストトラフィックは一般に、特にWi-Fiリンク[MCAST]で、ユニキャストトラフィックよりもコストがかかるため、この攻撃は特に深刻になります。このような攻撃によって引き起こされる可能性のある損傷を制限するには、ディスカバリプロキシ（またはそれが利用する基になるマルチキャストDNSサブシステム）が、問題のリンクテクノロジーに適したマルチキャストDNSクエリレート制限を実装する必要があります。今日の802.11b / g / n / ac Wi-Fiリンク（1秒間に約200のマルチキャストパケットでワイヤレススペクトルの約100％を消費するのに十分）の場合、1秒あたり20のマルチキャストDNSクエリパケットの制限をお勧めします。ギガビットイーサネットなどの他のリンクテクノロジーでは、より高い制限が適切な場合があります。このレート制限の結果、不正なリモートクライアントが過剰な数のクエリを発行し、そのDiscovery Proxyを使用しようとする他の正当なリモートクライアントにサービス拒否を引き起こす可能性があります。ただし、これは、ローカルネットワークにさらに大きな害を与えることができる不正なリモートクライアントよりも望ましい方法で、そのネットワーク上のすべてのローカルクライアントの正しい動作に影響を与える可能性があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、GJ、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、 <https://www.rfc-editor.org/info/rfc1918>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.
[RFC2308]アンドリュース、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<https://www.rfc-editor.org/info/rfc2308>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/info/rfc3927>.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4リンクローカルアドレスの動的構成」、RFC 3927、DOI 10.17487 / RFC3927、2005年5月、<https：//www.rfc-editor .org / info / rfc3927>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< https://www.rfc-editor.org/info/rfc4034>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<https： //www.rfc-editor.org/info/rfc5155>。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198] Klensin、J。およびM. Padlipsky、「Unicode Format for Network Interchange」、RFC 5198、DOI 10.17487 / RFC5198、2008年3月、<https://www.rfc-editor.org/info/rfc5198>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]チェシャーS.およびM.クロマル、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, <https://www.rfc-editor.org/info/rfc8490>.
[RFC8490]ベリス、R、チェシャー、S、ディキンソン、J、ディキンソン、S、レモン、T、プサテリ、「DNSステートフルオペレーション」、RFC 8490、DOI 10.17487 / RFC8490、2019年3月、 <https://www.rfc-editor.org/info/rfc8490>。
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", RFC 8765, DOI 10.17487/RFC8765, June 2020, <https://www.rfc-editor.org/info/rfc8765>.
[RFC8765] Pusateri、T。およびS. Cheshire、「DNS Push Notifications」、RFC 8765、DOI 10.17487 / RFC8765、2020年6月、<https://www.rfc-editor.org/info/rfc8765>。
[DNS-UL] Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 August 2018, <https://tools.ietf.org/html/draft-sekar-dns-ul-02>.
[DNS-UL] Cheshire、S.、T。Lemon、「Dynamic DNS Update Leases」、Work in Progress、Internet-Draft、draft-sekar-dns-ul-02、2018年8月2日、<https：// tools。 ietf.org/html/draft-sekar-dns-ul-02>。
[IEEE-1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014, <https://ieeexplore.ieee.org/document/6991462>.
[IEEE-1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462、2014、<https://ieeexplore.ieee.org / document / 6991462>。
[IEEE-3] IEEE, "IEEE Standard for Ethernet", DOI 10.1109/IEEESTD.2018.8457469, IEEE Std 802.3-2018, December 2008, <https://ieeexplore.ieee.org/document/8457469>.
[IEEE-3] IEEE、「IEEE Standard for Ethernet」、DOI 10.1109 / IEEESTD.2018.8457469、IEEE Std 802.3-2018、12月、<https://ieeexplore.ieee.org/document/8457469>。
[IEEE-5] IEEE, "Telecommunications and information exchange between systems - Local and metropolitan area networks - Part 5: Token ring access method and physical layer specifications", IEEE Std 802.5-1998, 1998, <https://standards.ieee.org/standard/802_5-1998.html>.
[IEEE-5] IEEE、「システム間の通信と情報交換-ローカルおよびメトロポリタンエリアネットワーク-パート5：トークンリングアクセス方法と物理層の仕様」、IEEE Std 802.5-1998、1998、<https://standards.ieee .org / standard / 802_5-1998.html>。
[IEEE-11] IEEE, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2016, December 2016, <https://standards.ieee.org/standard/802_11-2016.html>.
[IEEE-11] IEEE、「情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件-パート11：ワイヤレスLANメディアアクセスコントロール（MAC）および物理層（PHY）仕様」、IEEE Std 802.11 -2016、2016年12月、<https://standards.ieee.org/standard/802_11-2016.html>。
[MCAST] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, Internet-Draft, draft-ietf-mboned-ieee802-mcast-problems-11, 11 December 2019, <https://tools.ietf.org/html/draft-ietf-mboned-ieee802- mcast-problems-11>.
[MCAST] Perkins、C.、McBride、M.、Stanley、D.、Kumari、W.、J。Zuniga、「IEEE 802ワイヤレスメディアを介したマルチキャストの考慮事項」、進行中の作業、インターネットドラフト、ドラフト-ietf- mboned-ieee802-mcast-problems-11、2019年12月11日、<https://tools.ietf.org/html/draft-ietf-mboned-ieee802- mcast-problems-11>。
[OHP] "ohybridproxy - an mDNS/DNS hybrid-proxy based on mDNSResponder", commit 464d6c9, June 2017, <https://github.com/sbyx/ohybridproxy/>.
[OHP]「ohybridproxy-mDNSResponderに基づくmDNS / DNSハイブリッドプロキシ」、コミット464d6c9、2017年6月、<https://github.com/sbyx/ohybridproxy/>。
[REG-PROT] Cheshire, S. and T. Lemon, "Service Registration Protocol for DNS-Based Service Discovery", Work in Progress, Internet-Draft, draft-sctl-service-registration-02, 15 July 2018, <https://tools.ietf.org/html/draft-sctl-service-registration-02>.
[REG-PROT]チェシャーS.およびT.レモン、「DNSベースのサービスディスカバリ用のサービス登録プロトコル」、作業中、インターネットドラフト、draft-sctl-service-registration-02、2018年7月15日、<https ：//tools.ietf.org/html/draft-sctl-service-registration-02>。
[RELAY] Cheshire, S. and T. Lemon, "Multicast DNS Discovery Relay", Work in Progress, Internet-Draft, draft-sctl-dnssd-mdns-relay-04, 21 March 2018, <https://tools.ietf.org/html/draft-sctl-dnssd-mdns-relay-04>.
[リレー]チェシャーS.およびT.レモン、「マルチキャストDNSディスカバリリレー」、進行中の作業、インターネットドラフト、draft-sctl-dnssd-mdns-relay-04、2018年3月21日、<https：// tools。 ietf.org/html/draft-sctl-dnssd-mdns-relay-04>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<https://www.rfc-editor.org/info/rfc2132>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、DOI 10.17487 / RFC2136、April 1997 、<https://www.rfc-editor.org/info/rfc2136>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <https://www.rfc-editor.org/info/rfc3007>.
[RFC3007] Wellington、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、DOI 10.17487 / RFC3007、2000年11月、<https://www.rfc-editor.org/info/rfc3007>。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、DOI 10.17487 / RFC3492、2003年3月、<https://www.rfc-editor.org / info / rfc3492>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, <https://www.rfc-editor.org/info/rfc6760>.
[RFC6760] Cheshire、S。、およびM. Krochmal、「AppleTalk Name Binding Protocol（NBP）を置き換えるプロトコルの要件」、RFC 6760、DOI 10.17487 / RFC6760、2013年2月、<https：//www.rfc-editor .org / info / rfc6760>。
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015, <https://www.rfc-editor.org/info/rfc7558>.
[RFC7558] Lynn、K.、Cheshire、S.、Blanchet、M。、およびD. Migault、「Scalable DNS-Based Service Discovery（DNS-SD）/ Multicast DNS（mDNS）Extensions」の要件、RFC 7558、DOI 10.17487 / RFC7558、2015年7月、<https://www.rfc-editor.org/info/rfc7558>。
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7626] Bortzmeyer、S。、「DNSプライバシーに関する考慮事項」、RFC 7626、DOI 10.17487 / RFC7626、2015年8月、<https://www.rfc-editor.org/info/rfc7626>。
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788] Stenberg、M.、Barth、S。、およびP. Pfister、「Home Networking Control Protocol」、RFC 7788、DOI 10.17487 / RFC7788、2016年4月、<https://www.rfc-editor.org/info / rfc7788>。
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, <https://www.rfc-editor.org/info/rfc8375>.
[RFC8375] Pfister、P。およびT. Lemon、「Special-Use Domain 'home.arpa。'」、RFC 8375、DOI 10.17487 / RFC8375、2018年5月、<https://www.rfc-editor.org/info / rfc8375>。
[RFC8764] Cheshire, S. and M. Krochmal, "Apple's DNS Long-Lived Queries Protocol", RFC 8764, DOI 10.17487/RFC8764, June 2020, <https://www.rfc-editor.org/info/rfc8764>.
[RFC8764] Cheshire、S。およびM. Krochmal、「AppleのDNS長命クエリプロトコル」、RFC 8764、DOI 10.17487 / RFC8764、2020年6月、<https://www.rfc-editor.org/info/rfc8764> 。
[ROADMAP] Cheshire, S., "Service Discovery Road Map", Work in Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, 23 October 2018, <https://tools.ietf.org/html/draft-cheshire-dnssd-roadmap-03>.
[ロードマップ] Cheshire、S。、「Service Discovery Road Map」、Work in Progress、Internet-Draft、draft-cheshire-dnssd-roadmap-03、2018年10月23日、<https://tools.ietf.org/html/ draft-cheshire-dnssd-roadmap-03>。
[ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.
[ZC] Cheshire、S.およびD.H. Steinberg、「Zero Configuration Networking：The Definitive Guide」、O'Reilly Media、Inc.、ISBN 0-596-10100-7、2005年12月。
Some aspects of the mechanism specified in this document already exist in deployed software. Some aspects are new. This section outlines which aspects already exist and which are new.
このドキュメントで指定されているメカニズムの一部の側面は、デプロイされたソフトウェアにすでに存在しています。いくつかの側面は新しいです。このセクションでは、既存の側面と新しい側面について概説します。
Domain enumeration by the client ("b._dns-sd._udp.<zone>" queries) is already implemented and deployed.
クライアントによるドメイン列挙（ "b._dns-sd._udp。<zone>"クエリ）はすでに実装され、デプロイされています。
Performing unicast queries to the indicated discovery domain is already implemented and deployed.
指定されたディスカバリードメインへのユニキャストクエリの実行はすでに実装され、デプロイされています。
These are implemented and deployed in Mac OS X 10.4 Tiger and later (including all versions of Apple iOS, on all models of iPhones, iPads, Apple TVs and HomePods), in Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) and later.
これらは、Mac OS X 10.4 Tiger以降（すべてのバージョンのApple iOS、iPhone、iPad、Apple TV、HomePodsのすべてのモデルを含む）、Bonjour for Windows、およびAndroid 4.1 "Jelly Bean"（APIレベル16）以降。
Domain enumeration and unicast querying have been used for several years at IETF meetings to make terminal room printers discoverable from outside the terminal room. When an IETF attendee presses "Cmd-P" on a Mac, or selects AirPrint on an iPad or iPhone, and the terminal room printers appear, it is because the client is sending Unicast DNS queries to the IETF DNS servers. A walk-through giving the details of this particular specific example is given in Appendix A of the Roadmap document [ROADMAP].
ドメイン列挙とユニキャストクエリは、IETF会議で数年使用されており、ターミナルルームのプリンタをターミナルルームの外側から検出できるようにしています。 IETF参加者がMacで「Cmd-P」を押すか、iPadまたはiPhoneでAirPrintを選択し、ターミナルルームプリンターが表示されるのは、クライアントがIETF DNSサーバーにユニキャストDNSクエリを送信しているためです。この特定の例の詳細を説明するウォークスルーは、ロードマップドキュメント[ROADMAP]の付録Aに記載されています。
The Long-Lived Query mechanism [RFC8764] referred to in this specification exists and is deployed but was not standardized by the IETF. The IETF has developed a superior Long-Lived Query mechanism called DNS Push Notifications [RFC8765], which is built on DNS Stateful Operations [RFC8490]. DNS Push Notifications is implemented and deployed in Mac OS X 10.15 and later, and iOS 13 and later.
この仕様で言及されている長寿命クエリメカニズム[RFC8764]は存在し、デプロイされていますが、IETFによって標準化されていません。 IETFは、DNSステートフルオペレーション[RFC8490]に基づいて構築された、DNSプッシュ通知[RFC8765]と呼ばれる優れた長寿命クエリメカニズムを開発しました。 DNSプッシュ通知は、Mac OS X 10.15以降、およびiOS 13以降に実装および導入されています。
A minimal portable Discovery Proxy implementation has been produced by Markus Stenberg and Steven Barth, which runs on OS X and several Linux variants including OpenWrt [OHP]. It was demonstrated at the Berlin IETF in July 2013.
Markus StenbergとSteven Barthによって、最小限の移植可能なDiscovery Proxy実装が作成されました。これらは、OS XおよびOpenWrt [OHP]を含むいくつかのLinuxバリアントで実行されます。 2013年7月にベルリンIETFでデモされました。
Tom Pusateri has an implementation that runs on any Unix/Linux system. It has a RESTful interface for management and an experimental demo command-line interface (CLI) and web interface.
Tom Pusateriには、Unix / Linuxシステムで実行される実装があります。管理用のRESTfulインターフェイスと実験的なデモコマンドラインインターフェイス（CLI）とWebインターフェイスがあります。
Ted Lemon also has produced a portable implementation of Discovery Proxy, which is available in the mDNSResponder open source code.
Ted Lemonは、mDNSResponderオープンソースコードで利用可能なDiscovery Proxyのポータブルな実装も作成しました。
At the time of writing, existing APIs make multiple domains visible to client software, but most client user interfaces lump all discovered services into a single flat list. This is largely a chicken-and-egg problem. Application writers were naturally reluctant to spend time writing domain-aware user interface code when few customers would benefit from it. If Discovery Proxy deployment becomes common, then application writers will have a reason to provide a better user experience. Existing applications will work with the Discovery Proxy but will show all services in a single flat list. Applications with improved user interfaces will show services grouped by domain.
執筆時点では、既存のAPIにより複数のドメインがクライアントソフトウェアに表示されますが、ほとんどのクライアントユーザーインターフェイスは、検出されたすべてのサービスを単一のフラットリストにまとめます。これは主に鶏と卵の問題です。アプリケーション作成者は、ドメイン対応のユーザーインターフェースコードを書くことに時間を費やすことに消極的でした。 Discovery Proxyの展開が一般的になった場合、アプリケーション作成者はより良いユーザーエクスペリエンスを提供する理由があります。既存のアプリケーションはDiscovery Proxyで動作しますが、すべてのサービスを単一のフラットリストに表示します。ユーザーインターフェイスが改善されたアプリケーションでは、ドメインごとにグループ化されたサービスが表示されます。
Acknowledgments
謝辞
Thanks to Markus Stenberg for helping develop the policy regarding the four styles of unicast response according to what data is immediately available in the cache. Thanks to Anders Brandt, Ben Campbell, Tim Chown, Alissa Cooper, Spencer Dawkins, Ralph Droms, Joel Halpern, Ray Hunter, Joel Jaeggli, Warren Kumari, Ted Lemon, Alexey Melnikov, Kathleen Moriarty, Tom Pusateri, Eric Rescorla, Adam Roach, David Schinazi, Markus Stenberg, Dave Thaler, and Andrew Yourtchenko for their comments.
キャッシュですぐに利用できるデータに応じて、4つのスタイルのユニキャスト応答に関するポリシーの開発を支援してくれたMarkus Stenbergに感謝します。 Anders Brandt、Ben Campbell、Tim Chown、Alissa Cooper、Spencer Dawkins、Ralph Droms、Joel Halpern、Ray Hunter、Joel Jaeggli、Warren Kumari、Ted Lemon、Alexey Melnikov、Kathleen Moriarty、Tom Pusateri、Eric Rescorla、Adam Roachに感謝します。 David Schinazi、Markus Stenberg、Dave Thaler、Andrew Yourtchenkoのコメント。
Author's Address
著者のアドレス
Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America
スチュアートチェシャーアップル社ワンアップルパークウェイクパチーノ、カリフォルニア95014アメリカ合衆国
Phone: +1 (408) 996-1010
Email: cheshire@apple.com