Summary

  • DNSOP作業部会の新しい草案は、DSまたはトラストアンカー集合にUNIVERSALアルゴリズムがあり、FORMERLY-UNIVERSALがなければ、少なくとも一つのUNIVERSALで署名すればよいと提案する。
  • 初期のUNIVERSAL候補はアルゴリズム8と13。IANAの現行登録簿は両者を検証の必須実装とするが、草案が求める新しい状態欄はまだ存在しない。
  • 検証器が掲示されたUNIVERSALをローカル方針で無効にした場合、別の掲示アルゴリズムを扱えても、そのゾーンを未署名として扱う。方針の費用は検証器側の認証喪失だ。

DNSSECの署名者は全科目の答案を提出し、検証器は一科目に合格すればよい。RFC 4035とRFC 6840では、ゾーンが示すアルゴリズムごとに署名を用意する一方、検証器は有効な経路を一つ見つければ足りる。未知の検証器を相手にするための保険だが、署名者が毎回答で保険料を払う。IETFの草案は、必ず使えるはずのアルゴリズムがある場合に限って、その負担を減らす。

複数のDNS事業者で同じゾーンを配る場合、負担は運用上の束縛にもなる。RFC 8901の独立鍵モデルでは各事業者が自分の鍵で署名する。アルゴリズムが違えば、現行の全種類署名要件は事業者間の同期を強いる。移管中も同じ問題が出る。新しいトラストアンカーを早めに公開したいだけなのに、対応する署名を全ゾーンで先に出す必要があるなら、準備と実施を分けられない。

「誰でも使える」を登録簿に書く

草案はIANAのDNSSECアルゴリズム表に Validation support status という欄を求める。UNIVERSAL、FORMERLY-UNIVERSAL、空欄の三状態だ。初めはRSA/SHA-256の番号8とECDSA P-256/SHA-256の番号13がUNIVERSALに入る。現行の表でも両者は検証の必須実装である。かつて広く使えたが支援が減った算法のためのFORMERLY-UNIVERSALには、初期値がない。

親ゾーンのDSまたはトラストアンカーにUNIVERSALが少なくとも一つあり、FORMERLY-UNIVERSALが一つもなければ、署名者はそのUNIVERSALの一つで署名し、他は任意になる。DNSKEYも実際に署名したアルゴリズムに絞れる。UNIVERSALがない場合、または元UNIVERSALが含まれる場合は、全アルゴリズムの署名が必要だ。「二つあるから片方は省略」といった雑な省力化ではない。

番号8と13を使う二社なら、それぞれの有効な署名経路を返せる。新しいトラストアンカーを鍵と署名より先に示すこともできる。ある事業者が実験的な耐量子アルゴリズムを追加しても、共同運用する全事業者に同日対応を迫らずに済む。ただし新方式がUNIVERSALでなければ、最終的な切り替えには二重署名期間が必要な場合がある。

検証器の設定が結果を変える

ゾーンが8と13を掲げ、一社が8による正しい経路を返す。ある検証器の管理者は8をローカル設定で無効にしているが、13は扱える。草案なら、その検証器はゾーンを未署名と分類する。自分で必須扱いの算法を止めた結果を、ゾーンの壊れた署名として bogus やSERVFAILにしてはならない、という割り振りだ。過去にUNIVERSALだった算法についても同様の扱いになる。

名前解決が成功しても、この検証器にとってDNSSEC認証は成立していない。画面に「応答あり」とだけ表示する監視では、管理者の判断が見えなくなる。必要なのは secure、insecure、bogus を分けた記録と、誰がアルゴリズムを止めたかを示す変更履歴だ。

旧規則には攻撃への備えがある。攻撃者が検証可能な署名だけを取り除き、知らない署名だけ残して、安全だった応答を静かに「未署名」へ落とすことを防ぐためだ。草案はUNIVERSALとFORMERLY-UNIVERSALの区別でその防御を保つ設計だとする。検証器には、かつてUNIVERSALだった番号を無効化後も覚えておく仕事が増える。

2026年10月31日付の文書は作業部会の初稿で、導入数や障害件数は示さない。実際の導入を判断する材料は各運用者の検証結果だ。事業者ごとの署名の部分集合と、検証器ごとの有効・無効設定を組み合わせ、結果が安全、未署名、破損のどれになるかを測る。「DNSSEC対応」という製品欄だけではこの組み合わせを説明できない。

署名を減らす自由は、検証器のローカル方針を不可視にする自由ではない。登録簿、署名者、親ゾーン、検証器が別々の判断を持つ以上、最後の安全状態がどこで変わったかを追える設計が要る。

IETF草案 · RFC 4035 · RFC 6840 · RFC 8901 · IANA登録簿