要約

  • GSS-TSIG は TKEY で GSS コンテキストを交渉し、TSIG で DNS メッセージを保護するが、ゾーン更新の認可までは与えない。
  • 監査では、認証された主体、適用ポリシー、許可された操作、実際の書き込み、伝播、問い合わせ結果を別々に立証する必要がある。

状態遷移として考えると境界が見える。最初に資格情報がある。次にクライアントとサーバーがコンテキストを交渉する。メッセージ署名を検証した後、ローカル・ポリシーが操作を許すか判断する。サーバーがデータを変更し、その後に他の権威サーバーやリゾルバーから新しい値が見える。前段の成功は後段の領収書ではない。

RFC 3645 は GSS-TSIG を二段階で定義する。まず GSS_Init_sec_context と GSS_Accept_sec_context が生成する不透明なトークンを TKEY で交換し、未初期化、交渉中、確立済みへと進む。次に確立済みコンテキストを GSS_GetMIC と GSS_VerifyMIC に渡し、TSIG レコード内の署名を生成・検証する。テキスト版 は、この文書が認証機構だけを扱い、認可機構を提案しないと明記している。

ここで「誰から来たか」と「その人に許されているか」が分かれる。認証結果から得た主体は、認可判定への入力である。対象名、レコード型、追加・削除などの操作、現在のゾーン・ポリシーを照合して初めて許可が決まる。その後にも、更新応答、プライマリの状態、伝播先、問い合わせ時刻という独立した事実が残る。

構成要素にも役割分担がある。RFC 2743 は GSS-API の共通枠組み、RFC 2930 は鍵確立用の TKEY、RFC 2845 は元の TSIG 取引認証を定め、RFC 8945 がそれを更新した。RFC 4121 は Kerberos v5 の GSS 機構を定義する。部品が協調するからといって、権限判断まで一体化するわけではない。

コンテキストには寿命がある。RFC 3645 はクライアントとサーバーの関係ごとに固有のコンテキストを求め、交渉の往復回数は下位機構に依存する。規定されたループは十回を上限とし、クライアントは最後の署名付き応答を検証してから「確立済み」に進む。期限切れや検証失敗を、以前の信頼で補ってはならない。

相互運用プロファイルは SPNEGO を推奨し、Kerberos v5 対応を必須とする一方、他の機構も許す。安全性は選ばれた GSS 機構に依存する。したがってログには gss-tsig という名称だけでなく、交渉機構、ターゲット名、資格情報の由来、キー名、コンテキスト寿命、リプレイ・順序検査、相手、検証結果が必要になる。

認可の原則は RFC 3007 に現れる。ゾーン管理者がポリシーを設定し、サーバーが認証主体と要求操作に基づいて適用する。明示的に許されなければ変更を認めないのが既定である。RFC 2136 は Dynamic Update の前提条件と操作を定義する。署名が有効でも、ポリシー評価は省略できない。

さらに、RFC 4033 が説明する DNSSEC のデータ起源認証・完全性と、更新取引の認証は異なる。DNSSEC 検証済みの応答から、過去の管理操作の許可までは復元できない。逆に、認証済み更新が受理されても、目的地すべてで新状態が観測できるとは限らない。

IANA の TSIGアルゴリズム名レジストリ は gss-tsig を、DNSパラメータ・レジストリ は他の共通値を調整する。その手順を扱う RFC 6895 も含め、レジストリが証明するのは共通名称であり、稼働中の主体や権限や変更ではない。

規格の来歴は RFC Editorの記録、Datatracker、履歴、正誤表検索で確認できる。ここから特定製品の挙動や現在の普及率を推測してはいけない。

Heng Lu の現実の層、最小共通仕様、稼働コードの優位という視点を当てると、制度設計も明瞭になる。標準は相互運用の床を作る。権限はローカルに決まる。実際のサーバーと後続観測が結果を決める。一つの層に全権を持たせる説明は、技術的にも統治上も誤っている。