TSIG（Transaction SIGnature）是RFC 2845中定義的計算機網絡協議。主要是它使域名系統（DNS）能夠驗證對DNS數據庫的更新。這是最常用的更新動態DNS或輔助/從屬DNS服務器。TSIG使用共享密鑰和單向哈希來提供一種密碼安全的方式來認證連接的每個端點被允許作出或響應DNS更新。

盡管對DNS的查詢通常可能在沒有身份驗證的情況下進行，但對DNS的更新必須經過身份驗證，因為它們會對Internet命名系統的結構進行持久更改。由于更新請求可能通過不安全的渠道（互聯網）到達，因此必須采取措施確保請求的真實性和完整性。使用由客戶端進行更新和DNS服務器共享的密鑰有助于確保更新請求的真實性和完整性。單向哈希函數用于防止惡意觀察者修改更新并轉發到目的地，從而確保消息從源到目的地的完整性。

TSIG協議中包含一個時間戳，用于防止記錄的響應被重用，這將使攻擊者違反TSIG的安全性。這要求在動態DNS服務器和TSIG客戶端包含一個準確的時鐘。由于DNS服務器連接到網絡，網絡時間協議可以提供準確的時間源。

DNS更新（如查詢）通常通過UDP傳輸，因為它要求比TCP更低的開銷。但是，DNS服務器同時支持UDP和TCP請求。

內容

??[?隱藏?]?

• 1實施
• 2TSIG的替代品
• 3另見
• 4參考
• 5外部鏈接

實現[?編輯]

RFC 2136中規定的更新是對DNS服務器的一組指令。其中包括標題，要更新的區域，必須滿足的先決條件以及要更新的記錄。TSIG添加最終記錄，其中包括時間戳和請求的散列。它還包括用于簽署請求的密鑰的名稱。RFC 2535提供了關于名稱形式的建議。

對TSIG成功更新的回應也將用TSIG記錄進行簽名。故障沒有經過簽名，以防止攻擊者使用特制的更新“探測器”了解有關TSIG密鑰的任何信息。

該的nsupdate程序可以使用TSIG做DNS更新。

TSIG記錄與更新請求中的其他記錄格式相同。這些字段的含義在RFC 1035中進行了描述。

TSIG記錄字段領域字節描述

名稱	最大。256	密鑰名稱，在客戶端和服務器上必須是唯一的
類型	2	TSIG（250）
類	2	任何（255）
TTL	4	0（因為TSIG記錄不能被緩存）
RDLENGTH	2	RDATA字段的長度
RDATA	變量	包含時間戳，算法和散列數據的結構

TSIG的替代品[?編輯]

雖然TSIG被廣泛部署，但協議還有幾個問題：

• 它需要將密鑰分發給每個必須更新的主機。
• HMAC-MD5摘要不再被認為是非常安全的。
• 沒有權威的層次。任何帶有密鑰的主機都可能更新任何記錄。

因此，已經提出了一些備選方案和擴展。

• RFC 2137指定使用公鑰?“SIG”DNS記錄的更新方法。持有相應私鑰的客戶端可以簽署更新請求。此方法與用于安全查詢的DNSSEC方法相匹配。但是，此方法已由RFC 3007棄用。
• 在2003年，RFC 3645提出將TSIG擴展為允許通用安全服務（GSS）安全密鑰交換方法，而不需要手動向所有TSIG客戶端分配密鑰。將公鑰作為DNS資源記錄（RR）分發的方法在RFC 2930中進行了規定，其中GSS作為此方法的一種模式。使用Windows?Kerberos服務器的修改后的GSS-TSIG由Microsoft Windows?Active Directory服務器和客戶端實現，稱為安全動態更新。結合使用RFC 1918的配置不當的DNS（沒有反向查找區域）?尋址，使用這種身份驗證方案的反向DNS更新將被全部轉發到根DNS服務器，并在此過程中增加到根DNS服務器的通信量[1]。有一個任播組處理這個流量，把它從根DNS服務器拿走[2]。
• 定義TSIG的RFC 2845只規定了一個允許的散列函數，128位的HMAC-MD5不再被認為是高度安全的。RFC 4635被散發以允許RFC 3174安全散列算法（SHA1）散列和FIPS?PUB 180-2?SHA-2散列來替代MD5。由SHA1和SHA-2生成的160位和256位摘要比由MD5生成的128位摘要更安全。
• RFC 2930定義了TKEY，它是一個DNS記錄，用于將密鑰從DNS服務器自動分發到DNS客戶端
• RFC 3645，它定義了GSS-TSIG，它使用gss-api和TKEY以gss-api模式自動分配密鑰
• 該DNSCurve提案有很多相似之處TSIG。

總結

以上是生活随笔為你收集整理的TSIG的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。