要約

  • RFC 3008では、データ署名がDNSSECにとって実質的な証拠になるには、計算が正しいだけでなく、各フィールドが適格で、対応するゾーン鍵による署名でなければならなかった。
  • ホスト鍵とユーザー鍵はSIG(0)トランザクションの送信主体を認証できたが、公開ゾーンデータを証明するのはゾーン鍵であり、変更の提案とゾーンを代表する権限は分離された。

正しい署名が、正しい発言者の署名とは限らない。公開鍵は一致し、対象バイトも改変されておらず、検証式も成功する。それでも、その鍵がゾーン全体を代表する資格を持たなければ、リゾルバーが公共のDNS証拠として採用する理由はない。RFC 3008は2000年11月、この計算と権限の隙間を標準の判断手順にした。

文書は署名を material と immaterial に分けた。データSIGは通常RRsetを覆い、DNSSECの検証に参加する。一方、アプリケーション固有の用途を持つ署名、RRsetに結びつかない署名、DNSメッセージ自体を保護するSIG(0)もあり得る。それらは偽物だから排除されるのではない。ゾーンデータの信頼連鎖にとって実質的ではないから、別の証拠として扱われる。

これはRFC 2535の広い署名者モデルを狭める変更だった。初期のDNSSECでは、条件によってゾーン鍵だけでなくホスト鍵やユーザー鍵もデータへ署名できた。動的更新では、ホストが自分の追加データを署名できれば、重要なゾーン秘密鍵をオフラインに保てるという期待があった。

しかし、更新経路全体を見れば、その境界は成立しなかった。安全なゾーンで動的変更を受け入れると、SOAやNXTの集合も再署名しなければならない。RFC 3007の安全な更新は、結局オンラインのゾーン署名能力を必要とした。すでにゾーン鍵がオンラインにあり、受け入れたデータを署名できるなら、ホスト署名を公共のゾーン証拠にすることでオフライン化の利益は増えない。増えるのは、各リゾルバーが任意の署名者関係を解釈する負担だった。

RFC 3008は既定の権限面を縮小した。安全なゾーンのデータはゾーン鍵で署名される。明示的なローカル方針が上書きしない限り、リゾルバーはデータSIGを検証するとき非ゾーン鍵を無視する。以前の柔軟性は失われるが、検証連鎖の長さはDNS名のラベル深度で上限がつき、誰がゾーンを代表するかを可視の階層から判断できる。

ただし「ゾーン鍵」という名称だけで合格するわけではない。まずデータSIGの type covered は付随するRRsetの型と一致する必要がある。アルゴリズムはクライアントが認識し、SIG RDATA形式が定義されていなければならない。labelsの数は署名所有者名のラベル数を超えられない。中間サーバーはTTLを増やせないため、original TTLは現在のSIG TTL以上でなければならない。検証時刻はinceptionとexpirationの間に入る必要がある。

次に signer name、key tag、algorithm の組み合わせで候補KEYを探す。候補がなければ署名はそれ以上処理されず、DNSSECにとって非実質的になる。同じ識別子に複数の鍵が一致するときは、暗号検証で署名者が判明するまで全てが候補のままだ。検証成功を見てから、鍵の役割を後付けすることはできない。

KEYレコードにも検査項目があった。type flagsは認証を許可し、実質的なデータSIGならname typeはzoneでなければならない。protocolはDNSSECまたはALLを示す必要がある。KEYのalgorithmはSIGと一致する。したがって同じ公開鍵が同じ計算を成功させても、別のプロトコル用、別の主体種別として宣言されていれば、その結果はゾーンの証言にならない。

ここには複数の独立した受領証がある。暗号検証は鍵、署名、対象入力を結ぶ。形式検査は処理資格を示す。鍵種別はその対象に対する署名権限を示す。信頼連鎖は既知の信頼点からゾーン鍵への道を示す。時間窓は有効期間を限定する。全てが揃っても、DNSが指すサービスの稼働や、記録内容の現実的な妥当性まで保証するわけではない。

トランザクション署名には別の経路が残った。type coveredがゼロのSIGはDNSメッセージを保護するSIG(0)であり、RFC 2931が詳しく定義した。トランザクションを始めるのはユーザーまたはホストなので、期待される鍵のname typeもuserまたはhost/entityである。ネームサーバーがSIG(0)を作る場合も、特定ゾーンではなくホストとして署名する。ゾーン鍵は通常SIG(0)を生成すべきではなかった。

これはホスト鍵を弱くしたのではなく、何を証明する鍵かを限定した。ホスト鍵は更新要求を送ったprincipalを認証できる。その後、プライマリサーバーがRFC 3007のローカル方針で、対象名、RR型、操作を許可するか判断する。既定は変更不可である。要求が受理されると、ゾーン鍵が公開状態を署名する。提案者の身元、変更の許可、公開データの証明は三つの異なる権限だった。

この分割により、リゾルバーはプライマリ内部のアクセス制御を再現しなくてよい。どのクライアントが過去にどのRRを書けたかを公開プロトコルへ埋め込まず、ゾーンデータには共通のゾーン鍵基準を適用できる。プライマリは組織の方針を変更しても、DNS形式や全リゾルバーの相互運用性を変えずに済む。

旧KEYのsignatoryフィールドが使われなかったのも同じ理由だった。RFC 3008は値を割り当てず、存在も要求しなかった。少数のビットで「誰が何を署名できるか」を表す方法は簡潔に見えるが、将来の認可規則を固定列挙へ閉じ込める。更新の入口ではローカル方針、公開検証ではゾーン鍵という二つの面に分ける方が、責任の場所が明確だった。

ただし、この仕組みは初期DNSSECの歴史に属する。RFC 3090は当時の安全ゾーン状態を補足し、RFC 3658はDSレコードで親子の委任連鎖を更新した。その後、RFC 4033、RFC 4034、RFC 4035がRFC 2535と3008のKEY/SIG世代を置き換えた。

したがってRFC 3008を現行の設定手順として書くことはできず、そのKEY flagsを現代のDNSKEYやRRSIGへ無説明で対応させてもならない。RFC 3130は2001年当時、DNSSECが異なる速度で進む技術の道具箱として理解されていたことを記録する。それは設計が過渡期にあった証拠であり、普及率やRFC 3008単独の効果測定ではない。

歴史的に残るのは、署名が自分自身の委任状にはならないという順序である。受信側の実行コードが、署名者の役割、対象、用途、時間、信頼経路を合わせて初めて権限が成立する。そうしなければ、精密な数学が鍵の保有者へ設計外の公共発言権を与えてしまう。

Lu HengのRunning-Code Primacyという視点では、権限は署名オブジェクトに宿るのではなく、リゾルバーが分類と検証を実行した瞬間に現れる。最小の共通層はゾーン鍵という基準である。ローカル例外は可能だが、判断したリゾルバーの責任として残り、全員の規則を暗黙に変えない。安定性は一個の緑色表示ではなく、各段階の受領証を保存することで得られる。

RFC 3008は署名の神秘性を減らし、責任を増やした。署名は鍵の保有を示し、KEYは用途を宣言し、ゾーン上の位置は役割を与え、連鎖は信頼の出所を示し、時刻は期限を定める。これらが同じRRsetで交わるときだけ、正しい署名は権限あるDNSSEC証拠になる。

Sources