要約

  • RFC 2845では、署名付きDNS応答のMACに、その応答を求めた問い合わせのMACを含めた。
  • 複数メッセージから成るDNS/TCPのやり取りでは、累積MACが直前のMACと後続メッセージを順に覆う。TSIGは最初と最後のメッセージ、および少なくとも100メッセージごとのチェックポイントに付く。
  • RFC 8945は後に、送信側が応答の全メッセージにTSIGを付ける規則へ改めた一方、検証側には互換性のため限定的な未署名メッセージの許容を残した。どちらの規則も、トランザクション認証を機密性・データの正しさ・ローカルな許可に変えるものではない。

応答は単独のパケットではなかった

DNSのメッセージIDや応答コードはやり取りを対応付けられても、相手を認証したり、トランザクションの改変を防いだりはしない。2000年5月に公開されたRFC 2845は、共有秘密鍵で検証するTSIGというメタリソースレコードを加えた。対象は意図的に二者間へ限定されていた。両者が同じ鍵を設定済みであることが前提で、鍵の配布は仕様の範囲外だった。

設計の要点はMAC計算の入力にある。クライアントはまず問い合わせを認証する。サーバーが署名付きで応答するとき、応答側の計算には問い合わせのMAC、応答本体、応答側TSIGの変数が含まれる。検証側は応答を文脈から切り離された新しいデータとして扱えず、暗号学的な検証は元の問い合わせまでさかのぼる。署名時刻と許容幅もMACに含まれるため、中継者が時刻欄だけを書き換えて検証を通すことはできない。

この結び付きが示すのは、対象のバイト列と鍵の関係が検証に合致したということだ。鍵は二者で共有されるため、成功は設定済みの鍵でメッセージが検証できたことを示すが、その鍵を誰が持っていたのかまでは明かさない。TSIGはDNSを暗号化せず、サーバーが更新を許可すべきかも決めない。DNS UPDATEの操作はRFC 2136が定めるが、認証済みの相手にゾーン変更を許すかはローカルポリシーに残る。

ゾーン転送はメッセージの連なりになった

難しいのは、TCPによるゾーン転送のように、応答が複数メッセージに分かれる場合だった。各パケットを独立して扱えば、順序と相互の関係が見えなくなる。RFC 2845は最初と最後のメッセージにTSIGを要求し、少なくとも100メッセージごとに署名付きチェックポイントを置いた。チェックポイント間では、直前のMACと関係する時刻情報に加え、DNSメッセージを受信順に次のMAC計算へ含める。

検証対象は、ストリームの限られた区間にわたる連続性であり、中間メッセージ一つひとつへの独立署名ではない。検証に失敗したらTCP接続を閉じ、転送を中断として扱うようRFCは求めたが、具体的な再試行手順までは規定しなかった。チェックポイントが通っても、それが覆うのは受信したメッセージ列の一部であり、サーバーが後に何を確定したか、セカンダリーが何を配信したかまでは示さない。

規則は変わっても、境界は変わらない

RFC 4635は当初のHMAC-MD5に加えてHMAC-SHAのアルゴリズム識別子を追加した。2020年、RFC 8945はRFC 2845とRFC 4635を置き換え、STD 93となった。送信側の規則は厳しくなり、適合する送信側は応答内の全メッセージにTSIGを付ける。検証側の互換規則は別で、最初と最後には署名を要求しながら、中間の未署名メッセージは最大99件まで受け入れる。99件の許容は、現行の送信側が署名を省いてよいという意味ではない。

RFC 8945は、証明できる範囲も明記する。TSIGが認証するのは秘密鍵を共有する二者間の通信であり、元データの出所や正しさではない。別の信頼モデルでデータを認証するDNSSECとも異なる。TKEYを使って鍵を確立する構成もあるが、鍵の配布そのものはTSIGの機能ではない。規格が定めたのは用途の境界が明確な仕組みであり、何にでも使える信頼の印ではない。

出典：RFC 1035、RFC 2104、RFC 2845、RFC 8945、RFC 4635、RFC 2136、RFC 2930。