要約

  • DNSSEC は、存在しない名前やレコード種別を挟む順序付きの境界に署名することで、DNS の否定応答を検証可能な証拠に変えた。
  • NSEC3、Opt-Out、検証済みキャッシュの再利用は単なる調整ではなく、情報開示、計算量、委任の保証、新しい名前が有効になる時刻を配分する設計判断である。

すべての所蔵文書に本物の署名が付いた公文書館を考えてみよう。署名は目の前の文書が本物だと示すが、求めた文書を係員が隠していないことまでは証明しない。不在を証明するには、並び順によって空白が見える署名付き目録が要る。

DNSSEC の「認証された不存在証明」が成し遂げたのは、この発想の転換だった。

通常の DNS は、名前がなければ NXDOMAIN を、名前はあるが要求したレコード種別がなければデータなしを返す。DNSSEC 検証がなければ、その否定は応答経路と同じだけしか信頼できない。経路上の攻撃者にとっては、利用者を偽のアドレスへ導かなくても、サービスを消して見せるだけで十分な場合がある。

RFC 4034は、署名済みゾーンが空白を記述する方法を定めた。NSEC レコードは、ゾーンの正規順序で次に来る権威名と、現在の名前に存在するレコード種別のビットマップを持つ。RFC 4035は検証手順を定める。問い合わせ名が署名済みの二つの境界の間に入れば、その区間が正確な名前の不存在を示す。名前は存在しても種別がビットマップになければ、その種別がないことの証明になる。名前エラーでは、回答を生成し得るワイルドカードの不存在も示さなければならない。

考え得る質問ごとに否定レコードを作るのではない。ラベル空間は大きすぎる。証拠は順序付き区間そのものだ。認証された二つの事実が空白を挟む。

最初の証明は目録を見せすぎた

NSEC の明快さには別の性質がある。各レコードが次の権威名を指すため、問い合わせを重ねれば鎖をたどってゾーンを再構成できる。

この「ゾーンウォーキング」は、DNS が暗号化を約束した秘密を暴くわけではない。それでも、容易に列挙できる一覧は命名規則、内部用に見えるサービス名、従来は作成に手間がかかった偵察地図を示し得る。検証側には不在を区切る十分な証拠が必要だが、運用側は平文の索引を渡したくないことがある。

RFC 5155は NSEC3 を導入した。鎖という考え方は残し、読める所有者名をハッシュ値へ置き換える。検証者は問い合わせ名のハッシュが署名済み区間に入ることを確かめられるが、列挙する側は候補ラベルをオフラインで推測しなければならない。

これは摩擦であって秘密ではない。よく使われるラベルは推測しやすく、証明書、ログ、リンクにも現れる。RFC 9276は収穫逓減を明示する。反復回数を増やせば権威サーバーと検証者の仕事は増えるが、推測可能な名前が機密になるわけではない。

Opt-Out は規模の代価を証明に刻む

委任が非常に多いゾーンでは、未署名の子ごとに NSEC3 を作り更新することが署名処理とメモリの負担になる。Opt-Out は、各委任専用のハッシュレコードを置かずに、未保護の委任を一つの区間で覆える。

節約は現実だが、意味上の譲歩も現実だ。RFC 5155によれば、Opt-Out 区間は、その範囲に未保護の委任が存在するかどうかを断言しない。他の権威データは守られるものの、その境界での証明は意図的に狭い。ゾーンは委任変更を安く速くする代わりに、未署名のすべての子について同じ暗号学的主張をしない。

したがって Opt-Out は中立なサーバー設定ではなく、どの不存在に運用者が責任を持つかという統治判断だ。RFC 9276は小規模ゾーンで推奨せず、非常に大きく動的で署名済み委任の比率が低い場合に用途を限定している。

キャッシュされた空白が次の質問に答える

RFC 8198は、検証リゾルバーがキャッシュ済み NSEC または NSEC3 区間を積極的に使うことを認める。後の問い合わせが既に空だと証明された区間に入れば、権威サーバーへ再問い合わせせず否定応答を合成できる。

これは遅延と負荷を減らし、不要な問い合わせの上流への漏出を抑え、ランダムラベル型の DoS の一部も吸収し得る。ただしキャッシュが署名済みの主張を将来の質問へ適用するため、その有効期間が運用条件になる。

RFC 8198は、NSEC または NSEC3 の TTL とゾーンの否定キャッシュ値が、新しい名前が使い始められる時刻を決めると説明する。広い不存在証明を公開した直後に名前を作れば、検証リゾルバーはまだ正しく「存在しない」と答えられる。誤っているのはプロトコルではなく、否定証拠の有効期間を無視した変更計画だ。

現在の実務は複雑さを減らす

RFC 9276は、NSEC3 の機能が不要なら NSEC を優先する。NSEC3 が必要でも追加反復はゼロ、salt は空を推奨する。追加反復は計算量、CPU 枯渇攻撃、相互運用失敗の危険を増やす。固定 salt の効果は小さい。完全修飾名そのものが計算をゾーン固有にするからだ。

パラメーター変更後は、既知の不存在名を使ってセカンダリーを検査することも求める。正のレコードが正常に見えても、否定証明の鎖だけが古い、食い違う、または一つの実装に重すぎることがある。

これらの RFC は仕組みと現行実務を定義するが、特定運用者の設定品質までは証明しない。品質は実際の権威側と検証側で測る必要がある。

出典