要約

  • draft-ietf-dnsop-dry-run-dnssec-01 は過渡状態を提案する。対応リゾルバーは署名済みゾーンを検証して異常を報告するが、ドライラン検証がbogusでも通常クライアントには非セキュアな答えを返す。
  • 提案中のNOERROR報告は、ある参加リゾルバーが検証に成功したことを示す。しかし沈黙するリゾルバーや背後の利用者の総数は分からず、RFC 9567の報告はキャッシュで抑制され、送信者も認証しない。
  • 親がドライランDSを実DSへ置き換える前に、観測群、クライアント試験、親の状態、報告の限界、IANA登録状況、残る未知を結ぶ昇格レシートが要る。これはDaniel Kadeの統治提案であり、IETFの規定ではない。

DNSSEC導入の境界は、子ゾーンの署名作業だけでは決まらない。親にDSがない間は、署名の誤りを公開の信頼連鎖に接続せず検査できる。実DSが載った後は、同じ誤りが独立した検証リゾルバーでSERVFAILとなり、運用者が直接管理しないキャッシュや利用者へ伝わる。

DNSOP作業部会の現行Internet-Draft dry-run DNSSEC は、その二つの状態の間に観測可能な段階を設けようとしている。第01版は2026年6月21日公開で、本文はStandards Trackを想定する。しかしRFCでも承認済み標準でもなく、実配備の証拠でもない。提案するEDEとEDNSのコードはなおTBDである。

基礎になるのはRFC 6840の未知DSダイジェストアルゴリズム処理だ。検証器は利用できないアルゴリズムの認証済みDSを考慮せず、使える認証経路が残らなければ子を未署名として扱う。草案は通常値の最上位ビットを立てた値をドライラン用とし、親のDS RRset全体をドライラン型だけにする案を示す。通常DSとの混在は、対応リゾルバーにもドライラン側を無視させる。

非対応リゾルバーは未知の値を捨て、子を非セキュアとして解決する。対応リゾルバーは合図を認識して署名を検証し、結果を報告できる。正しければ認証済みデータとして扱える一方、bogusなら通常クライアントにDNSSECエラーを見せず、ドライランDSが存在しない場合と同じ非セキュアな答えへ戻る。

これは「弱いDNSSEC」ではない。草案はドライラン委任をDNSSEC署名済みとみなすべきでないとし、セキュリティ節は非セキュアへのフォールバックが完全性保証を無効にして、偽造回答の影響を許し得ると述べる。停止を起こさず実経路を検査する代わりに、保護をまだ強制しない期間を受け入れる仕組みなのである。

見える障害と強制される障害

RFC 8914のExtended DNS Errorは、失敗理由を表す共通語彙を与える。RFC 9567のDNS Error Reportingでは、権威サーバーが告知した監視エージェントのドメインへ、リゾルバーがDNS問い合わせを作る。故障したQNAME、QTYPE、EDEコードが報告用の名前に組み込まれる。

これは実験室の試験より現場に近い。配備済みの検証実装、実際のキャッシュ、通常の問い合わせが通った経路から、特定の異常が観測されたと分かる。しかし、一通の報告が証明するのはそこまでだ。

RFC 9567は、報告リゾルバーを監視エージェントへ認証しない。TCPやDNS Cookieは送信元アドレスの詐称を難しくするが、そのアドレスを組織の身元証明にはしない。UDPの報告内容や見かけの送信元は偽り得る。また古いトラストアンカーなどリゾルバー内部の不備を外へ示すこともあるため、プライバシー上、問い合わせ名最小化が推奨される。

報告数は生の失敗数でもない。キャッシュが反復送信を抑え、構成した名前が長すぎれば送られず、監視先が到達不能なら観測も消える。画面に並ぶ件数は、通信条件と実装方針で成形された標本であって、問い合わせ、独立リゾルバー、影響利用者の全数ではない。

NOERRORが証明するのは参加者の存在

エラーがゼロという表示には、ゾーンが正しい以外の理由がある。対応リゾルバーが問い合わせていない、すでに報告が抑制された、監視先へ届かなかった、名前が長すぎた、そもそも実装がない、といった場合である。

第01版は、このうち「対応者がいたか」を確かめるNOERROR報告を提案する。検証成功時、リゾルバーはゾーン頂点を使った肯定信号を送り、キャッシュで頻度を抑える。少なくとも一つの参加者が一度成功した事実が残る。

それでも外部の分母は得られない。非対応リゾルバーは設計上沈黙し、対応していても対象問い合わせを受けなければ現れない。一件のNOERRORは、そのリゾルバーの背後にいる全クライアント、後日の経路、全キャッシュ状態を列挙しない。成功とエラーの比率は観測群の内訳であって、インターネット全体の成功率ではない。

草案はDMARC報告、RFC 8509のルート鍵トラストアンカー・センチネル、RFC 8145のトラストアンカー知識通知を先例に挙げる。規模が小さくても、現在性があり要所にいる観測者は大きな運用情報を与えられる。だが、要所にいることと母集団を統計的に代表することは別である。

Wet-Runは失敗を受け取る経路を選ぶ

通常クライアントが非セキュア回答を受ける限り、本番のDNSSEC拒否にアプリケーションがどう反応するかは試せない。そこで草案はWet-Run EDNSオプションを設ける。クライアントが明示的に付けると、対応リゾルバーはドライラン検証の実際のエラーを返す。キャッシュ済み回答にも通常状態とドライラン状態を並べて保持し、失敗時にはオプションを応答へ戻す。非対応リゾルバーは無視する。

Wet-Runの単位は、選ばれたアプリケーション、ネットワーク、リゾルバーの組み合わせだ。参加しないクライアントを覆わず、リゾルバー側のNOERRORとも置き換えられない。両方を一つの「試験合格」へ畳むと、誰が失敗を受け入れ、どの経路を検査したかが消える。

否定応答には別の盲点もある。RFC 8198により、検証器はキャッシュ済みNSEC/NSEC3証明から回答を合成できる。この効率化は、権威側の壊れた否定証明へ改めて問い合わせないため、問題を隠し得る。草案は合成を一時停止し、明示的に権威へ問い合わせ、結果を比較して、差異を提案EDEで報告するよう求める。

昇格スイッチは親にある

子が署名しただけではドライランにならない。親が特殊DSを受け入れ、公開する必要がある。DSそのものを受け取る親には子がドライラン値を渡す。DNSKEYからDSを作る親にはモード指定か、併記されたCDSを解釈する処理が要る。CDNSKEYだけでは提案中の区別を運べないため、草案はCDSとCDNSKEYの双方を推奨する。

本番化も親の変更である。ドライランDS集合を実DS集合へ置換する。しかし申請、親による受理、権威データでの公開確認、旧キャッシュの失効は別時点だ。一つの「切替済み」欄では、意図と観測を区別できない。

置換後は結果の意味が変わる。演習中のbogusは報告されても通常利用者へは非セキュア回答が届く。実DSの下では、対応アルゴリズムを持つ検証器が同じ誤りを解決失敗にする。従って、ダッシュボードのしきい値は単なる監視設定ではなく、外部のリゾルバーに署名の強制を始めさせる承認判断である。

コード領域はまだ現行登録と一致しない

第01版は、DSダイジェスト値の最上位ビットを使い、128–255をDry-run DNSSECとしてIANAへ求める。現在のIANAレジストリにはその割当はない。2026年1月13日更新の表では、RFC 9904に基づき128–252がReserved、253–254がPrivate Use、255がUnassignedである。

草案が進むなら、この差は明示的に調整されなければならない。現在の表はIANAが提案を拒絶した証拠ではない。Internet-DraftのIANA要請は、適切な承認過程を経て初めて割当になるからだ。ただし、それまでは提案範囲を公的に利用可能なコードとして扱えない。

RFC 9904は、使用推奨と実装推奨を別の列にした。この区別はドライランにも当てはまる。ソフトウェアが機能を持つこと、運用者が有効にすること、このゾーンの重要なクライアント経路が通ることは、それぞれ別の証拠である。

昇格レシートに残すもの

最初に固定するのは実体だ。署名済みゾーンのフィンガープリント、DNSKEY集合、提案したドライランDS、親への申請、受理、外部から観測した公開状態を記録する。観測期間、権威の観測点、キャッシュの境界も分ける。

次に、母集団と呼ばず観測群を記述する。独立した根拠で識別できたリゾルバーはどれか。TCPやCookieで送信元への信頼を少し高めただけの報告はどれか。抑制後のNOERRORとエラー、対象名、問い合わせ型、コード、修正と再試験を対応付ける。プライバシーのための集約は、承認に必要な構造まで消す理由にはならない。

クライアント試験は独立欄にする。ネットワーク、リゾルバー、アプリ種別ごとのWet-Run、通常フォールバックとの比較、正と負の回答、NSEC/NSEC3の明示問い合わせ、キャッシュ期間、届かなかった層を保存する。当日のIANA登録表も添え、未割当コードを実験値と明記する。

最後に、誰が実DSを申請できるか、どの最小証拠と残余未知を受け入れたか、ロールバック責任者は誰かを署名する。申請、受理、公開観測、切替後検証には別々の時刻を与える。

このレシートも全リゾルバーを証明しない。その役割は、選択された標本が意思決定文書の中でいつの間にか「インターネット」へ膨らむのを防ぐことだ。境界が見える証拠なら、結果を引き受ける人が未知を吟味した上で行動できる。

出典

  1. dry-run DNSSEC 第01版
  2. dry-run DNSSEC Datatracker情報
  3. 文書履歴
  4. DNSOPの活動中文書
  5. DNSOP憲章
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — DNSSEC実装上の注意
  9. RFC 8198 — 検証済みキャッシュの積極利用
  10. RFC 8509 — ルート鍵トラストアンカー・センチネル
  11. RFC 8145 — トラストアンカー知識の通知
  12. RFC 9904 — DNSSEC暗号アルゴリズム推奨更新手順
  13. IANA DS Digest Algorithmsレジストリ