[第126回IETF Meeting] DNS関連WG・周辺ミーティングの状況

▽DNSSEC鍵の復元（draft-ietf-dnsop-dnssec-keyrestore）

DNSSECにおいて、ゾーンの運用者が秘密鍵を使えない（Inoperatble）状態になった場合の鍵の復元に関する手順と、運用上の指針をまとめた提案です。

DNSSECでは、ゾーンの運用者が自身の秘密鍵でゾーンデータを署名します。そのため、何らかの理由[1]によって秘密鍵が使えない状況になった場合、ゾーンの変更や再署名ができなくなります。提案では、DNSSEC鍵の更新（ロールオーバー）の手法を応用することでDNSSECによる保護を維持したまま、新しい鍵ペアに取り替えることで鍵を回復させる手順と留意点がまとめられています。

なお、本提案では事前署名（事前に署名した静的なゾーンデータを使う形式）によるゾーンの運用を想定しており、DNS応答時に動的に署名を生成するオンライン署名は、考慮の対象外としています。

WG参加者の反応は概ね肯定的で「TTL [2]と署名の有効期間の比較について詳細に記述して欲しい」「実装に関するセクションを設けるべき」などのコメントがあり、継続して作業を進めることとなりました。

▽EDEによるネガティブトラストアンカーの伝達（draft-farrokhi-dnsop-ede-nta）

リゾルバーが応答を返す際に、ネガティブトラストアンカー[3]が有効であったことを問い合わせ側に通知できるようにするための機能拡張の提案です。

本提案では、RFC 8914で定義される拡張DNSエラー（EDE）を使い、ネガティブトラストアンカーが有効であったことを問い合わせ側に伝達するための仕様を定義しています。本提案はCloudflareが運用する1.1.1.1で既に試験運用されており、7月3日に発生した.al（アルバニア）のDNSSEC運用ミスによる検証エラーの発生時に使われた旨のブログが公開されています[4]。

発表では、IANAが本提案のEDEのコードとして33を割り当てたこと[5]、複数のオープンソースDNSソフトウェアベンダーにパッチを送付しており、一部の実装にはマージ済みであることなどが紹介されました。WG参加者の反応は概ね好意的で、継続して作業を進めることとなりました。

▽DNSエラーへのTTLの追加（draft-homburg-dnsop-dettl）

DNSのエラー応答にTTLを追加できるようにする、機能拡張の提案です。

DNSでは、応答するリソースレコード（以下、RR）をキャッシュに保持してもよい時間をTTLで指定します。応答するRRが存在しない不在応答（NXDOMAIN応答、NODATA応答）では、Authorityセクションに設定されたSOA RRの情報をネガティブキャッシュ[6]として使います。

しかし、DNSのエラー応答、例えばSERVFAIL応答やREFUSED応答にはネガティブキャッシュに相当する仕組みがなく、応答をキャッシュできる時間はRFC 9520により、最大5分に制限されていました。

本提案では、権威DNSサーバーの運用ミスやトラブルでこうしたエラーが発生した際にフルリゾルバーの負荷が高くなってしまうことが問題点として指摘され、エラー応答のAdditionalセクションにネガティブキャッシュに相当する情報を追加し、受け取り側が任意に使えるようにすることで問題の解決を図っています。

WG参加者からは「アイデアは良いが詳細については追加の検討が必要」「EDNS0を使う方がいいのではないか」「攻撃者に悪用される可能性もある」「セキュリティ面での検討が必要」「セキュアな通信路に限定するなどの対策が必要なのではないか」などのコメントがあり、継続して作業を進めることとなりました。

▽Optimistic DNS（draft-gakiwate-dnsop-optimistic-dns）

期限切れのキャッシュを活用して、名前解決のパフォーマンスを向上させる「Optimistic DNS」の仕様を定義する機能拡張の提案です。提案者はAppleの技術者で、macOS/iOSのmDNSResponderに実装され、デフォルトで有効になっています[7]。

リゾルバーは通常、期限切れのキャッシュを参照しません。Optimistic DNSはスタブリゾルバーに実装される機能で、期限切れのキャッシュを保持し、アプリケーションからそのキャッシュに合致する名前解決要求を受け取った際にその内容を即座に返し、それと同時にフルリゾルバーへの名前解決要求も並列実行することでアプリケーションが応答を待つ時間の削減と、名前解決の一貫性を両立させることを意図しています。

Optimistic DNSと同様に期限切れのキャッシュを活用して名前解決を継続する機能として、RFC 8767で定義されるserve-staleがあります。serve-staleはフルリゾルバーで実装される機能であるのに対し、Optimistic DNSはスタブリゾルバーで実装される機能であるという違いがあります。

WG参加者からは「DNSプリフェッチ[8]と比較したデータはあるか」「さまざまなリゾルバーと組み合わせて検証する必要がある」「以前は期限切れのキャッシュを使うことに強い不快感があったが、現在は好意的に捉えている」「本番環境で既に使っており、問題は発生していない」「期限切れのキャッシュを長時間使うと問題が発生するのではないか」などのコメントがあり、継続して作業を進めることとなりました。

▽基本仕様の作業状況（draft-ietf-dnsop-delext、draft-ietf-deleg）

これまでの議論で、DELEGの基本仕様は委任そのものを再設計するdraft-ietf-dnsop-delextと、DELEG RRとDELEGPARAM RRを使った新しい委任の仕様を定義するdraft-ietf-delegの、2本の提案に分割されることとなりました。

それぞれの提案がカバーする内容は、以下となります。

1. draft-ietf-dnsop-delext（以下、delext提案）

delext提案は、委任に使われるRR一般について、それらを機能させるために必要な権威DNSサーバー・フルリゾルバー・DNSSECバリデーターの仕様変更、委任における脅威モデルの考察、関連するRRのIANAへの登録をカバーしています。

既存のDNSプロトコルを変更する内容であるため、dnsop WGの提案となっていますが、後述するdeleg提案と共に、deleg WGで作業が進められています。

2. draft-ietf-deleg（以下、deleg提案）

deleg提案は、委任そのものを再設計する部分がdelext提案に移動され、DELEG RRとDELEGPARAM RRの具体的な形式と、それらのRRで実現される新しい委任の仕様をカバーする形に再構成されています。

今回のWGでは、delext提案とdeleg提案のそれぞれの著者から、前回のIETF 125以降の作業状況と、主なDNSソフトウェアにおける実装状況が発表されました。今後、2本の提案を一まとめにした形でレビューが進められ、WGの最終案が確定される予定です。

▽安全なトランスポートの実現（draft-hoffman-deleg-secure-transports）

DELEGの基本仕様が固まってきたため、今回のWGではDELEGを使った安全なトランスポートの実現に関する提案が発表されました。提案にはDELEG RRとDELEGPARAM RRに追加するkeyのタイプとして、以下の3種類が定義されています。

• 安全なトランスポートを示す「secure-transport」
• 従来のDNS通信のサービスを提供しないことを示す「no-do53」
• 安全なトランスポートのための証明書の公開鍵を記述する「tlsa」

発表者からは、本提案の初版を5月に公開したが、DELEGの基本仕様の議論が最終段階に入っていることもあり反応が少なかったことが共有され、提案内容のレビューやソフトウェアへの実装はDELEGの基本仕様の確定後になる旨の見通しが示されました。

▽一つの名前解決に要するDNS問い合わせは何回か？

ISCのOndřej Surý氏から「How many DNS queries does it take to resolve one name? - A cold-cache tour through delegations, CNAMEs, and PTRs（参考訳：一つの名前解決に要するDNS問い合わせは何回か？-委任、CNAME、PTRを巡るコールドキャッシュツアー）」と題した発表が行われました。

発表では最初に、何もキャッシュされていない「コールドキャッシュ」の状態から「dnssec-stats.ant.isi.edu」のIPv6アドレスのPTR RRをBIND 9.18のフルリゾルバーで名前解決すると、329回という多数の問い合わせが必要になる旨が示されました[9]。

その後、DNS問い合わせの数が増える理由・ケースとして、

• In-domainでない委任
• 多段のCNAME RR
• Unrelatedな委任の段数が多くなる逆引き
• 特に、ニブル（4ビット）ごとに区切られ、委任の段数も多いIPv6の逆引き

が挙げられました。また、2025年10月に報告されたキャッシュポイズニングの脆弱性（CVE-2025-40778）[10]を修正するためにBIND 9.20.14でSibling domainのグルーレコードを受け入れないようにしたことで[11]、必要な問い合わせの数が増加したことも、理由として挙げられました。

なお、発表ではBIND 9.21.20で階層構造をたどる際の動作を親中心（parent-centric）に変更したため[12]、それ以降のBIND 9では必要な問い合わせの回数が大幅に減少したことも発表されました。

最後に、問い合わせの回数を減らすために取りうる方策が、それぞれのDNS運用者ごとに示されました。

• 権威DNSサーバーの運用者
  • 可能な場合、In-domainで委任する
  • 外部のDNSサービスを使う場合、ネームサーバーのTLDを一つか二つにする
  • CNAMEの段数に注意する
  • 逆引き（PTR）の委任においても可能な限り、グルーレコードを保持する
• マネージドDNSサービスの提供者
  • 自身のネームサーバーホスト名の委任にはIn-domainを使う
• フルリゾルバーの運用者
  • Aggressive NSECを有効にする
  • 最新バージョンに更新する

▽現在の検討状況

Side Meetingの共同チェアを務めるPeter Thomassen氏から、PQ DNSSECの現在までの検討状況が発表されました。

発表では、今回のSide Meetingは6回目で、IETFのWGになっていないこと、現時点では解決方法や解決に向けた計画がないことが改めて示され、後述するMTLを使ったDNSSECの再設計やアルゴリズムの導入、運用における解決など、いくつかのアイデアや活動が進められているが、問題全体の解決には至っていないことが示されました。

▽MTLを使ったDNSSECの再設計（draft-sheth-pqc-dnssec-strategy）

Verisign LabsのAndrew Kaizer氏から、MTLを使ったDNSSECの再設計の状況が発表されました。提案はインターネットドラフトとして公開されています[14]。

現在の提案は、MTLをDNSSECに導入する際の戦略と運用上の留意点を説明し、今後のテストや導入に向けた推奨事項をまとめています。

▽現在のDNSSECへの影響を最小限に留めるためのアイデアの検討

Swedish Internet FoundationのJohan Stenstam氏から、現在のDNSSECへの影響を最小限に留めるための、三つのアイデアが発表されました。

一つ目は、量子コンピューターが秘密鍵を解読する前に鍵の自動生成・自動更新を使って、鍵署名鍵（KSK）を素早くロールオーバーしてしまう方法です。この方法は、より高パフォーマンスな量子コンピューターが普及するまでのつなぎの手法として紹介され、かつ、親ゾーンがRFC 9859で定義されるDSYNC RRを使った、DS RRの安全な自動更新をサポートしている必要があります。

二つ目は、KSKには強いポスト量子暗号を使って攻撃耐性を確保し、ゾーン署名鍵（ZSK）には署名サイズが小さくなるポスト量子暗号を使い、ZSKのロールオーバーを高頻度化することで、署名サイズを小さくする方法です。

三つ目は、KSKとZSKを分離せず、ポスト量子暗号を用いた一つのCSK（Combined Signing Key）で運用する方法です。この場合、すべてのDNS応答がTCPによるものとなりますが、応答を64キロバイト以内に収めることで、従来のDNSプロトコルでDNSSECを運用できます。

いずれのアイデアも検討中のもので、今後追加の検討・検証が必要になりますが、従来のDNSSECの運用と親和性があり、現実的な妥協点と成り得る可能性があります。