要点

  • draft-ietf-dnsop-delegation-mgmt-via-ddns-02は、子から親へNS、グルー、DSの具体的な差分をSIG(0)付きDNS UPDATEで送り、DSYNCで受信先を見つける仕組みを提案する。
  • 最初のブートストラップは新しい鍵自身で署名される。証明できるのは秘密鍵の所持であって、子の委任を管理する資格ではない。受信側は鍵をまずknownとし、別の検証に成功してからtrustedへ進める。
  • 旧鍵、選択した検証経路、独立した根拠、ポリシー判断、UPDATE受理、親ゾーンでの実掲載を結ぶ「権限移行記録」が必要だ。これは本稿の統治提案であり、DNSOPの要件ではない。

自己署名は嘘ではない。ただ、答えている質問が小さい。

受信側が知りたいのは「この公開鍵に対応する秘密鍵が使われたか」だけではない。「この鍵にchild.parent.の委任情報を変える権力を渡してよいか」である。前者は署名検証で答えられる。後者には、現在の運用者、登録者、レジストラ、親側ポリシーのどれを権限源とするかという判断が必要になる。

2026年6月17日に公開された第02版は、DNSOPの作業部会Internet-Draftとして活動中である。Internet-Draftは変更、置換、失効し得る作業文書だ。本文ヘッダーはStandards Trackを掲げる一方、Datatracker概要の想定RFCステータスは空欄になっている。RFCではなく、どこかのレジストリが採用済みだとも言えない。

対象とする障害は地味だが危険である。子ゾーンがネームサーバーやDNSSEC情報を更新しても、親側に古いNS、グルー、DSが残ることがある。残った一系統で名前解決が続けば不一致は見えにくい。次の故障が起きた瞬間、期待していた冗長性がすでに失われていたと分かる。

CDSやCSYNCのスキャナーは、親が子を定期的に調べて変更を見つける。提案方式では、変更を最初に知る子が差分を作り、安全なDNS UPDATEとして押し出す。親はDSYNCでUPDATEを受ける場所とポートを知らせる。大量の巡回と待ち時間を減らし、子ゾーンがDNSSEC署名済みでなくても利用できる余地がある。

ただし、仕事が子側へ移るほど、誰の意思を運んでいるかは明示しなければならない。

UPDATE Receiverは検問所である

NOTIFYは変化があるという合図であり、受信側が調べ直す。DNS UPDATEは追加・削除したいレコードそのものを含む。SIG(0)により、すでに信頼する公開鍵を基準として、取引の完全性と秘密鍵所持を検証できる。

この「すでに信頼する」が制度の入口だ。草案は、SIG(0)の暗号強度がDNSSEC署名と同程度でも、信頼モデルは同じではないと明記する。DNSSECは通常、署名の連鎖を信頼アンカーまでたどる。UPDATE用の鍵はブートストラップによって個別に信頼される。強い暗号が、最初の委任判断を代行するわけではない。

受信機能は親のプライマリーサーバーと分離でき、親自身またはレジストラなどの第三者が運用できる。重要なのは、署名が正しいだけで稼働中ゾーンへ直書きしないことだ。対象をNS、グルー、DSと鍵管理に絞り、CDS/CSYNC相当の整合性確認、監査、プロビジョニング系との接続を行う。

通常ルールでは、child.parent.への更新は同じ名前を持つ信頼済みSIG(0)鍵で署名されなければならない。ある子の鍵が別の子を変更するのを防ぐ境界である。多数の子を扱うレジストラ鍵など別方式を採る場合、受信側は各変更の委任を別の方法で保証する責任を負う。

名前の一致は作用範囲を定める。鍵を信頼する根拠までは作らない。

knownは保留であり、半分の信頼ではない

最初のUPDATEは、新しいKEYの追加と古いKEY集合の削除を要求し得る。新しい鍵自身の署名が正しければ、受信側は候補鍵を知ったことになる。草案はこの状態をknownと呼ぶ。

次に、選択した方式で権限を検証する。成功して初めてtrustedとなる。失敗すれば候補を信頼せず、従来の鍵を残す。再ブートストラップでも、新鍵の検証前に旧鍵を削除してはならない。

順番には具体的な防御効果がある。攻撃者はいつでも鍵を作って自己署名できる。候補が到着しただけで旧鍵を消せるなら、承認を得られなくても正規運用を止められる。旧鍵の存続は「提案する力」と「置き換える力」を分離する。

管理画面も状態を潰してはいけない。「登録済み鍵」と一語で表示すると、受領、審査中、失敗、信頼済みが混ざる。いつ誰が、どの証拠とポリシーで昇格させたかを履歴として残す必要がある。

ブートストラップ経路によって証明主体が変わる

署名済みの子は、ゾーン頂点にSIG(0)公開鍵を置き、親がDNSSEC連鎖を検証できる。子が未署名でも、権威ネームサーバーの一つが署名済みゾーン内にあれば、その運用者が自分のゾーンの特別な名前で鍵を再公開できる。DNSSECによる検証は得られるが、DNSサービス事業者との調整が新たに必要であり、その内部手順は草案の外に残る。

署名連鎖を使えない子については、複数地点、複数時刻、可能なら複数トランスポートでKEYを観測し、一致を確かめるunsigned方式がある。一時的な経路上攻撃には強くなる。しかし証明されるのは、その期間に権威サーバーの応答を制御した運用者であって、登録者本人ではない。草案自身が最も弱い自動方式と位置づける。

手動方式も選べる。認証済みポータルで登録情報と照合する場合もあれば、メールやサポート交換の場合もある。手動という名称から保証水準は分からない。誰を何の記録で確認したか、チャレンジが変更対象に結び付いたか、復旧や例外を誰が承認したかが品質を決める。

親側は、先に認可したい主体を定義すべきだ。DNS運用者、登録者、レジストラアカウントの管理者、署名ゾーンの管理者は一致することも、分かれることもある。一人への正しい証明を、別の役割への証明として使ってはならない。

方式の広告も証拠になる

DSYNCターゲットのSVCBにbootstrapパラメータを置けば、親はat-apex、at-ns、unsigned、manualのどれを受けるか示せる。子は利用可能な手続きを発見できる。

だが、選択肢を書き換えられれば結論も変わる。未保護の広告を偽造して強い方式を隠し、unsignedだけを見せるダウングレードが考えられる。草案は、DNSSECを使える親がSVCBを署名し、子が満たせる最強方式を優先するよう勧める。

したがって監査記録には採用方式だけでなく、広告された全方式、広告の検証結果、子側の能力、選択規則を含めるべきだ。弱い試験に誘導された後でその試験に合格しても、強い権限証明にはならない。

NOERRORの後に公開工程が残る

信頼済み鍵からのUPDATEであっても、受信側は範囲、レコード、整合性、ローカルポリシーを確認する。NOERRORは受領と受理の確認であり、草案は変更が将来親ゾーンに掲載されるはずだと説明する。掲載済みの証明ではない。

移行時にこの時間差を見落とすと危険だ。応答直後に旧ネームサーバーを止めれば、親がまだ古い委任を配っている間に到達不能になる。DS更新でも、受理を掲載と誤認すればDNSSEC検証の不整合を招く。

鍵を知る、鍵を信頼する、変更を受理する、親で公開する。この四段階には別々の時刻と失敗がある。BADKEY、検証待ち、検証失敗、ポリシー拒否、プロビジョニング遅延を一つの「更新失敗」に丸めれば、復旧手順も誤る。

逆方向の認証も必要になる。親は子の署名を確かめるが、子が鍵状態の応答を自動処理するにはReceiver側の署名を信頼できなければならない。偽応答は委任を直接変更できなくても、不要な再ブートストラップや停止を引き起こせる。

権限移行記録を残す

私は、初回と再ブートストラップごとに権限移行記録を作ることを提案する。DNSOP仕様に新しい必須項目を求めるものではない。trusted=trueが循環的な自己証明ではなく、説明できる判断から生まれたと示すための運用記録である。

親と子、Receiver、DSYNC応答と検証状態、ソフトウェアとポリシー版、旧鍵と候補鍵の指紋、自己署名UPDATEのダイジェスト、署名時刻を固定する。広告された方式、子が利用できた方式、選択理由も残す。

DNSSEC経路なら問い合わせ名、連鎖、検証器、時刻、結果を記録する。unsignedなら観測地点の独立性、時刻、トランスポート、完全な応答指紋、一致判定を保存する。手動なら認証セッション、確認した権限記録、チャレンジ、審査者、復旧と例外を非公開参照として結ぶ。

known、検証開始、失敗、trusted、旧鍵置換、失効を別イベントにし、新鍵成功前に旧鍵が生きていたことを示す。運用UPDATEには具体的差分、検査、ポリシー判断、応答、プロビジョニングIDを結び、最後に親の権威サーバーで新しいRRsetを観測した時刻を加える。

自動化の価値は、判断を消すことではなく、正しい場所に置くことにある。鍵は自分の所持を証明できる。自分の権限までは署名できない。

出典

  1. DDNSによるDNS委任管理の自動化・第02版
  2. DNSOP草案のDatatracker情報
  3. 草案履歴
  4. DNSOP文書一覧
  5. DNSOP作業部会
  6. RFC 9859：一般化DNS通知
  7. RFC 2136：DNS動的更新
  8. RFC 2931：DNS要求・トランザクション署名
  9. RFC 3007：安全なDNS動的更新
  10. RFC 8078：CDS/CDNSKEYによる親側DS管理
  11. RFC 7477：DNSの子から親への同期
  12. The Policy Mirror