個々のDNSルートサーバーで利用される名前構造は本当に最適か? – RSSAC028とStudy Reportのご紹介 –

今回は、ICANNが公開している技術政策文書シリーズの中からRSSAC028 Technical Analysis of the Naming Scheme Used For Individual Root Serversと、その勧告に基づいた調査レポートであるRSSAC028 Implementation study reportをご紹介します。前者はRSSACによる勧告ですが、後者は委託を受けたNLnet LabsとSIDNによって執筆されRSSACに提出されたものです。本記事中では前者を「RSSAC028」、後者を「Study Report」と表記することにします。

DNSのルートゾーンを提供するルートサーバーは現在13系統があり、それぞれのサーバーにはroot-servers.net.ドメインの名前がつけられ、root-servers.net.ゾーン自体もルートサーバーによって提供されています。この名前構造(ネーミングスキーマ)はroot-servers.net.ゾーンがルートサーバーに委任された1995年からおよそ30年に亘り機能し続けてきましたが、RSSACでは現在の名前構造に対する詳しい研究と他に取り得る名前構造の検討を行いました。

検討された名前構造

RSSAC028では大きく分けて6種類の名前構造について調査・検討を行いました。以下でそれぞれの名前構造について、Study ReportのAppendix C.から引用した図を用いて簡単に説明します。

図中では円とその中に書いてある文字列がゾーンを、円の外に書いてある文字がルートサーバー自体の名前を示しています。ルートゾーンを表すラベルはnullであるため、何も書いていない円はルートゾーンを表していることになります。

5.1 現在の名前構造

現在の名前構造では[a-m].root-servers.net.の権威サーバーがroot-servers.net.ゾーンをホストしており、root-servers.net.ゾーンの上位にはnet.ゾーンとルートゾーンが存在します。この中でnet.ゾーンはルートサーバーによってホストされていないため、ルートサーバー基盤の外であるnet.ゾーンで障害が発生するとroot-servers.net.ゾーンにも障害が発生します。また、net.ゾーンとルートゾーンはDNSSEC署名されていますが、root-servers.net.ゾーンは署名されていません。このため、RSSAC028ではDNSスプーフィング攻撃に対して脆弱だと指摘されています。

5.2 現在の名前構造でDNSSEC署名を行う

文字通り、上述の名前構造を維持したままroot-servers.net.ゾーンにもDNSSEC署名を行うものです。これによりDNSSECを検証するリゾルバーではプライミング^[1]時にプライミング応答を検証できるようになります。ただし、プライミング応答の内容やグルーレコードを信頼するかなど、権威サーバー実装とリゾルバー実装の組み合わせ次第で挙動が異なることになります。

5.3 ルートゾーン内の名前を使う

ルートサーバーの名前を[a-m].root-servers.や[a-m].などルートゾーン内の名前にする(ゾーンカットや委任を一切行わない)名前構造です。これにより、リゾルバーの動作に必要な情報をnet.ゾーンなど他の権威サーバーに頼ることなくすべてルートサーバーから提供でき、理想的にはプライミングで複数回クエリする必要がなくなります。ただし、DNSSEC署名を前提とすると、プライミング応答に13のグルーレコードとそれに対する26のRRSIGレコードが含まれるため、UDPのパケットサイズが標準的なMTUを越える可能性があります。

5.4 共通の専用TLDを委任する

ルートサーバーの名前を[a-m].root-servers.などにして、(この例では)root-servers.という新しいルートサーバー専用のTLDを別の権威サーバーに委任する名前構造です。このTLDにはarpa.ゾーンを使用するなどの策も挙げられますが、いずれにせよTLDの検討を十分に行う必要があります。また、DNSSEC署名を前提とすると、5.2と同様の懸念点が発生します。

5.5 各ルートサーバー運用者(RSO)に名前を委任する

ルートサーバーの名前を[a-m].や[a-m].root-servers.などとしてルートゾーンからゾーンカットし、それぞれのゾーンを各々のRSOに委任する名前構造です。これによりDNSSECを前提とした場合でもプライミングの最初の応答サイズを小さくできる反面、DNSSECの運用ポリシーが各RSOの采配や事情によって異なる可能性があります。また、関係するDNSSEC署名の数自体や実施回数が増えるため、その分失敗のリスクが増えます。

5.6 全てのルートサーバーを一つの名前にまとめる

ルートサーバーの名前をall-root-servers.やroot-servers.のような単一の名前に統一して、その名前に対して13のA/AAAAレコードを登録する名前構造です。この名前はルートゾーンにあるので、リゾルバーの動作に必要な情報をすべてルートサーバーから提供します。また、RRSIGレコードも2つだけ^[2]のため、理想的には現実的なサイズのプライミング応答パケット一つにすべての情報を載せることができます。ただし、リゾルバーの実装(再送制御単位)によっては13系統あるルートサーバの一つでもSERVFAILやREFUSEDを返すとリゾルバーはそれ以上の名前解決ができなくなる恐れがあります。この問題は実装だけでなくDNSのプロトコルレベルでの修正が必要です。

RSSAC028での勧告

以上のような名前構造を検討した結果、RSSA028ではICANN理事会に対して主に4点の勧告を行っています。

勧告1: さらなる研究が行われるまでは、現状のルートサーバーシステムで使われている名前構造を変更すべきではない。

勧告2: 現状のDNSリゾルバーの振る舞いと、検討された各名前構造がその振る舞いに与える影響について、研究すること。

この勧告2によって行われ報告されたのがStudy Reportです。Study ReportのMain Analysisでは以下の順を追って検証しています。

1. Acceptable response sizes: DNS Flag Day 2020で推奨されている応答サイズ(1232byte)と、各種研究で明らかになった実際に運用されているサーバーの応答サイズの調査
2. Reproducing RSSAC028 Appendix A. results: RSSAC028 の中で簡単に検証された各種実装の挙動を再検証
3. Priming responses from all root server software: 考案された各名前構造を取ったときに、ルートサーバーで現在使用されている実装と同じものから得られるプライミング応答についての検証
4. Testbed results: メジャーなリゾルバー実装を使ったテストベッドにて、前項の応答がどのような動作を引き起こすかの検証

詳細な研究内容や結果については、各項目ごとにとても細かに記載されているため、ここでは割愛させていただきます。

勧告3: Node re-delegation attackの影響と忍容性について、研究すること。

Node re-delegation attackは、カミンスキー・ミュラー攻撃と同様のDNSリゾルバーに対するキャッシュポイズニング攻撃です。DNSSEC検証を行っていないリゾルバーに対して偽の委任応答を送りつけることにより、あるゾーン以下の名前解決を一定期間正規の権威サーバーではなく攻撃者の権威サーバーへ送ることになり、ルートゾーンへの偽の委任応答を送りつけることですべての名前解決について攻撃者の用意した偽の権威サーバーに問い合わせを送らせることができる可能性があります。詳細はImproved DNS Spoofing Using Node Re-Delegationという論文にて説明されています。

勧告4: プライミング応答のサイズを抑制する方法について、研究すること。

Study Reportでの議論および結論

Study Reportではまとまった文章ではなくデータセットの提供自体が結論となっている議論もあるため、ここではそのような詳細なデータは割愛します。

プライミングクエリの適切な応答サイズについて

推奨されている値や実際の設定値などを調査しました。RSOの調査を行い、実際に使用している権威サーバー実装でのシミュレーションを行い、それらが与える影響について調査しました。

グルーレコードが減少した場合のリゾルバー実装の挙動について

テストベッドを用いて検証しました。既存の名前構造・実装でのプライミング応答の多くはadditional sectionのルートサーバーのアドレスセットが一部もしくは完全に欠如しています。グルーレコードが欠けている場合、主要な実装のうちPowerDNS Recursor以外の全てのリゾルバー実装では、追加の検索を行った後名前解決できなくなります。また、BINDとPowerDNS Recursorでは、ビルド時に指定したりroot hintsにあったりするものと同じNSレコードセットについて、新しいIPアドレスをキャッシュできなくなります。

不正なプライミング応答のリゾルバー実装での扱いについて

DNSSECの有効期間とリゾルバーの時刻のズレが与える影響を調査しました。その結果、ズレがある場合にPowerDNS RecursorとKnot Resolverの特定バージョンでは完全に機能しなくなることが分かりました。これは、プライミング応答を適切にDNSSEC検証している場合に起こる挙動です。

サーチリスト^[3]への影響について

各名前構造でのサーチリストへの影響をsystemd-resolvedを使用して検証したところ、名前解決およびDNSSEC全般、テストで用いたドメイン名の単一文字のラベル名で影響はありませんでした。

まとめ

今回の話題は一般的なDNSゾーンでの名前構造を考える一助になる構成例や、普段のDNS運用でも役立てられる調査結果などについて簡単にまとめました。

RSSAC028では、日々発見される新たな脅威に基づき、これまで運用し続けてきた名前構造自体の見直しを検討しましたが、名前構造の変化自体がインターネットの可用性に及ぼすの影響を考慮し、最終的には現在の名前構造を維持することを決定・勧告しました。しかし、これが即ち、考え無しにこれまでの運用を継続すれば良いということではなく、最善の運用は常に変化する可能性があることを示唆しています。また、勧告やStudy Reportではそれに備えて研究を行う必要性を示しています。

このように、既存の運用の見直しや必要な調査はインターネット全体の根幹をなすDNSルートゾーンにおいても行われています。

付録

Study Reportに記載されている調査で分かったことのうち、今回の結論には直接関係しないものの、DNS実装を運用する上で参考になる知見がいくつかあったため、付録としてまとめます。

各RSOが使用している実装やパラメーター

Study Report記載の、調査時点で各RSOが使用している権威サーバー実装などについて、表で記載します。現在実際に使用されているバージョン等とは異なっている可能性があることにご留意ください。また、調査時点で変更が予定されているシステムについては→を使って右側に変更予定先のシステムについて記載します。

挙動の調査に使用したテストベッド環境

リゾルバーテストベッドはICANNによって開発され、さらにアップデートや自動化が行われたものが調査に使用されました。使用されたテストベッドは、現在ICANNのGitHubレポジトリにて公開されています。

https://github.com/icann/resolver-testbed

リゾルバー実装ごとの挙動

Study Reportに記載されている、リゾルバー実装とバージョンごとの重要な挙動について、表で記載します。なお、調査時点ではリリースされていない新しいバージョンでも挙動が変わっていないかについては本文書では保証しません。

^[1] リゾルバーは最初のクライアント(スタブリゾルバー)からの名前解決要求を処理する前(付録-リゾルバー実装ごとの挙動 を参照)に、ビルド時や設定ファイルなどで指定されたroot hintsファイルを元に、最新のルートサーバーのIPアドレスの名前解決を行い、これを元に以降の名前解決要求を処理します。この動作をプライミングと呼びます。

^[2] DNSSECの署名(RRSIGレコード)は各個のリソースレコードではなくリソースレコードセット(名前・クラス・タイプが同じレコードの集合)ごとに生成されます。

^[3] ユーザーがアプリケーションにドメイン名を入力しそのドメイン名が名前解決できなかった(NXDOMAIN)ときに、そのドメイン名がFQDNではない可能性があるため、サーチリストに事前に登録されたドメイン名をユーザーが入力したドメイン名の前や後ろに加えたドメイン名などで再度名前検索を行うことがあります。SAC064で詳しく触れられています。