基于DNS的服務發現

胡浩

摘 要：基于DNS的服務發現（DNS-SD）是一種可以使用標準DNS編程接口、數據包格式和服務器瀏覽機制。DNS-SD定義了如何命名和排列dns記錄，即指針（Ptr）、服務定位器（Srv）、IPv6地址（AAAA）和文本（Txt），目的是方便在子域中的服務發現。DNS-SD不改變DNS消息、操作代碼、記錄類型或任何其他DNS協議值的結構。廣義地說，DNS-SD服務器包含服務列表，服務具有<Instance>.<ServiceType>.<Domain>的標準格式。

關鍵詞：DNS;服務發現

1.分布式DNS服務發現

mDNS多播DNS（mDNS）將DNS規范擴展到沒有基礎設施的網絡，其中設備查詢本地域，通過多播而不是通過單播查詢DNS服務器。

mDNS在DNS規范中添加了一個.local域，一個公開的多播端口和地址，并定義了如何管理單個查詢的多個結果。在基于分布式dns服務發現中，設備可以使用mDNS通告發布有關它們提供的服務和資源的信息，這些通告具有與標準dns查詢格式相同的格式，但被發送到IPv6多播地址FF02：FB。這些通告可以包括具有域名的服務類型和名稱（PTR記錄）（在mDNS的情況下是本地域）、主機名和端口（SRV記錄）、地址（AAAA記錄）以及設備的擴展描述（TXT記錄）。

在樓宇自動化控制中，智能燈將通過在其mDNS通告中包含ptr、srv和txt記錄來發布其服務。PTR記錄定義了服務與服務實例的映射，例如服務為_light._sub.coap._udp.test.local，其中coap._udp為服務的類型，定義了所使用的協議（例如，CoAP/UDP），_light為服務的子類型表示被訪問的資源（比如燈）。test.local為本地域，其服務的實例是LIGHT1_bc._sub.coap._udp.test.local，其中LIGHT_bc為實例的名稱，可以為同一服務定義多個ptr以啟用不同的查詢格式。

服務實例LIGHT1_bc的SRV記錄描述了如何訪問服務。這包括主機名URI（例如，light1.test.local）、端口（例如，5683）、優先級（其中零表示最大優先級），以及具有相同優先級的記錄的相對權重。

txt記錄總是與srv一起定義的，以便提供更多的描述。TXT記錄提供了資源的路徑（path=/lt/1/on）和資源類型（rt=ipso.lt.on）。

一旦相關的客戶端（如智能開關）擁有記錄中包含的所有信息，它將使用所獲得的信息（解析后）來訪問燈資源。

如果客戶端沒有收到mDNS通告，分布式DNS服務發現還允許通過向多播地址發送標準DNS查詢來發現服務器中的服務。比如查找其本地域中的任何燈，dns查詢將只包含ptr，ptr用來表示智能開關只希望找到匹配特定的服務（_light._sub._coap._udp）的設備，智能燈將用服務實例（例如，LIGHT1_bc）的PTR記錄答復智能開關。智能開關接收智能燈服務的實例后，需要解析出智能燈的URI。為此，智能開關會請求智能燈提供服務實例對應的SRV和TXT，SRV和TXT將提供IP地址、端口、路徑和其他相關的信息。最后，客戶端設備智能開關就可以使用獲得的信息與已發現的智能燈的功能進行交互。

2.集中式DNS服務發現

在集中式DNS服務發現中，假定DNS-SD服務器可在網絡基礎結構中使用。DNS-SD服務器存儲其子域中的設備提供的服務。與CoAP RD類似，這些設備先必須在DNS-SD中注冊它們的服務。但與CoAP RD不同的是，沒有定義標準的DNS注冊消息。注冊消息的最常見實現來源于蘋果的Bonjour，它重用mDNS發布消息來在DNS-SD中注冊服務描述，因此DNS-SD以mDNS為基礎，如果DNS-SD地址未知，注冊消息可以通過多播地址發送（這和mDNS類似），如果DNS-SD地址已知，可以直接發送到DNS服務器的單播地址。或者，設備可以通過瀏覽公開的服務_b._DNS-SD.udp.local（_b為服務的子類型，DNS-SD.udp為服務的類型）來發現DNS-SD服務器地址。最后，當DNS-SD服務器處于不同的子網中時，必須使用全局DNS-SD進程。

目前，全局DNS-SD無法自動發現遠程服務器的地址。因此，假設DNS-SD服務器地址已經已知，例如通過IPv6路由器通告，智能燈將單播發送發布消息到全局DNS服務器以注冊服務。因為遠程DNS-SD服務器與智能燈不在同一個子網，服務器將無法觀察該網絡內的服務和資源的變化，例如，如果由于連通性的丟失而無法再到達智能燈。為了解決這個問題，IETF定義了一種稱為動態DNS更新的同步機制[1]。動態dns更新利用dnsd服務器記錄中增加生存期參數。每t分鐘更新一次的記錄（t=30分鐘是建議的值）。如果資源在此時間范圍內未更新，則將從DNS-SD中刪除該資源。此外，IETF還定義DNS長壽命查詢，允許客戶端觀察服務注冊中的任何更改[2]。

最后，DNS-SD可以在公開的服務_services._dnssd._udp._local（_services為服務的子類型，DNS-SD.udp為服務的類型）下自動注冊所有服務。這允許瀏覽在目錄中注冊的所有服務，CoAP的/wellknow/core與此類似，一旦注冊過程結束，任何設備都可以通過DNS查詢查找到DNS-SD服務器的服務。與分布式DNS不同，來自DNS-SD服務器的單個響應包括網絡中與請求類型匹配的所有注冊服務。在接收到服務實例后，解析過程必須通過全局DNS-SD服務器執行。

參考文獻

[1] P. Vixie，S. Thomson，Y. Rekhter and J. Bound. Dynamic Updates in the Domain Name System（DNS UPDATE），Internet Engineering Task Force，RFC 2136. 1997

[2] S. Cheshire，M. Krochmal，K. Sekar. DNS Long-Lived Queries