基于DNS的服務發(fā)現(xiàn)

胡浩

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

關(guān)鍵詞：DNS;服務發(fā)現(xiàn)

1.分布式DNS服務發(fā)現(xiàn)

mDNS多播DNS（mDNS）將DNS規(guī)范擴展到?jīng)]有基礎(chǔ)設(shè)施的網(wǎng)絡(luò)，其中設(shè)備查詢本地域，通過多播而不是通過單播查詢DNS服務器。

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

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

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

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

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

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

2.集中式DNS服務發(fā)現(xiàn)

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

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

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

參考文獻

[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