TSIG

TSIG (トランザクション署名) は、RFC 2845 で定義されているコンピュータ ネットワークプロトコルです。主に、ドメイン ネーム システム(DNS) が DNS データベースへの更新を認証できるようにします。最も一般的に使用されるのは、ダイナミック DNSまたはセカンダリ/スレーブ DNS サーバーの更新です。TSIG は、共有秘密キーと一方向ハッシュを使用して、接続の各エンドポイントが DNS 更新を実行または応答することを許可されているかどうかを認証する、暗号的に安全な手段を提供します。

DNS へのクエリは通常は認証なしで実行できますが、DNS の更新はインターネット命名システムの構造に永続的な変更を加えるため、認証が必要です。更新要求は安全でないチャネル(インターネット) 経由で到着する可能性があるため、要求の信頼性と整合性を保証するための対策を講じる必要があります。更新を行うクライアントと DNS サーバーが共有するキーを使用すると、更新要求の信頼性と整合性が保証されます。一方向ハッシュ関数は、悪意のある観察者が更新を変更して宛先に転送するのを防ぎ、送信元から宛先へのメッセージの整合性を保証します。

TSIG プロトコルには、記録された応答が再利用され、攻撃者が TSIG のセキュリティを侵害するのを防ぐために、タイムスタンプが含まれています。これにより、ダイナミック DNS サーバーと TSIG クライアントに正確なクロックを含めることが求められます。DNS サーバーはネットワークに接続されているため、ネットワーク タイム プロトコルは正確な時間ソースを提供できます。

クエリなどの DNS 更新は通常、 TCPよりもオーバーヘッドが少ないため、UDP経由で転送されます。ただし、 DNS サーバーは UDP 要求と TCP 要求の両方をサポートしています。

RFC 2136 で規定されている更新は、DNS サーバーへの一連の指示です。これには、ヘッダー、更新するゾーン、満たす必要のある前提条件、更新するレコードが含まれます。TSIG は、タイムスタンプと要求のハッシュを含む最終レコードを追加します。また、要求の署名に使用された秘密キーの名前も含まれます。RFC 2535 には、名前の形式に関する推奨事項があります。

TSIG 更新が成功した場合の応答も、TSIG レコードで署名されます。攻撃者が特別に細工された更新「プローブ」を使用して TSIG キーに関する情報を入手できないようにするため、失敗は署名されません。

nsupdateプログラムは TSIG を使用して DNS 更新を実行できます。

TSIG レコードは、更新要求内の他のレコードと同じ形式です。フィールドの意味は RFC 1035 で説明されています。

TSIG は広く導入されていますが、プロトコルにはいくつかの問題があります。

• 更新を行う必要がある各ホストに秘密鍵を配布する必要があります。
• HMAC-MD5 ダイジェストは今でも一般的に使用されていますが、それほど安全であるとは考えられていません。HMAC-SHA256 が推奨されます。^{[引用が必要]}

その結果、いくつかの代替案と拡張が提案されました。

• RFC 2137 では、公開鍵「SIG」DNS レコードを使用した更新方法が指定されています。対応する秘密鍵を持つクライアントは、更新要求に署名できます。この方法は、安全なクエリのDNSSEC方法と一致します。ただし、この方法は RFC 3007 で非推奨になっています。
• 2003 年に^{[アップデート]}、RFC 3645 は、TSIG を拡張して、Generic Security Service (GSS) 方式の安全な鍵交換を可能にすることを提案しました。これにより、すべての TSIG クライアントに手動で鍵を配布する必要がなくなりました。公開鍵を DNS リソース レコード (RR) として配布する方法は RFC 2930 で指定されており、GSS はこの方法の 1 つのモードです。Windows Kerberosサーバーを使用する修正された GSS-TSIG は、 Microsoft Windows Active Directoryサーバーとクライアントによって、セキュア ダイナミック アップデートと呼ばれる形で実装されました。RFC 1918 アドレス指定を使用する、適切に構成されていない DNS (逆引き参照ゾーンなし) と組み合わせると、この認証方式を使用した逆引き DNS 更新がルート DNS サーバーに大量に転送され、ルート DNS サーバーへのトラフィックが増加します。このトラフィックを処理してルート DNS サーバーからトラフィックを取り除くエニーキャストグループがあります。 ^{[1] [2]}
• RFC 2845 は TSIG を定義し、128 ビットHMAC-MD5という 1 つのハッシュ関数のみを指定していますが、これはもはや高度に安全であるとは考えられていません。RFC 4635 は、MD5 の代わりに RFC 3174 セキュア ハッシュ アルゴリズム (SHA1) ハッシュとFIPS PUB 180-2 SHA-2ハッシュを許可するように配布されました。SHA1 と SHA-2 によって生成される 160 ビットと 256 ビットのダイジェストは、 MD5によって生成される 128 ビットのダイジェストよりも安全です。
• RFC 2930 では、DNS サーバーから DNS クライアントにキーを自動的に配布するために使用されるDNS レコードであるTKEYが定義されています。
• RFC 3645 は、gss-api と TKEY を使用して gss-api モードでキーを自動的に配布する GSS-TSIG を定義します。
• DNSCurve提案にはTSIG と多くの類似点があります。

• DNSレコードタイプのリスト

• RFC  2136 ドメイン ネーム システムにおける動的更新 (DNS UPDATE)
• RFC  2845 DNS の秘密鍵トランザクション認証 (TSIG)
• RFC  2930 DNS の秘密鍵の確立 (TKEY RR)
• RFC  3007 セキュア ドメイン ネーム システム (DNS) 動的更新
• RFC  3645 DNS の秘密鍵トランザクション認証のための汎用セキュリティ サービス アルゴリズム (GSS-TSIG)
• RFC  3174 US セキュアハッシュアルゴリズム 1
• RFC  4635 HMAC SHA TSIG アルゴリズム識別子
• RFC  8945 DNS の秘密鍵トランザクション認証 (TSIG)