要約

  • RFC 3655はADビットを広いサーバーポリシー表示から、関連するDNS RRsetが改訂後の規則に従って認証されたことを示す、より限定的な信号へ変更した。
  • ADはリゾルバーによる状態報告であり、DNSパケットの署名でも、リゾルバー、経路、利用者の信頼判断が正しいことの証明でもない。

分析

場面は、ごく普通の名前解決から始まる。アプリケーションがstub resolverに問い合わせ、stubは再帰リゾルバーへクエリーを転送する。再帰リゾルバーは鍵の連鎖をたどって署名を取得し、結果をキャッシュできる。応答が戻ると、DNSヘッダーの1ビットで上流の処理内容をアプリケーションへ伝えられる。重要なのはビット数ではなく、誰がその主張を行い、どの証拠を要約しているかだ。

RFC 2535ではAuthenticated Data（AD）ビットは、AnswerとAuthorityのデータがサーバー自身のポリシーに照らして認証済みだという、幅広い意味を持っていた。2003年11月のRFC 3655は、この信号は実用上有益でないと論じた。適合サーバーなら、そもそも自らのセキュリティ方針に反するデータを返すべきではない。従来のADはサーバー全体の姿勢を表すにとどまり、目の前の応答の状態をアプリケーションに伝えにくかった。

改訂版では伝達内容を限定した。再帰サーバーは、AnswerとAuthorityに含まれる関連RRsetが認証条件を満たさない限り、ADを設定してはならない。回答レコードに加え、否定応答を裏付ける関連レコードも認証されている場合に設定する。DNSSECが各DNSパケットに署名を付けたわけではない。DNSSECが認証するのはリソースレコードセットであり、ADはリゾルバーがその応答について行ったローカルな判断を要約する。

この区別はDO、CDとADを分けて考える理由でもある。DOはDNSSECレコードの返却を求める。RFC 3655は、要求され、関連するSIGレコードが返ることをAD設定の条件とした。CDはそのクエリーに対する検査を無効にする。CDがあるからといってADが自動的に消えるわけではなく、既に暗号学的に検証済みか、ローカルポリシーに適合すると判断されたデータなら、サーバーはADを設定できた。各ビットは、証拠の要求、検査の制御、結果の通知という異なる段階を表す。

そのためRFC 3655は、再帰リゾルバーを信頼の中継点にした。各アプリケーションが完全な検証器を内蔵しなくてもよく、キャッシュされた検証結果も共有できる。ただしstubは、ADを自己認証する証拠として扱えない。再帰リゾルバーを明示的に信頼し、安全な通信路やTSIG、SIG(0)などで通信を保護する必要がある。そうでなければ、経路上の応答者が立てたADは検証の主張にすぎず、検証証拠が安全に届いたことにはならない。

権威サーバーの規則は別の境界を示した。セキュアなゾーンのプライマリーサーバーはADを設定するよう構成できるが、明示的な選択が必要で、既定では無効にすべきだった。権威サーバーは自分のゾーンの署名を検証する義務を負わない。ロード時や各クエリーで署名を検証すれば運用コストも生じる。そのため、権威サーバーからの直接応答にADがあっても、再帰リゾルバー同様の検証が行われたと既定で保証されるわけではない。

ADが0のときも読み違えが起きる。RFC 3655は、insecureな応答にADを設定してはならないとしたが、ビットがクリアされているだけでは、データがinsecureなのか、リゾルバーが未検査なのか、要求されたDNSSECレコードがなかったのか、サーバーが状態を表明しなかったのかは分からない。AD=1は信頼関係の中で意味を持つ一方、AD=0だけでは完全な診断にならない。

2005年、RFC 4033、4034、4035がDNSSECの枠組みを改訂し、RFC 3655を廃止した。ADによる状態伝達は残ったが、検証器、stub、権威サーバー、認証経路を含む、より包括的な仕様群に位置づけ直された。RFC 3655の歴史的役割は狭いインターフェースの修復にある。再帰リゾルバーの評価をアプリケーションへ伝えつつ、ヘッダーのビット自体を暗号学的証明と見せない方法だった。

証拠は階層ごとに扱う必要がある。RRSIGは鍵の連鎖とトラストアンカーに基づくRRset認証を支える。検証リゾルバーがローカルな状態を判断する。ADがその判断を伝える。信頼するリゾルバーとの安全な通信路があれば、その応答を利用者が選んだサービスに結びつけられる。どれも単独では、ドメイン登録者の誠実さ、アプリケーションにとっての情報の鮮度、アプリケーションの安全な行動までは証明しない。

出典