DNSSD官方文件翻譯
目錄
1.介紹............................................... 3 .....
2.本文件中使用的約定和術語............... 5
3.設計目標.............................................. ...... 5
4.服務例項列舉（瀏覽）......................... 6
4.1
4.2。使用者介面演示................................ 9
4.3。名稱的內部處理................................. 9
5.服務例項解決.................................... 10
6. DNS-SD TXT記錄的資料語法............................. 11
6.1。DNS TXT記錄的通用格式規則.................. 11
6.2。DNS-SD TXT記錄的大小.................................... 12
6.3。DNS-SD中使用的DNS TXT記錄格式規則.....................
6.4。DNS-SD金鑰/值對中的金鑰規則.................. 14
6.5。DNS-SD金鑰/值對中的值規則................ 16
6.6。示例TXT記錄........................................ 17
6.7。版本日............................................... 17
6.8。具有多個TXT記錄的服務例項............... 18
7.服務名稱.............................................. .... 19
7.1。選擇性例項列舉（子型別）................. 21
7.2。服務名稱長度限制................................ 23
8.旗艦命名.............................................. ..25
9.服務型別列舉....................................... 27
10.使用資訊填充DNS ........................... 27
11.瀏覽和註冊域的發現（域枚 舉）................................................ ..28
12. DNS附加記錄生成.............................. 30
12.1。PTR記錄............ 30
12.2。SRV記錄.............................................. 30
12.3。TXT記錄.............................................. 31
12.4。其他記錄型別....................................... 31
13.工作例項.............................................. 31
13.1.從dns-sd.org上宣傳了哪些網頁？..... 31
13.2.有哪些印表機配置網頁？.......... 31
13.3.如何訪問名為“服務發現”的網頁
？.............................................. 32
14. IPv6注意事項........................................... 32
15.安全考慮........................................ 32
16. IANA注意事項........................................... 32
17.致謝............................................... 33
18.參考文獻............................................... ..... 33
18.1。規範性參考文獻..................................... 33
18.2。資訊參考................................... 34
附錄A.使用DNS作為服務基礎的基本原理
發現............................................. 37
附錄B.服務例項的訂購名稱元件.......... 38
B.1。語義結構........................................ 38
B.2。網路效率........................................ 39
B.3。操作靈活性................................... 39
附錄C.所見即所得.......................... 40
附錄D.出廠預設名稱的選擇....................... 42
附錄E.域名系統中的名稱編碼.............. 44
附錄F.“連續實時更新”瀏覽模型............... 45
附錄G.部署歷史.................................... 47
1.簡介
本文件指定了DNS資源記錄的命名方式以及如何結構化以促進服務發現。給定一種客戶端正在尋找的服務以及客戶端正在尋找該服務的域，這種機制允許客戶使用標準DNS查詢發現一個服務期望的命名例項列表。此機制稱為基於DNS的服務發現，或DNS-SD。
本文件建議不要更改DNS訊息的結構和操作程式碼，響應程式碼，資源記錄型別或任何其他新的DNS協議值。
本文件指定了特定的服務例項可以使用DNS SRV [RFC2782]和DNS TXT [RFC1035]記錄進行描述。SRV記錄的名稱格式為“<Instance>.<Service>.<Domain>”
並提供服務例項能夠到達的目標主機和埠。同名的DNS TXT記錄提供了額外的有關此例項的資訊，使用鍵/值對的結構化形式，在第6節中描述。客戶端發現使用DNS查詢的 PTR [RFC1035]，記錄的名為“<Service>。<Domain>”的給定服務型別的可用例項的列表，它返回一組零個或多個名稱，這些名稱是上述的DNS SRV / TXT記錄對。
此規範與多播DNS以及今天現有的單播DNS伺服器和客戶端軟體相容[RFC6762]。
與多播DNS一起使用時，DNS-SD可以提供零配置操作 - 只需連線DNS-SD / mDNS裝置，其服務即可
在本地連結上公佈，沒有進一步的使用者互動[ZC]。
當與傳統的單播DNS一起使用時，一些配置通常是必需的---- 例如使用DNS配置的裝置
應該在其中宣傳其服務和配置的域，並且使用DNS更新[RFC2136] [RFC3007]鍵配置它以便授予它許可權
這樣做。在極少數情況下，例如防火牆背後不需要DNS更新金鑰的安全的企業網路 ，
零配置操作可以通過簡單地讓裝置以從網路中學習的預設註冊域中的服務來註冊它來實現（參見第11節“瀏覽和註冊域的發現”）， 但這是例外，通常安全憑證是需要執行DNS更新的。
請注意，當使用DNS-SD與單播DNS時，單播DNS-SD服務不必由相同的DNS伺服器硬體提供， 這是目前提供組織的傳統主機名查詢服務。雖然很多人只想到“DNS”只是將主機名對映到IP地址的上下文，事實上，“DNS是一個普通的（如果有些限制）分層資料庫，並且可以儲存幾乎任何型別的資料，幾乎用於任何目的“[RFC2181]”，通過委託“_tcp”和“_udp”子域，所有工作負載相關的 DNS-SD可以轉載到不同的機器上。這種在網路上處理主DNS伺服器上的DNS-SD靈活性，對於管理員的自由裁量權來說，是使用DNS的好處之一。
即使將DNS-SD功能委託給其他機器，使用DNS的好處仍然存在：它是成熟的技術，很好理解，來自不同的多個獨立實現供應商，關於該主題的各種書籍，以及在其運營中經驗豐富的勞動力。相反，採用其他一些服務發現技術需要每一個世界上的網站，用於安裝，學習，配置，操作和維護一些全新的，不熟悉的伺服器軟體。面對這些障礙，似乎不太可能是任何其他服務發現技術可能希望的以及DNS已經享受了的無處不在的部署競爭。有關進一步的討論，請參閱附錄A， “使用DNS作為服務發現基礎的基本原理”。
本文件面向兩個受眾：為開發人員建立在網路上提供或訪問服務的應用軟體，併為開發人員建立DNS-SD庫來實現廣告和發現機制。對於兩個觀眾，理解整個文件很有幫助。對於開發者建立應用程式軟體，本文件提供了指導選擇例項名稱，服務名稱和其他方面在創造良好的整體使用者體驗方面的作用。但是，瞭解用於提供的基礎DNS機制服務發現設施可幫助應用程式發現這些潛在機制的能力和侷限性（例如，姓名長度限制）。對於編寫軟體的庫開發人員構建DNS記錄（宣傳服務）並生成DNS查詢（發現和使用服務）來說，瞭解 最終的使用者體驗目標可幫助他們提供可滿足的API的那些目標。
2.本文件中使用的約定和術語
關鍵詞“必須”，“絕不”，“必須”，“必須”，“不要”， “應該”，“不應該”，“推薦”，“可能”和“可選” 檔案的解釋如“使用的關鍵詞”中所述RFC指示需求級別“[RFC2119]。
3.設計目標
在良好的服務發現協議需要的許多屬性中有三個特別重要的是：
（i）查詢在 某些邏輯域的某種型別的服務的能力，並在響應中接收命名列表例項（網路瀏覽或“服務例項列舉”）。
（ii）給定一個特定的命名例項，有效的將該例項名稱解析為客戶端所需的資訊的能力，需要實際使用該服務，即IP地址和埠 數字，至少（服務例項解決方案）。
（iii）例項名稱應相對持久。如果是使用者從可用選項列表中選擇其預設印表機，今天，明天他們仍然可以打印出來--即使印表機 - IP地址和/或埠號以及服務駐留已經改變 - 沒有使用者（或他們的 軟體）必須重複步驟（i）（初始網路瀏覽）第二次。
另外，如果要成功，還要進行服務發現，協議應該如此簡單，幾乎可以實現任何裝置能夠實施IP不應該有任何實施的麻煩
服務發現軟體也是如此。
在其餘部分中將更詳細地討論這些目標文獻。更全面地處理服務發現要求可在“替換議定書的要求”中找到
AppleTalk名稱繫結協議（NBP）“[RFC6760]。那個檔案。借鑑二十年的運作經驗 AppleTalk開發了一個通用要求列表，廣泛適用於任何潛在的服務發現協議。
4.服務例項列舉（瀏覽）
傳統DNS SRV記錄[RFC2782]對於定位很有用，當所有例項都是特定型別服務的例項時有效地區分提供相同的服務的客戶。
例如，SRV記錄了（假設的）名稱“_http._tcp.example.com。” 將允許客戶端發現實現“_http._tcp”服務（即Web伺服器）
“example.com”。域的伺服器 。沒有說明的假設是所有這些伺服器提供相同的網頁集， 客戶端使用哪個伺服器並不重要，只 要它隨機選擇一個 根據DNS中規定的權重和優先順序規則的SRV規範[RFC2782]。
其他型別服務的例項並不容易互換。如果一個文書處理應用程式要查詢（假設）SRV記錄“_ipp._tcp.example.com”。先找到互 聯網列表，然後，在Example Co.的列印協議（IPP）[RFC2910]的印表機隨意挑選一個並在上面列印什麼可能不是使用者想要 的。
本節的其餘部分描述瞭如何使用SRV記錄以稍微不同的方式，允許使用者發現給定型別服務的所有可用例項的名稱，然後從該列表中選擇他們想要的特定例項。
4.1.結構化服務例項名稱
本文件借用了來自DNS SRV記錄邏輯服務命名語法和語義，但增加了一個間接級別。代替 請求名稱 為“_ipp._tcp.example.com。”的“SRV”型別的記錄， 客戶端請求型別為“PTR”的記錄（指標從一個名稱到DNS名稱空間中的另一個）[RFC1035]。
實際上，如果想到域名“_ipp._tcp.example.com”。類似於檔案中目錄的絕對路徑系統，DNS-SD的PTR查詢類似於執行該目錄列表以查詢它包含的所有條目。（記住那個與路徑名相比，域名以相反的順序表示 - 絕對路徑名稱以左側的根開頭並從左到右被讀取，而完全限定的域名以 右邊的根，從右到左閱讀。如果完全合格域名“_ipp._tcp.example.com”.表達為 檔案系統路徑名，它將是“/ com / example / _tcp / _ipp”。）
此PTR查詢名稱“<Service>。<Domain>”的結果是一組由零個或多個PTR記錄給出的服務例項名稱形成：
服務例項名稱= <例項>。<服務>。<域>
有關元件按此順序排列的原因，請參閱附錄B，“服務例項名稱元件的排序”。
4.1.1.例項名稱
服務例項名稱的<Instance>部分是使用者 - 友好名稱由任意Net-Unicode文字[RFC5198]組成。它不得包含ASCII控制字元（位元組 值0x00-0x1F和0x7F）[RFC20]但允許包含任何字元， 沒有限制，包括空格，大寫，小寫， 標點符號 - 包括點 - 重音字元，非 羅馬文字， 以及可以使用Net-Unicode表示的任何其他內容。對於討論為什麼<Instance>名稱應該是使用者可見的，使用者 - 友好的名稱，而不是一個看不見的機器生成的不透明識別符號，請參閱附錄C，“所見即所得”。
正在提供的服務名稱的<Instance>部分網路應該由使用者設定服務來配置，所以他或她可能會給它一個資訊豐富的名字。但是， 該裝置或服務不應要求使用者在其可以使用之前配置名稱。在許多情況下，預設名稱的合理選擇允許在沒有任何手冊的情況下訪 問裝置或服務的完全配置。預設名稱應該簡短具描述性的，不應該包括裝置的媒體訪問控制（MAC）地址，序列號或任何類似 的不可理解的十六進位制字串，試圖使名稱全域性唯一。 討論為什麼<Instance>名稱不需要（並且應該是）在工廠製造獨特，見 附錄D，“選擇出廠預設名稱“。
儲存服務例項名稱的<Instance>部分直接在DNS中作為規範預組合的單個DNS標籤 UTF-8 [RFC3629]“Net-Unicode”（Unicode規範化表格C） [RFC5198]文字。有關文字編碼的進一步討論，請參閱 附錄E，“域名系統中的名稱編碼”。
DNS標籤目前的長度限制為63個八位位元組。UTF-8 編碼要求每個Unicode字元最多需要四個八位位元組，這意味著在最壞的情況 下，名稱的<Instance>部分可以 限制為十五個Unicode字元。但是，Unicode 在UTF-8編碼下具有較長八位位元組長度的字元往 往是較少使用的，往往是那些傳達每個角色的更有意義。
請注意常用的16位Unicode Basic中的任何字元， 多語言平面[Unicode6]可以編碼不超過三個UTF-8編碼的八位位元組。這意味著例項名稱可以 包含多達21個漢字字元，這是一個足夠表達大多數用途的名稱。
4.1.2.服務名稱
服務例項名稱的<Service>部分由一對DNS標籤組成，遵循已為SRV制定的慣例記錄[RFC2782]。該貨幣對的第一個標籤是下劃線字元後跟服務名稱[RFC6335]。服務名稱識別服務的作用以及它的應用程式協議。第二個標籤是“_tcp”（通過TCP應用程式協議）或“_udp”執行的協議（對於所有其他協議）。更多有關詳細資訊，請參見第7節“服務名稱”。
4.1.3.網站域名
服務例項名稱的<Domain>部分指定DNS 這些名稱在其中註冊的子域。它可能是 “local。”，意思是“連結本地多播DNS”[RFC6762]，或者它可能是 傳統的單播DNS域名，例如“ietf.org。”， “cs.stanford.edu.”或“eng.us.ibm.com”。因為服務例項
名稱不是主機名，它們不受通常規則的約束 ，主機名[RFC1033] [RFC1034] [RFC1035]和富文字服務 允許並鼓勵子域名，例如：
Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .
此外，因為服務例項名稱不受主機名的限制的約束，本文件建議它們儲存在DNS中，並通過線路進行通訊，編碼為 直接的規範預組合UTF-8 [RFC3629]“Net-Unicode”（Unicode標準化表C）[RFC5198]文字。在有些情況下 DNS伺服器返回有問題名稱的否定響應， 客戶端軟體可以選擇重試查詢 ，使用“Punycode”演算法[RFC3492]將UTF-8名稱轉換為IDNA“A-label” [RFC5890]，從頂級標籤開始，然後反覆發出查詢，如果成功連續更多標籤翻譯成IDNA A標籤，如果它已將所有標籤轉換為IDNA A標籤，查詢仍然失敗。
4.2.使用者介面演示
服務例項列舉PTR查詢產生的名稱 在列表中呈現給使用者以供使用者選擇一個（或 更多）。通常，僅顯示第一個標籤（使用者友好的
名稱的<Instance>部分）。
在常見情況下，<Service>和<Domain>已為客戶端軟體所知，這些首先是使用者由隱式提供，通過指示正在尋找的服務的行為， 以及尋找它的領域。請注意， 處理響應的軟體應注意不要使其無效，但是，假設它是*可能的，儘管很少見， 在一個域中的服 務列舉以返回服務在 一個不同的領域的名稱。同樣，使用子型別時（參見第7.1節， “選擇性例項列舉”）發現的<Service>
例項可能與請求的<Service>不完全相同 。
有關服務例項列舉（瀏覽）的進一步討論的使用者介面注意事項，請參閱附錄F“'連續實時更新'瀏覽模型'。
一旦使用者選擇了所需的命名例項，可以立即使用服務例項名稱，或者將其儲存在某些例項名稱中作為持久的使用者偏好資料結 構，供將來使用，具體取決於適用於有關申請的內容。
4.3.名稱的內部處理
如果客戶端軟體採用服務例項名稱的<Instance>，<Service>和<Domain> 部分，並在內部連線它們一起變成單個字串，然後因為<Instance>部分是允許包含適當的任何字元，包括點， 必須採取預防措施以確保DNS標籤邊界妥善儲存。客戶端軟體可以以各種方式執行此操作方式，如角色逃避。
本檔案推薦如果連線服務例項名稱的三部分，<Instance>部分中的任何點都是按照文字檔案的慣例DNS約定進行轉義： 在字 麵點前面加反斜槓（所以“.”變為“\.”）。 同樣，<Instance>部分中的任何反斜槓也應該是通過在它們之前使用反斜槓進行轉義（因此“\”變為“\\”）。
完成此操作後，名稱的三個組成部分可能是安全的級聯。反斜槓轉義允許名稱中的文字點（轉義）與標籤分隔符點（不是
轉義），可以安全地傳遞生成的連線字串成標準DNS API，如res_query（），它將按預期方式解釋反斜槓轉義字串。
5.服務例項解決方案
當客戶需要聯絡由服務例項名稱標識的特定服務時 （此前通過服務例項列舉（瀏覽）發現），它將在SRV和TXT記錄查詢那個 名字。服務的SRV記錄給出埠號和可以找到服務的目標主機名。TXT記錄提供有關服務的其他資訊，如第6節“DNS-SD TXT記錄的資料語法”中所述。
SRV記錄非常有用，因為它們不再需要預先分配的埠號。只有65535個TCP埠號可用。傳統上，這些埠號分配一個應用程式協議[RFC6335]。一些協議，如X Window系統有一個分配了64個TCP埠的塊（6000-6063）。用一個 給定的機器的給定服務的 每個不同例項的 不同TCP埠 是完全合理的，但分配每個應用程式它自己的大靜態範圍（與X Window系統一樣）不是一個實用的方法。在任何給定的主機上，大多數TCP埠 保留用於在它的一生中永遠不會在該特定主機上執行的服務 。這是有限埠空間的利用率很低 。使用SRV記錄允許每個主機動態地分配其可用的 埠號為那些實際執行的 需要它們的主機的服務，然後 通過SRV記錄通告分配的埠號。根據需要分配可用的偵聽埠號 ，在每個主機上本地允許可用的埠空間比今天的集中式全球空間更好地利用 分配。
如果返回多個SRV，客戶端必須
正確解釋優先順序和權重欄位 - 即更低 -
編號優先伺服器應優先使用 -
編號優先順序伺服器，優先順序相同的伺服器應該是
根據其相對權重按比例隨機選擇。然而，
在絕大多數情況下，單個廣告的DNS-SD服務
例項僅由一個SRV記錄描述，並且在此常見中
如果SRV記錄的優先順序和權重欄位都應該是
設為零。
6. DNS-SD TXT記錄的資料語法
通過Service Instance Enumeration發現的某些服務可能需要
不僅僅是一個IP地址和埠號來完全識別
服務例項。例如，通過舊的Unix LPR進行列印
（埠515）協議[RFC1179]通常指定佇列名稱[BJP]。
此佇列名稱通常較短且含糊不清，無需顯示
給使用者。它應該被視為與IP地址相同的方式
和埠號：它是定址的另一個組成部分
識別特定服務例項所需的資訊
由某些硬體提供。同樣，檔案伺服器
可能有多個卷，每個卷都由自己的卷名標識。一個
Web伺服器通常具有多個頁面，每個頁面由其自己標識
URL。在這些情況下，必要的附加資料儲存在a中
與SRV記錄同名的TXT記錄。具體性質
這些額外資料以及如何使用，是服務 -
依賴，但TXT記錄中資料的整體語法是
標準化，如下所述。
除了SRV之外，每個DNS-SD服務都必須有一個TXT記錄
記錄，具有相同的名稱，即使該服務沒有額外的
要儲存的資料和TXT記錄包含不超過一個零
位元組。這允許服務明確控制時間
生存（TTL）其（空）TXT記錄，而不是使用
預設負快取TTL，否則將用於“否”
錯誤無答案“DNS響應。
請注意，強制TXT記錄的此要求適用
專用於DNS-SD服務廣告，即所宣傳的服務
使用本文件中指定的PTR + SRV + TXT約定。它是
一般而言，不是SRV記錄的要求。DNS SRV記錄
資料型別[RFC2782]仍然可以在其他任何情況下使用
隨附PTR和TXT記錄的要求。
6.1。DNS TXT記錄的通用格式規則
DNS TXT記錄最長可達65535（0xFFFF）位元組。總數
length由資源記錄頭中給出的長度表示
在DNS訊息中。沒有辦法直接從資料中分辨出來
它有多長（例如，開始時沒有長度計數，或者
最後終止NULL位元組）。
注意，使用Multicast DNS [RFC6762]時最大包大小
是9000位元組，包括IP頭，UDP頭和DNS訊息
標題，對TXT記錄的大小施加上限
大約8900位元組。在實踐中，DNS-SD的最大合理大小
TXT記錄甚至比這小，通常最多幾百
位元組，如下面6.2節所述。
DNS TXT記錄中的資料格式是一個或多個
字串，在記憶中打包在一起，沒有任何間隙或
字對齊的填充位元組。
DNS TXT記錄中每個組成字串的格式為a
單長度位元組，後跟0-255位元組的文字資料。
TXT記錄的這些格式規則在第3.3.14節中定義
DNS規範[RFC1035]並不特定於DNS-SD。
DNS-SD指定應儲存哪些資料的附加規則
用於DNS-SD服務廣告的那些組成字串，
即，當用於描述使用PTR + SRV + TXT通告的服務時
本檔案中規定的慣例。
不允許包含零字串的空TXT記錄[RFC1035]。
DNS-SD實現絕不能發出空的TXT記錄。DNS-SD
客戶必須將以下內容視為等效：
o包含單個零位元組的TXT記錄。
（即一個空字串。）
o空（零長度）TXT記錄。
（這不是嚴格合法的，但應該收到，應該
被解釋為與單個空字串相同。）
或沒有TXT記錄。
（即，NXDOMAIN或無錯誤 - 無應答響應。）
6.2。DNS-SD TXT記錄大小
典型DNS-SD TXT記錄的總大小旨在很小
- 200位元組或更少。
在更多資料合理的情況下（例如，LPR列印[BJP]），
將總大小保持在400位元組以下應該允許它適合a
單個512位元組DNS訊息[RFC1035]。
在極端情況下，即使這還不夠，保持大小
低於1300位元組的TXT記錄應該允許它適合單個
1500位元組的乙太網資料包。
此處不推薦使用大於1300位元組的TXT記錄
時間。
請注意，一些乙太網硬體供應商提供晶片組
多播DNS [RFC6762]解除安裝，以便計算機可以睡眠和
仍然可以在網路上發現。這種早期版本
晶片組有時非常有限：例如，有些是
（不明智地）限於處理不大於256位元組的TXT記錄
（這意味著具有更大TXT記錄的LPR印表機服務確實如此
不行）。開發人員應該意識到這種現實世界的侷限性，
並且應該理解即使是完美的硬體
能夠具有更低限制的低功率和睡眠模式。
6.3。DNS-SD中使用的DNS TXT記錄格式規則
DNS-SD使用DNS TXT記錄來儲存任意鍵/值對
傳達有關指定服務的其他資訊。每
鍵/值對被編碼為其自身的組成字串
DNS TXT記錄，格式為“key = value”（不帶引號）
分數）。第一個'='字元的所有內容都是關鍵（Section
6.4）。第一個'='字元後的所有內容到了結尾
string（包括後續的'='字元，如果有的話）是值
（第6.5節）。該值周圍不需要引號，
即使它包含空格，'='字元或其他標點符號
分數。每個作者定義用於發現的DNS-SD配置檔案
特定型別服務的例項應定義基本集
對該型別的服務有效的鍵/值屬性。
在TXT記錄中使用這種標準化的鍵/值語法
稍後通過定義來擴充套件這些基本定義更容易
其他命名屬性。如果實現看到未知金鑰
在服務TXT記錄中，它必須默默地忽略它們。
目標主機名和服務的TCP（或UDP）埠號是
在SRV記錄中給出。此資訊 - 目標主機名和
埠號 - 不得使用中的鍵/值屬性進行復制
TXT記錄。
DNS-SD TXT記錄的意圖是傳達少量的
有關服務的有用的其他資訊。理想情況下，它應該
客戶端無需檢索此附加資訊
在它可以有用地建立與服務的連線之前。為一個
精心設計的應用程式協議，即使沒有資訊
在TXT記錄中，應該是可能的，只知道
與之通訊的主機名，埠號和協議
聽取過程然後執行版本或功能 -
協商確定任何進一步的選擇或能力
服務例項。例如，連線到AFP（Apple
檔案協議）伺服器[AFP]通過TCP，客戶端進入
協議與伺服器交換以確定哪個版本的AFP
伺服器實現以及哪些可選功能或功能（如果
任何）是可用的。
對於具有足夠帶內版本和功能的協議 -
談判時，TXT記錄中的任何資訊都應視為a
效能優化 - 當客戶端發現許多例項時
一項服務，TXT記錄允許客戶瞭解一些基本知識
有關每個例項的資訊，而無需開啟TCP
連線到每個服務例項並詢問每個服務例項
分別。這樣做時要小心，以確保
TXT記錄中的資訊與資訊一致
將通過TCP連線的客戶端檢索。
有些舊協議不提供功能協商
能力，在這些情況下，傳達必要的可能是有用的
TXT記錄中的資訊。例如，使用LPR列印時
[RFC1179]，LPR協議沒有為客戶端提供任何方法
確定特定的印表機是否接受PostScript，是什麼
PostScript的版本等。在這種情況下，嵌入是合適的
這個資訊在TXT記錄[BJP]中，因為替代方案
會更糟 - 將書面指示傳遞給使用者，
奧術手動配置“/ etc / printcap”檔案等
關於為TXT記錄定義什麼鍵的工程決策
需要根據每種服務型別的具體情況來決定。
對於某些服務型別，適合傳遞資訊
通過TXT記錄以及（或代替）通過帶內記錄
應用程式協議中的通訊。
6.4。DNS-SD金鑰/值對中的金鑰規則
關鍵必須至少是一個字元。DNS-SD TXT記錄字串
以'='字元開頭（即，金鑰丟失）必須是
默默地忽略了。
金鑰不應超過九個字元。這是因為
為了網路，保持小包大小是有益的
效率。將DNS-SD與多播DNS結合使用時
[RFC6762]這很重要，因為多播流量尤其如此
在802.11無線網路[IEEEW]上很昂貴，但即使在使用時也是如此
傳統的單播DNS，保持TXT記錄較小有助於改善
響應將適合原始DNS 512位元組的可能性
大小限制[RFC1035]。此外，DNS TXT的每個組成串
記錄限制為255個位元組，因此過長的金鑰會減少
可用於該鍵值的空間。
鍵/值對中的鍵可以與單個字元一樣短。
關鍵名稱只需要在上下文中是唯一且明確的
定義它的服務型別。意圖是一個關鍵名稱
僅僅是機器可讀的識別符號，而不是人類可讀的識別符號
文章詳細討論了引數的用途，用
網頁的URL，提供規範的更多詳細資訊。
為了便於開發和除錯，使用金鑰可能很有價值
名稱是助記符文字名稱，但過於冗長的鍵
浪費和低效，因此建議保留它們
到九個字元或更少。
鍵的字元必須是可列印的US-ASCII值（0x20-0x7E）
[RFC20]，不包括'='（0x3D）。
金鑰中的空格是重要的，無論是前導，尾隨還是中
中間 - 所以除非你真的想要，否則不要包含任何空格
那。
解釋金鑰時會忽略大小寫，因此“papersize = A4”，
“PAPERSIZE = A4”和“Papersize = A4”都是相同的。
如果DNS-SD TXT記錄字串中沒有“=”，則它是a
布林屬性，簡單地標識為存在，沒有值。
給定的密鑰不應該在TXT記錄中出現多次。該
這種簡化規則的原因是為了促進建立
將TXT記錄解析為內部資料的客戶端庫
結構（例如從中對映的雜湊表或字典物件）
鍵值）然後使客戶端可以使用該抽象
碼。給定金鑰可能不會出現多次的規則
簡化這些抽象，因為它們不需要支援
為給定鍵返回多個值的情況。
如果客戶端收到包含相同金鑰的TXT記錄
曾經，然後客戶端必須默默地忽略除第一個之外的所有
該屬性的出現。對於客戶端實現
從頭到尾處理DNS-SD TXT記錄，放置鍵/值
使用金鑰作為雜湊表金鑰對進入雜湊表，這個
表示如果實現嘗試新增新的鍵/值對
進入表並查詢已存在相同鍵的條目，
然後應該靜默地丟棄新增的新條目。
通過搜尋來檢索鍵/值對的客戶端實現
請求金鑰的TXT記錄應從中搜索TXT記錄
開始並簡單地返回他們找到的第一個匹配鍵。
在檢查給定金鑰的TXT記錄時，因此有四個
可能返回的結果類別：
*屬性不存在（缺席）
*屬性存在，沒有價值
（例如，“passreq” - 此服務所需的密碼）
*屬性存在，空值
（例如，“PlugIns =” - 伺服器支援外掛，但沒有外掛
目前安裝）
*屬性存在，非空值
（例如，“PlugIns = JPEG，MPEG2，MPEG4”）
每個作者定義DNS-SD配置檔案以發現例項
特定型別的服務應該定義這些解釋
不同種類的結果。例如，對於某些鍵，可能存在
自然的真/假布林解釋：
*缺席暗示'假'
*現在暗示'真'
對於其他鍵，定義其他語義可能是明智的，例如
值/無值/未知：
*有價值的現在意味著價值。
（例如，四色噴墨印表機的“顏色= 4”）
或六色噴墨印表機的“顏色= 6”）
*空值表示'假'。
（例如，不是彩色印表機）
*缺席意味著'未知'。
（例如，列印伺服器連線到某個未知的印表機，其中
列印伺服器實際上不知道印表機是否顏色或
不是 - 這給使用者帶來了非常糟糕的體驗，應該是
儘可能避免）
請注意，這是一個假設的例子，而不是實際的例子
DNS-SD網路印表機使用的鍵/值鍵，記錄在案
在“Bonjour印刷規範”[BJP]中。
6.5。DNS-SD金鑰/值對中的值規則
如果DNS-SD TXT記錄字串中有“=”，則表示一切
在第一個'='到字串結尾之後是值。價值
可以包含任何八位值，包括'='。值絕不可以
用其他引號或任何類似的標點符號括起來;
任何引號，或前導或尾隨空格，都是其中的一部分
值。
該值是不透明的二進位制資料。通常是特定的價值
屬性將是US-ASCII [RFC20]或UTF-8 [RFC3629]文字，但它是
合法的值是任何二進位制資料。
通用除錯工具通常應顯示所有屬性值
作為十六進位制轉儲，伴隨文字並顯示UTF-8
這些位元組的解釋，除了屬性之外
除錯工具具有嵌入的知識，其價值是其他的
一種資料。
定義DNS-SD配置檔案的作者不應該進行一般轉換
使用十六進位制將二進位制屬性資料型別轉換為可列印文字
表示，Base-64 [RFC4648]或Unix到Unix（UU）編碼，
僅僅是為了使資料看起來是可列印的文字
在通用除錯工具中看到。這樣做只會讓人失望
TXT記錄的大小，實際上不再生成資料
對於在通用除錯工具中檢視它的人來說，這是可以理解的。
6.6。示例TXT記錄
下面的TXT記錄包含三個語法上有效的鍵/值
字串。（這些鍵/值對的含義，如果有的話）將取決於
關於有關服務的定義是
使用它們。）
-------------------------------------------------------
| 0x09 | key = value | 0x08 | 紙= A4 | 0x07 | passreq |
-------------------------------------------------------
6.7。版本日
建議定義DNS-SD配置檔案的作者包括
“txtvers = x”形式的屬性，其中“x”是十進位制版本
US-ASCII [RFC20]文字中的數字（例如，“txtvers = 1”或“txtvers = 8”），
在他們的定義中，並要求它成為第一個鍵/值對
TXT記錄。TXT記錄中的此資訊可用於
幫助客戶保持與舊版本的向後相容性
實現，如果有必要更改或更新
隨著時間的推移。即使個人資料作者沒有
預計任何未來不相容的變化的必要性，有一個
TXT記錄中的版本號應提供有用的保險
不相容的變