「ちょうどいいDNS」ってどういうもの？ その設定・運用のために必要なこととは

株式会社日本レジストリサービスの森下泰宏氏と熊谷維魅氏が「ランチのおともにDNS」で講演した

　「Internet Week 2024」において11月26日に行われた恒例の「ランチのおともにDNS」では、「ちょうどいいDNSの設定と運用のために必要なことを考える」をテーマとして、株式会社日本レジストリサービス（JPRS）の森下泰宏氏と熊谷維魅（くまがい いみ）氏による講演が行われた。

　インターネットが始まった当時、プロトコルは厳密さよりも柔軟性を優先して開発されていた。性善説に基づく牧歌的な時代でもあり、使い方をプロトコルによって過度に制限しないことのメリットは大きかったのではないかと想像される。しかし、現在ではそのことが仕様における弱点となり、さまざまな対策が求められるようになっている。

　本講演はそうした点に着目し、「DNSにおいて適切な上限値が設定されていないことが原因となった脆弱性・サイバー攻撃の事例を紹介・考察しながら、それらの状況に適切に対応でき、安定的かつ柔軟で限界を超えない『ちょうどいいDNS』を実現するために必要なことについて、『上限値』をキーワードにひも解いていきたい」（森下氏）というものである（図1）。

図1　本日の内容

DNSはプロトコルによる上限値の設定が緩めである

　講演は、熊谷氏による「DNSのプロトコルにおける上限値はどうなっているのか」という状況説明から始まった。DNSが開発された際、プロトコルにおける上限値がいくつか設定されたが、項目としては多くなかった。熊谷氏は、「DNSが開発された1980年代はTCP/IPのインターネットが作られ始めたばかりであり、プロトコル仕様はまだ緩かった」と述べ、上限値が設定されているもの／いないものについて表形式に整理した図を使い、説明を行った（図2、図3）。

図2　DNSプロトコルにおける上限値

図3　上限値が設定されていない項目

　図を見ると分かる通り、上限値が設定されているものはメッセージサイズやラベルの長さといった、プロトコルの基本仕様から生まれる制約が中心である。一方で、1つのゾーンのレコード数や委任されるゾーンの数、サブドメインの深さなどの個別の項目については、明確な上限値が設定されていない。

　そのような決まり事がある場合、使い方によって結果も変わってくる。例えば、ドメイン名の長さは最長で253文字となっている。各階層のラベルを制限いっぱいの63文字近くまで使うと、せいぜい4階層までしか設定できない。しかし、各階層のラベルを数文字で済ませれば、相当に深い階層まで設定できることになる。また、現在の.comのゾーンには1億以上の委任が存在するが、問題なく動いている。仮に、これらについて当時のハードウェアやソフトウェアの能力を前提として「これは、ここまで」「これは、こう使わなくてはいけない」といった制約を作っていたら、どうなっていたであろうか？

　これらの項目の一部には、実装や運用で上限値が設定されている項目も存在する（図3において赤枠で囲まれた部分）。実際の処理時間が許容できないくらい長くなっては運用に耐えられないし、例えばwww.example.jpの正式名がwww.example.comと指定されているときにwww.example.comの正式名がwww.example.jpと指定されていると、名前解決が循環して終わらなくなってしまう。運用においてこのようなケースが想定される場合、実装において歯止めをかける必要がある。そのため、名前解決におけるCNAME RRの段数や名前解決におけるUnrelated[*1] [*2]な委任の段数はプロトコルにおける上限値は設定されていないが、それぞれの実装で上限値が設定されている（図4、図5）。

図4　名前解決におけるCNAMEレコードの段数

図5　名前解決におけるUnrelatedな委任の段数

　今回の資料はJPRSのウェブサイトですでに公開されているため、詳細を知りたい方はそちらを参照していただきたいが、同様に、RRsetごとのレコード数やゾーンごとのネームサーバーホスト名の数、ゾーンごとのDNSSEC鍵の数・レコードごとのDNSSEC署名の数といった値にも、プロトコルにおける上限値は設定されていない。図6は最初のパート「DNSにおける上限値の状況」のまとめであるが、プロトコルの上限値が緩やかな部分を、実装・運用でカバーしている状況が示されている。

図6　このパートのまとめ

実装・運用の上限値は、DNSを安定稼働させるために設定された

　続いて森下氏が、上限値が設定されていないことで発生した脆弱性の事例として、「iDNS Attack[*3]」「NXNSAttack[*4]」「TsuNAME[*5]」「KeyTrap[*6]」の4つを説明した（図7、図8）。いずれも、権威DNSサーバーに設定した攻撃用のデータを名前解決で注入して、フルサービスリゾルバー（キャッシュDNSサーバー）を攻撃する脆弱性である。本稿ではそれらの詳細には触れないが、脚注にそれらの解説に関するいくつかのリンクを示したので、興味のある方は参照してほしい。

図7　このパートで紹介・解説する脆弱性

図8　脆弱性を発生させる仕組み

　iDNS Attackは、深い階層の委任情報をたどらせてフルサービスリゾルバーを攻撃する手法である。ドメイン名の管理者は、サブドメインの管理権限を第三者に委任できる。委任された第三者はさらにサブドメインを作り、別の第三者に委任できる。この仕組みを悪用し、委任を延々と繰り返していくことで、（何かしらの歯止めを設けていなければ）フルサービスリゾルバーは委任情報を無限にたどることになる（図9）。したがって、その対策は名前解決の動作に上限値を導入することになる（図10）。CVE-IDが複数あるのは、実装ごとにIDが割り当てられたためである。

図9　iDNS Attack

図10　iDNS Attackの対策

　NXNSAttackは、標的のドメイン名に存在しないサブドメインを付加した多数のネームサーバーホスト名を委任情報に設定することで、委任情報を処理するフルサービスリゾルバーと標的のドメイン名の権威DNSサーバーを攻撃する手法である（図11）。ドメイン名圧縮を利用することで多数のネームサーバーホスト名を設定可能であり、かつ、フルサービスリゾルバーの実装によっては効率を高めるため、設定された委任情報を同時に名前解決しようとする動作を利用し、攻撃の効率を高めている。つまり、委任情報に存在しない多数のサブドメインを設定して、フルサービスリゾルバーにランダムサブドメイン攻撃をさせるわけである。対策は、名前解決の動作に上限値を導入すること、名前解決の動作を工夫することになる（図12）。

図11　NXNSAttack

図12　NXNSAttackの対策

　TsuNAMEは、循環参照を意図的に発生させた委任情報を処理させ、フルサービスリゾルバーに委任情報のドメイン名の権威DNSサーバーを攻撃させる手法である（図13）。複数のパブリックDNSサービスが脆弱性の対象であり、実際にGoogle Public DNSが対象であったため、大量のクエリが発生した実例がある。対策としては委任情報をたどる回数に上限値を設定することで、ループを回避することになる（図14）。

図13　TsuNAME

図14　TsuNAMEの仕組み

　KeyTrapは、DNSSECにおける鍵の更新や運用者の変更を実現するため、1つのゾーンに複数の鍵を設定でき、1つのRRsetに複数の署名を追加できるようにしているという仕様を突いて、フルサービスリゾルバーを過負荷にする攻撃である（図15）。鍵タグを意図的に衝突させた多数の鍵を設定したゾーンを作成し、検証に失敗する多数の署名を持つDNSデータを検証させることで検証にかかるコストを増大させ、フルサービスリゾルバーの名前解決を妨害する（図16）。対策は、各実装でDNSSEC検証の作業量を抑制する上限値・仕組みを導入することで実施されている（図17）。

図15　KeyTrap

図16　KeyTrapの攻撃イメージ

図17　KeyTrapの対策

　図18は、このパート「これまでに報告された脆弱性の事例」のまとめである。ここまで見てきて分かるとおり、プロトコルにおける上限値が設定されていないことがDNSにおけるさまざまな脆弱性の原因となり、その対策として実装で上限値が設定され、DNSの安定運用が図られてきたという経緯が分かると思う。

図18　このパートのまとめ

それぞれの役割を果たし、連携し合って活動を続けていくことが重要

　最後のパートは、「ちょうどいいDNSのために必要なこと」と題され、森下氏と熊谷氏の掛け合いという珍しいかたちで進められた。

　まず熊谷氏が冒頭で、先に述べられたさまざまな攻撃手法が編み出された背景として「フルサービスリゾルバーが頑張りすぎる」ことを指摘した（図19、図20）。注目点は、KeyTrapの論文タイトルに「The Harder You Try, The Harder You Fail：頑張れば頑張るほど失敗する」と書かれていたことと（図19）、フルサービスリゾルバーがどのような優先順位で設計されなければならないかは、1987年に発行されたDNSの基本仕様であるRFC 1034[*7]にすでに書かれていた、という2点である。RFC 1034には、「たとえ誰かがあるデータを誤って設定していたとしても、リクエストが無限ループに陥ったり、他の実装との間にリクエストや問い合わせの連鎖反応が引き起こされたりしないように、作業量（パケット送信数、並列プロセス起動数）を抑制する」と書かれている（図20）。ただ、「開発者はこの一番大事なことを忘れ、つい頑張りすぎてしまう」（森下氏）というのは、これまでの状況を考えると、その通りなのかもしれない。

図19　フルリゾルバーは頑張り過ぎ？

図20　フルリゾルバーにとって一番大事なこと

　とはいえ、フルサービスリゾルバー実装者が頑張りすぎることには相応の背景がある。図21にはそのことがまとめられているが、インターネットで長年に渡り尊ばれてきたポステルの法則[*8]と、名前解決の効率を上げたいという実装者の意思があることが指摘されている。

　ただし、ポステルの法則については過剰な適用をしないようにする見直しが進められ[*9]、2023年にIAB[*10]が取りまとめたRFC 9413[*11]において「ロバストネス原則にはソフトウェアの欠陥・サイバー攻撃・予期しない入力に対する耐性も含むため、『受信では寛容に』の過剰な適用は危険である」という旨が記載されたことが紹介されている。

図21　頑張り過ぎの背景にあること

　そこから生まれる「では、どうすればいいのか」となる問いへの回答が、まさに今回のテーマである「ちょうどいいDNS」である（図22）。ちょうどいいというのは、「過不足なく一致し、期待・目的にうまく合うこと」である。森下氏は「DNSはプロトコル・実装・運用の3つが重要で、特に運用が大事である。だから、ちょうどいいDNSを考える場合も、プロトコル・実装・運用の3つの観点で考えないといけない」と述べ、その「ちょうどいいDNS」を実現するための活動の紹介に移った。

図22　どうすればいいのか？

　最初は、プロトコルにおける活動である。ここでは、JPRSの藤原和典氏によるIETFでの提案が紹介された。「Upper limit values for DNS[*12]」と題された提案は、DNSを丈夫にするために、DNSプロトコルのさまざまな値について合理的な上限値を設定しようというものである。ただ、この件に関しては議論が始まって間もないこと、提案内容には賛否両論があり、プロトコルで使い方を制限すべきではないといった意見があるなど、まだまだこれからといった印象である。とはいえ、ちょうどいいDNSを実現するための活動の1つとして重要であろう（図23）。

図23　プロトコルにおける活動（2/2）

　実装における活動では、ISCでBIND 9の実装を担当しているPetr Špaček （ペトル・シュパチェック）氏が、KeyTrapの脆弱性が公開された際に書いた、印象的なブログが紹介された（図24）。森下氏は、「暗黒面（dark corners）という言葉が印象深い」「実装者はこれまでに何度も敗北している」と述べている。確かに、「何度も何度も、研究者たちは、この単純な指示に従わなかったという暗黒面（dark corners）を、実装者に示し続けている」という一文からは、実装者としての後悔の念が感じられる（図25）。

図24　Petr Špaček 氏（ISC）の弁明（2/2）

図25　実装における活動（2/2）

　最後に、運用における活動が紹介された。図26に書かれているが、「DNSは複数の構成要素が連携し合って動いている分散システムだから、うまく動かすにはそれぞれのサーバーやシステムを運用している関係者が、互いに連携・協調し合う必要がある」というのは、まさにその通りであろう。2019年と2020年に実施されたDNS flag day[*13]が紹介されているが、今後もそうした、インターネット全体で何かを一斉に実施するための取り組みが行われるかもしれない（図27）。

　森下氏からは本講演のまとめとして「普段から情報共有や情報交換を積極的に行い、最新動向に気を配っておくこと」が重要であり、ちょうどいいDNSの実現のためには「DNSに関わるさまざまな立場の関係者がそれぞれの役割を果たし、連携し合って活動を続けていくこと」が必要であることが、改めて強調された（図28）。

図26　運用における活動（1/2）

図27　運用における活動（2/2）

図28　おわりに：ちょうどいいDNSのために必要なこと

普段から情報共有や情報交換を積極的に行い、最新動向に気を配っておこう

　今回の「ランチのおともにDNS」で取り上げられた「ちょうどいいDNSの設定と運用のために必要なことを考える」を聞き終わって、性善説でインターネットを運用していくことが本当に難しくなってきたことと、そうした状況に対応するため、DNSをはじめとするインターネット基盤を支える関係者が不断の努力を積み重ねてきたことが、改めてよく分かった。

　普段、何気なく使っているインターネットが便利、かつ安定しているのも、その裏側に回れば技術者を中心としたさまざまな人々によって支えられているからである。最後に述べたように、やるべきことは「それぞれの関係者が普段から情報共有や情報交換を積極的に行い、最新動向に気を配っておくこと」であるから、このようなイベント（Internet WeekやDNS Summer Dayのような）を積極的に活用してほしいと思う。

ランチの時間帯に行われる「ランチのおともにDNS」では、聴講者にお弁当が配られる。その名の通り、ランチをしながらDNSに関する講演を聴けるのが特徴だ。今年は2種類のお弁当が存在したらしい