TSIG (Transaction Signature) is a DNS security mechanism defined in RFC 8945 that authenticates DNS messages between two parties sharing a secret key and keyed hash, primarily protecting zone transfers and dynamic updates without encrypting the content. The mechanism requires both sides to be configured with matching key names, algorithms, and secrets, and includes timestamp validation to prevent replay attacks while relying on synchronized system clocks. Operational risks include poor key management practices, clock drift between servers, and the need for explicit access rules to enforce TSIG requirements, making proper documentation, rotation, and monitoring essential for maintaining reliable DNS communications.
TSIGの仕組み
TSIGは、共有秘密鍵と鍵付きハッシュを使用して、DNSメッセージが鍵を保持する当事者から送信されたものであり、転送中に改ざんされていないことを証明します。双方とも、事前に同じ鍵名、アルゴリズム、および秘密鍵が設定されている必要があります。
- 鍵の共有:管理者が秘密鍵を生成し、両方のサーバー、またはクライアントとサーバーの両方で、同じ鍵名、アルゴリズム、および秘密鍵を設定します。
- メッセージへの署名:送信者は、DNSメッセージと、タイムスタンプを含む特定のTSIGフィールドに対して鍵付きハッシュを計算し、その結果をTSIGレコードとしてメッセージに追加します。
- 署名の検証:受信側は名前で鍵を検索し、ハッシュを再計算して、受信したハッシュと比較します。一致しない場合、メッセージは拒否されます。
- 時刻の確認:受信側は、署名付きタイムスタンプが許容時間枠内に収まっているかどうかも確認します。これにより、キャプチャされたメッセージのリプレイが制限されます。
- 応答への署名:受信側は同じ鍵を使用して返信に署名するため、リクエスト送信者はその回答が期待したサーバーから送信されたものであることを確認できます。
TSIGはメッセージの認証と完全性を保護しますが、メッセージを暗号化することはありません。共有秘密鍵に依存しているため、公開解決ではなく、既知の当事者間の通信に適しており、双方の時計は適度に同期されている必要があります。
TSIGに関する一般的な問題
TSIGにはタイムスタンプが含まれており、受信側は許容時間枠外のメッセージを拒否します。サーバーの時計にずれが生じると、キーが正しくても、転送や更新が「時間エラー」で失敗します。通常、NTPを使用して双方の時計を同期させることで、この問題は解決します。
キー名、アルゴリズム、およびシークレットは、双方で完全に一致している必要があります。シークレットの入力ミス、アルゴリズムの不一致、またはキー名の綴りの違いがあると、「署名不備」または「未知のキー」エラーが発生し、リクエストは拒否されます。
キーを定義したからといって、それ自体がキーの使用を必須とするわけではありません。ゾーンが依然として送信元 IP アドレスによる転送や更新を許可している場合、署名のないリクエストも成功する可能性があります。アクセスルールでは、キーを明示的に指定する必要があります。
チケットに貼り付けられたシークレット、複数のゾーンで共有されているシークレット、またはローテーションが行われていないシークレットは、1つでも漏洩すると影響範囲が広がります。関係ごとに個別のキーを使用し、スケジュールに従ってローテーションを行うことで、被害を最小限に抑えることができます。
TSIGはメッセージに署名を行いますが、暗号化は行いません。転送中に送信されるゾーンの内容は、TLSなどの手段でトランスポート層も保護されていない限り、通信経路上で読み取られる可能性があります。