ゼロ構成ネットワーク

ゼロ構成ネットワーキング( zeroconf ) は、コンピュータまたはネットワーク周辺機器が相互接続されるときに、インターネット プロトコル スイート(TCP/IP)に基づいて使用可能なコンピュータ ネットワークを自動的に作成する一連のテクノロジです。手動のオペレータ介入や特別な構成サーバーは必要ありません。zeroconf がない場合、ネットワーク管理者は、動的ホスト構成プロトコル(DHCP) やドメイン ネーム システム(DNS)などのネットワーク サービスをセットアップするか、各コンピュータのネットワーク設定を手動で構成する必要があります。

Zeroconf は、ネットワーク デバイスへの数値ネットワーク アドレスの自動割り当て、コンピュータホスト名の自動配布と解決、印刷デバイスなどの ネットワーク サービスの自動検索という3 つのコア テクノロジに基づいて構築されています。

コンピュータ ネットワークでは、参加デバイスのネットワーク内の通信エンドポイントを識別するために、数値のネットワーク アドレスを使用します。これは、各電話を識別するために数字の文字列を割り当てる電話ネットワークに似ています。最新のネットワーク プロトコルでは、送信される情報は一連のネットワーク パケットに分割されます。各パケットには、送信元アドレスと送信先アドレスが含まれています。ネットワーク ルーターはこれらのアドレスを調べて、各ステップでデータ パケットを転送して宛先に向かう ための最適なネットワーク パスを決定します。

電話機に電話番号のラベルを貼るのと同様に、初期のネットワークではネットワーク デバイスにアドレス ラベルを貼るのが一般的でした。現代のネットワーク、特に必要なときだけデバイスの電源を入れる住宅用ネットワークの動的な性質により、初期化や管理にユーザーの介入を必要としない動的なアドレス割り当てメカニズムが求められています。これらのシステムは、ブランドやモデル番号など、機器メーカーが選択した共通名、またはユーザーが機器を識別するために選択した共通名を自動的に付けます。名前とアドレスは、ディレクトリ サービスに自動的に入力されます。

初期のコンピュータ ネットワークは、電気通信ネットワークのテクノロジに基づいて構築されていたため、プロトコルは 2 つのグループに分かれていました。ローカル デバイスをローカル エリア ネットワーク(LAN) に接続するためのプロトコルと、主に長距離通信を目的としたプロトコルです。後者のワイド エリア ネットワーク(WAN) システムは、集中型のセットアップが一般的で、ネットワーク管理者が手動でアドレスと名前を割り当てていました。LAN システムでは、これらのタスクの自動化が進む傾向があり、オペレータと管理者の介入を最小限に抑えて LAN に新しい機器を追加できるようになりました。

ゼロ構成 LAN システムの初期の例としては、Apple 社が 1980 年代の初期のMacintosh コンピュータ向けに導入したプロトコルであるAppleTalkがあります。Mac やこのプロトコルをサポートする他のデバイスは、接続するだけでネットワークに追加でき、それ以降の構成はすべて自動化されていました。ネットワーク アドレスは、AppleTalk アドレス解決プロトコル (AARP) と呼ばれるプロトコルを使用して各デバイスによって自動的に選択され、各マシンは Name Binding Protocol (NBP) と呼ばれるプロトコルを使用して独自のローカル ディレクトリ サービスを構築しました。NBP には、名前だけでなく、デバイスの種類や、物理的な場所や可用性など、ユーザーが提供する追加の情報も含まれていました。ユーザーは、デバイスの種類に基づいて名前をフィルターするアプリケーションChooserを使用して、ネットワーク上の任意のデバイスを検索できました。

インターネット プロトコル(IP) ネットワークでは、ネットワークのドメイン ネーム システムデータベースは、当初はネットワーク管理者によって手動で管理されていました。このデータベースの保守を自動化する取り組みにより、動的ホスト構成プロトコル(DHCP)などの自動化サービスを提供する新しいプロトコルが数多く導入されました。

ネットワーク上のホストには、同じネットワーク上の他のデバイスから一意に識別されるIP アドレスを割り当てる必要があります。一部のネットワークでは、新しいデバイスが追加されるとこれらのアドレスを割り当てる中央機関が存在します。このタスクを自動的に処理するメカニズムが導入され、現在では IPv4 と IPv6 の両方にアドレス自動構成のシステムが含まれており、デバイスは簡単なメカニズムを通じて安全に使用できるアドレスを決定できます。リンクローカル アドレス指定の場合、IPv4 は特別なブロック169.254.0.0 / 16 ^[1]を使用し、IPv6 ホストはプレフィックスfe80:: / 10を使用します。より一般的には、アドレスはDHCP サーバーによって割り当てられ、多くの場合、コンピューター ホストやルーターなどの一般的なネットワーク ハードウェアに組み込まれています。

ほとんどの IPv4 ホストは、DHCP サーバーが利用できない場合の最後の手段としてのみ、リンクローカル アドレスを使用します。それ以外の場合、IPv4 ホストは、グローバルまたはリンクローカルのすべての通信に DHCP によって割り当てられたアドレスを使用します。理由の 1 つは、IPv4 ホストはインターフェイスごとに複数のアドレスをサポートする必要がないことです (ただし、多くのホストはサポートしています)。もう 1 つの理由は、すべての IPv4 ホストが分散名前解決 (マルチキャスト DNSなど) を実装しているわけではないため、ネットワーク上の別のホストの自動構成されたリンクローカル アドレスを検出することが困難な場合があることです。別のホストの DHCP 割り当てアドレスを検出するには、分散名前解決か、この情報を持つユニキャスト DNS サーバーが必要です。一部のネットワークでは、DHCP によって割り当てられたホストとアドレスの情報で自動的に更新される DNS サーバーを備えています。

IPv6ホストはインターフェースごとに複数のアドレスをサポートする必要があります。さらに、グローバルアドレスが利用可能な場合でも、すべてのIPv6ホストはリンクローカルアドレスを設定する必要があります。IPv6ホストは、ルータ広告メッセージを受信したときに追加のアドレスを自己設定できるため、DHCPサーバーは不要になります。^[2]

IPv4 ホストと IPv6 ホストはどちらも、自動構成されたアドレスのホスト固有の部分をランダムに生成する場合があります。 IPv6 ホストは通常​​、最大 64 ビットのプレフィックスと、工場で割り当てられた 48 ビットのIEEE MAC アドレスから派生した 64 ビットの EUI-64 を組み合わせます。 MAC アドレスには、EUI-64 の基本的な特性であるグローバルに一意であるという利点があります。 IPv6 プロトコル スタックには、他のホストとの競合を回避するための重複アドレス検出も含まれています。 IPv4 では、この方法はリンク ローカル アドレス自動構成と呼ばれています。^[1]ただし、Microsoft はこれを自動プライベート IP アドレス指定(APIPA) ^[3]またはインターネット プロトコル自動構成( IPAC )と呼んでいます。 この機能は、少なくともWindows 98以降で Windows でサポートされています。^[4]

インターネットプロトコルは通信に IP アドレスを使用しますが、人間が簡単に使用できるものではありません。特に IPv6 では、手動で入力するのが難しい非常に長い数字の文字列が使用されます。この問題に対処するために、インターネットでは長い間 DNS を使用してきました。DNS では、人間が読める名前を IP アドレスに関連付けることができ、階層型データベースシステムからこれらの名前を検索するコードが含まれています。ユーザーはexample.orgなどのドメイン名を入力し、コンピューターの DNS ソフトウェアが DNS データベースを検索して IP アドレスを取得し、そのアドレスをプロトコルスタックに渡して通信を継続します。^[5]

DNS を使用してアドレスを検索するには、DNS サーバーの IP アドレスを知る必要があります。これは通常、ネットワーク上のデバイスの 1 つに既知のサーバーのアドレスを入力することで実現されます。初期のシステムでは、これは通常すべてのデバイスで必要でしたが、これは階層の 1 層上に押し上げられ、DHCP サーバーまたはインターネット サービス プロバイダーからこの情報を受信するケーブルモデムなどのブロードバンドデバイスにまで広がりました。これにより、ユーザー側の管理要件が軽減され、ゼロ構成アクセスの重要な要素が提供されます。^[5]

DNS は、ネーム サービスによって提供されるexample.orgなどの同じ管理領域内のデバイス グループに統一された名前を提供することを目的としていました。thirdfloorprinter.example.orgなどのローカル デバイスにアドレスを割り当てるには、通常、DNS サーバーへの管理者アクセスが必要であり、多くの場合手動で行われます。さらに、従来の DNS サーバーは、構成の変更を自動的に修正することは想定されていません。たとえば、プリンターをあるフロアから別のフロアに移動すると、ローカル DHCP サーバーによって新しい IP アドレスが割り当てられる場合があります。^[5]

自動構成の必要性に対応するため、Microsoft はNetBIOS ネーム サービスを実装しました。その一部であるComputer Browser Service は、 1992 年にはすでに Microsoft Windows for Workgroups 3.11 ^{[6]に搭載されていました。NetBIOS ネーム サービスは、単一のサブネットを持つネットワークでは構成が不要で、} WINSサーバーまたはアドレスの安全な自動登録をサポートする Microsoft DNS サーバーと組み合わせて使用​​できます。このシステムでは、非常に大規模なエンタープライズ ネットワークでも管理オーバーヘッドはわずかですが、ゼロではありません。NetBIOS が使用できるプロトコルは、 Linux および iOS でも使用できるオープン プロトコルのServer Message Block (SMB) スイート^[6]の一部ですが、Windows は通常、それをサポートする Windows クライアント間でネゴシエートできる、より広範囲のいわゆる方言をサポートしています。たとえば、サーバー オペレーティング システムまたはそれ以降のバージョンの Windows で実行される Computer Browser Service は、サーバー オペレーティング システムを実行していないサービスや古いバージョンの Windows を実行しているサービスよりも、いわゆるマスター ブラウザーとして選出されます。^[6]

2000年にビル・マニングとビル・ウッドコックはマルチキャストドメイン名サービス^[7]を説明し、これがAppleとMicrosoftによる実装を生み出しました。両方の実装は非常によく似ています。AppleのマルチキャストDNS（mDNS）は標準化過程提案RFC  6762として公開されていますが、Microsoftのリンクローカルマルチキャスト名前解決（LLMNR）は情報RFC  4795として公開されています。LLMNRはWindows Vista以降のすべてのWindowsバージョンに含まれており^[8]、MicrosoftのIPv4経由のNetBIOSネームサービスの並行代替として、またNetBIOSはIPv6では利用できないためIPv6上の代替として機能します。Appleの実装は、 2002年からMac OS X v10.2でBonjourサービスとして利用できます。Bonjour実装（mDNSResponder）はApache 2オープンソースライセンス^[9]の下で利用可能で、 Android Jelly Bean以降^[10]に同じライセンスの下で 含まれています。

Windows での NetBIOS サービスまたは LLMNR サービスの使用は基本的に自動です。これは、標準の DNS クライアント API を使用すると、解決される名前 (名前がローカル名であるかどうか)、有効なネットワーク構成 (有効な DNS サフィックスなど)、および (企業ネットワークでは) 有効なポリシー (LLMNR または NetBIOS が無効になっているかどうか) に応じて、NetBIOS または LLMNR のいずれかが使用されるためです。ただし、開発者は、個々のアドレス検索でこれらのサービスをバイパスすることを選択できます。

mDNS と LLMNR プロトコルは、名前解決のアプローチに若干の違いがあります。mDNS では、ネットワーク デバイスがローカルDNS名前空間内のドメイン名を選択し、特別なマルチキャスト IP アドレスを使用してそれをアナウンスできます。これにより、トップレベル ドメイン localに特別なセマンティクスが導入され、^[11] IETF の一部のメンバーはこれを問題視しています。^[12]現在の LLMNR ドラフトでは、ネットワーク デバイスが任意のドメイン名を選択できるようになっていますが、これは IETF の一部のメンバーによってセキュリティ リスクと見なされています。^[13]次のセクションで説明するように、mDNS は DNS-SD と互換性がありますが、LLMNR は互換性がありません。^[14]

mDNS、LLMNR などの名前サービスは、デバイスのタイプや状態に関する情報を提供しません。たとえば、近くのプリンタを探しているユーザーは、プリンタに「Bob」という名前が付けられていると、検索が困難になる可能性があります。サービス検出は、デバイスに関する追加情報を提供します。サービス検出は、Apple のName Binding Protocolや Microsoft のNetBIOSのように、名前サービスと組み合わされることがあります。

Windows の NetBIOS は、ファイル共有やプリンターなどのサービスをアドバタイズするために、ネットワーク上の個々のホストをサポートしています。また、たとえば、ネットワーク プリンターが、プリンター デバイスとそれがサポートする関連サービスを共有するホストとして自分自身をアドバタイズすることもサポートしています。デバイスの接続方法 (ネットワークに直接接続するか、共有するホストに接続するか) と、サポートされているプロトコルによって異なります。ただし、それに接続する Windows クライアントは、 NetBIOS を使用してSSDPまたはWSD を使用することを好む場合があります。NetBIOS は、Windows 上のプロバイダーの 1 つで、機能検出と呼ばれるより一般的な検出プロセスを実装しています。これには、PnP、レジストリ、NetBIOS、SSDP、WSD ^[15]の組み込みプロバイダーが含まれます。これらのうち、前者 2 つはローカル専用で、後者 3 つはネットワーク デバイスの検出をサポートします。これらのいずれも、ローカル サブネットで使用するために構成する必要はありません。NetBIOS は、従来、企業向けの高価なプリンターでのみサポートされていましたが、Wi-Fi または Ethernet を備えたエントリー レベルのプリンターの中には、NetBIOS をネイティブにサポートしているものもあり、非常に古いオペレーティング システムでも構成なしでプリンターを使用できます。

Web Services Dynamic Discovery ( WS-Discovery ) は、ローカル ネットワーク上のサービスを見つけるためのマルチキャスト検出プロトコルを定義する技術仕様です。TCP および UDP ポート 3702 で動作し、IP マルチキャスト アドレス239.255.255.250を使用します。名前が示すように、ノード間の実際の通信は、Web サービス標準、特にSOAP-over-UDP を使用して行われます。Windows は、 Web Services for DevicesおよびDevices Profile for Web Servicesの形式でこれをサポートしています。HP や Brother のプリンターなど、多くのデバイスがこれをサポートしています。

DNS-SD（DNSサービス検出^[16]）を使用すると、クライアントはサービスインスタンスの名前付きリストを検出し、標準のDNSクエリを使用してそれらのサービスをホスト名に解決できます。この仕様は、既存のユニキャストDNSサーバーおよびクライアントソフトウェアと互換性がありますが、ゼロ構成環境でmDNSでも同様に機能します。各サービスインスタンスは、DNS SRV^[17]およびDNS TXT^[18]レコードを使用して記述されます。クライアントは、そのサービスタイプの名前のDNS PTR^[18]レコードを照会することにより、特定のサービスタイプで使用可能なインスタンスのリストを検出します。サーバーは、それぞれがSRV/TXTレコードペアに対応する、<サービス>.<ドメイン>形式の0個以上の名前を返します。SRVレコードはインスタンスを提供するドメイン名に解決され、TXTにはサービス固有の構成パラメータを含めることができます。クライアントは、ドメイン名のA/AAAAレコードを解決してサービスに接続できます。

サービスタイプは先着順で提供されます。サービスタイプレジストリは元々DNS-SD.orgによって管理されていましたが^[16]、その後IANAのDNS SRVレコードレジストリに統合されました。^[19]

1997年、スチュアート・チェシャーは、サービス検出機能の不足に対処するため、Appleの成熟した名前バインディングプロトコルをIPネットワークに適合させることを提案した。 ^[20]チェシャーはその後Appleに加わり、 mDNSとDNSベースのサービス検出に関するIETFのドラフト提案を作成し、AppleTalkからIPネットワークへの移行をサポートした。 2002年、AppleはRendezvous ^[21] （後にBonjourに改名）という名前で両方のプロトコルの実装を発表した。これはMac OS X 10.2で初めて搭載され、10.1で使用されていたサービスロケーションプロトコル（SLP）に取って代わった。^{[要出典] 2013年、提案は}RFC  6762 ^[22]およびRFC  6763 ^[23]として承認された。

mDNS は、ユニキャスト DNSに似たパケットを使用してホスト名を解決しますが、マルチキャスト リンク経由で送信されます。各ホストは、既知のマルチキャスト アドレスに送信される mDNS ポート 5353 をリッスンし、その.localホスト名 (例: A、AAAA、CNAME )のDNS レコードの要求を IP アドレスに解決します。mDNS クライアントがローカル ホスト名を IP アドレスに解決する必要がある場合、その名前の DNS 要求を既知のマルチキャスト アドレスに送信します。対応する A/AAAA レコードを持つコンピューターは、その IP アドレスで応答します。mDNS マルチキャスト アドレスは、IPv4 の場合は224.0.0.251 、 IPv6 リンク ローカル アドレスの場合は ff02::fbです。

DNSサービスディスカバリ（別名DNS-SD）要求は、mDNSを使用して送信して、ゼロ構成DNS-SDを生成することもできます。^[24]これは、DNS PTR、SRV、TXTレコードを使用して、サービスタイプのインスタンス、それらのインスタンスのドメイン名、およびそれらのインスタンスに接続するためのオプションの構成パラメータをアドバタイズします。ただし、SRVレコードは.localドメイン名に解決できるようになり、mDNSはそれをローカルIPアドレスに解決できます。

DNS-SDは、Apple製品、ほとんどのネットワークプリンター、DebianやUbuntuを含む多くのLinuxディストリビューション^[25]、およびさまざまなオペレーティングシステム用の多くのサードパーティ製品で使用されています。たとえば、Safari、iChat、メッセージなど、Appleが作成した多くのOS Xネットワークアプリケーションは、DNS-SDを使用して近くのサーバーとピアツーピアクライアントを見つけることができます。Windows 10には、JavaScriptを使用して作成されたアプリケーションのDNS-SDのサポートが含まれています。^[26]個々のアプリケーションは、オペレーティングシステムの古いバージョンで独自のサポートを組み込むことができるため、Windows上のほとんどのインスタントメッセージングおよびVoIPクライアントはDNS-SDをサポートしています。一部のUnix、BSD、およびLinuxディストリビューションにもDNS-SDが含まれています。たとえば、Ubuntuは、基本ディストリビューションにmDNS/DNS-SD実装であるAvahiを出荷しています。

UPnP には、サービス検出を目的としたいくつかのプロトコル コンポーネントがあります。

シンプル サービス検出プロトコル(SSDP) は、 Windows XP以降で使用される UPnP プロトコルです。SSDP は、サービス タイプURIと一意のサービス名 (USN) を提供する HTTP 通知アナウンスを使用します。サービス タイプは、Universal Plug and Play Steering Committee によって規制されています。SSDP は、Brother などの多くのプリンター、NAS、アプライアンス メーカーによってサポートされています。また、特定のブランドのネットワーク機器や、その背後にあるホスト コンピューターがアプリケーションに穴を開ける可能性がある多くのSOHOファイアウォール アプライアンスでもサポートされています。また、ホーム シアター PCシステムでも、ホスト コンピューターとメディア センター間のメディア交換を容易にするために 使用されています。

Digital Living Network Alliance (DLNA) は、ネットワーク デバイスの検出に UPnP を使用する別の標準スイートです。DLNA には、テレビ、NAS デバイスなど、DLNA をサポートするデバイスを製造する大手メーカーが多数あります。DLNA は、すべての主要なオペレーティング システムでサポートされています。DLNA サービス検出は、SSDP の上に階層化されています。

SLP は、 Hewlett-Packardのネットワークプリンタ、Novell、およびSun Microsystemsによってサポートされています。SLP はRFC  2608 およびRFC 3224で説明されており、 SolarisとLinux の 両方で実装が可能です。

AllJoynは、IoT デバイスからフルサイズのコンピューターまで、さまざまなデバイスに対応したオープンソース ソフトウェア スタックで、ネットワーク (Wi-Fi、イーサネット) やその他のリンク (Bluetooth、ZigBee など) 上のデバイスの検出と制御に使用されます。mDNS とHTTP over UDP およびその他のプロトコルを使用します。

どこでサービスを受けるかを判断するためのSLP標準であるRFC  2608は、1999年6月にSVRLOC IETFワーキンググループによって公開されました。^[27]

ネットワーク上のアイテムのアドレスを選択するための標準であるRFC  3927は、2005年3月にIETF Zeroconfワーキンググループによって公開されました。このグループには、Apple、Sun、Microsoftの担当者が含まれていました。^[28]

LLMNRはIETF DNSEXTワーキンググループに正式に採用されるよう提出されたが、合意を得られず、2007年1月に情報RFC  4795として公開された^。[29]

LLMNR がインターネット標準になることができず、mDNS/DNS-SD が LLMNR よりもはるかに広く使用されていることから、Apple は IETF から mDNS/DNS-SD 仕様を Informational RFC として公開するよう依頼されました。^{[引用が必要]}

2013 年 2 月に、mDNS と DNS-SD は、標準化過程提案RFC  6762 とRFC  6763 として公開されました。

mDNS はユニキャスト DNS とは異なる信頼モデルで動作するため、指定された DNS サーバーではなくネットワーク全体を信頼するため、同じブロードキャスト ドメイン内の任意のシステムによるスプーフィング攻撃に対して脆弱です。SNMP や他の多くのネットワーク管理プロトコルと同様に、攻撃者はmDNSを使用してネットワークとそのマシンの詳細な情報を迅速に取得することもできます。^[30]このため、アプリケーションは DNS-SD/mDNS を介してリモート ホストを検出して解決した後、そのホストへのトラフィックを認証して暗号化する必要があります ( RSA、SSHなど経由)。LLMNR も同様の脆弱性を抱えています。^[31]

Apple のBonjour は、mDNS と DNS Service Discovery を使用します。Apple は、 Mac OS X 10.1と10.2の間で、推奨される zeroconf テクノロジを SLP から mDNS と DNS-SD に変更しましたが、SLP は引き続き Mac OS X でサポートされています。

AppleのmDNSResponderにはCとJavaのインターフェースがあり^{[32] 、BSD、Apple Mac OS X、Linux、その他の}POSIXベースのオペレーティングシステム、およびMS Windowsで利用できます。WindowsのダウンロードはAppleのWebサイトから入手できます。^[33]

AvahiはLinuxとBSD用のZeroconf実装です。IPv4LL 、mDNS、DNS-SDを実装しています。ほとんどのLinuxディストリビューションに含まれており、一部のディストリビューションではデフォルトでインストールされています。nss-mdnsと組み合わせて実行すると、ホスト名解決も可能になります。^[34]

Avahi は、Bonjour と歴史的な mDNS 実装 Howl をエミュレートするバイナリ互換性ライブラリも実装しているため、これらの実装を使用するように作成されたソフトウェアも、エミュレーション インターフェイスを通じて Avahi を利用できます。

Microsoft Windows CE 5.0 には、Microsoft 独自の LLMNR 実装が含まれています。

Systemd はmDNS と LLMNR の両方を実装しますsystemd-resolved。

ホストに IP アドレスを割り当てるための DHCP サーバーが利用できない場合、ホストは独自のリンク ローカル アドレスを選択できます。リンク ローカル アドレスを使用すると、ホストはこのリンクを介して通信できますが、ローカルのみです。他のネットワークやインターネットにアクセスすることはできません。使用可能なリンク ローカル IPv4 アドレス実装はいくつかあります。

• Apple Mac OSとMS Windowsは、 Windows 98とMac OS 8.5（ともに1998年リリース）以降、リンクローカルアドレスをサポートしています。 ^[1] Appleはオープンソース実装をDarwin bootpパッケージでリリースしました。
• Avahi には、 avahi-autoipd ツールに IPv4LL の実装が含まれています。
• ゼロ信頼IP（zcip）^[35]
• BusyBox はシンプルな IPv4LL 実装を埋め込むことができます。
• Busyboxから分岐したStablebox ^[36]は、わずかに改良されたlladという名のIPv4LL実装を提供している。
• Zeroconf ^[37]は、 Arthur van Hoffによる短縮版実装であるSimple IPv4LLをベースにしたパッケージです。^[38]

上記の実装はすべて、リンクローカル IP アドレスのみを扱う DHCPクライアント用のスタンドアロン デーモンまたはプラグインです。別のアプローチとしては、新規または既存の DHCP クライアントにサポートを組み込むことが挙げられます。

• Elvis PfützenreuterはuDHCPクライアント/サーバーのパッチを作成しました。^[39]
• dhcpcd ^[40]はLinuxおよびBSD用のオープンソース DHCPクライアントであり、 IPv4LLサポートが含まれています。NetBSDには標準で含まれています。

どちらの実装も、ARP応答のブロードキャスト^[41]や既存のネットワーク接続の切断などのカーネルの問題には対処していません。

• Bonjour 睡眠プロキシ
• ワイヤレスゼロ構成
• ピア名解決プロトコル(PNRP)

注記

出典

• JmDNS、ソースフォージmDNS/DNS-SD の純粋な Java 実装です。
• pyZeroConf、Source forge、2015 年 7 月 11 日mDNS/DNS-SD の純粋なPython実装です。
• Mono.Zeroconf、Mono プロジェクトは、クロスプラットフォーム (Linux、MS Windows、Apple Mac)、Zeroconf 用の統合 Mono/.NET ライブラリであり、Bonjour と Avahi の両方をサポートしています。
• WxServDisc、Source forge、2013 年 6 月 13 日外部依存関係のないクロスプラットフォームの wxWidgets ベースのサービス検出モジュール。
• チェシャー、スチュアート、マルチキャスト DNS (ドラフト)。
• チェシャー、スチュアート、DNS ベースのサービス検出仕様 (ドラフト)、DNS-SD。
• Cheshire, Stuart、Zeroconf (技術トーク)、オリジナル(ビデオ)から2008-03-02 にアーカイブ、2006-03-08 に取得。
• チェシャー、スチュアート、ゼロコンフインターネット下書きも含む。
• DNS-SDDNSベースのサービス検出
• 「マルチキャスト DNS」。
• サービスロケーションプロトコル、バージョン2。doi : 10.17487 / RFC2608。RFC 2608 。
• スタインバーグ、ダニエル、チェシャー、スチュアート、ゼロ構成ネットワーキング：決定版ガイド、オライリー。