DNSの代表的な弱点「メッセージ圧縮機能」――その理由と現状を振り返り、今後の針路を考える

　DNS（Domain Name System）は、インターネットの通信プロトコルがTCP/IPに移行した1980年代から使われている、重要な基盤サービスの1つである。当時のインターネットの利用者は主に研究者や専門家であり、安全性よりも「動かすこと・つながること」に重点が置かれていた。そのため、当時の計算機やネットワークの性能の低さとも相まって、DNSのプロトコルはシンプルで動作が軽く、実装・運用が容易になることを意図して開発された。

　この考えは当時としては合理的であったが、悪意の存在を想定していなかったことが後に問題となるセキュリティ上の不備や不具合・脆弱性の要因となり、現在もDNSに携わるさまざまな関係者がそれぞれの立場で、その解決に取り組んでいる。インターネット技術の標準化を推進するIETF（The Internet Engineering Task Force）においても、それは例外ではない。

　今回、「Internet Week 2022」において11月29日に行われた「ランチのおともにDNS」では、「DNSの弱点を振り返り、今後の針路について考える」と題し、DNSの設計における代表的な弱点になっているメッセージ圧縮機能を題材として、プロトコル開発において顕在化した問題へのIETFの取り組みを含めた、今後の指針の考察と提案が行われた。

実装の不具合や運用ミスが発生しやすい「DNSの弱点」とは

　株式会社日本レジストリサービス（JPRS）の森下泰宏氏と月東健人（がっとうけんと）氏による講演は、月東氏によるDNSの弱点に関する話題から始まった。最近報告されたDNSに関する脆弱性について、何がその原因となっているかを説明するものである。

株式会社日本レジストリサービス（JPRS）の森下泰宏氏と月東健人（がっとうけんと）氏

　月東氏は冒頭で、このセミナーで取り上げるDNSの弱点を「DNSの実装・運用において弱みとして付け込まれやすい、設計上の不十分なところ・欠点・短所」と定義し、2020年以降に報告されたDNSに関する脆弱性と、その原因について説明した。

　説明では脆弱性を引き起こす代表的な原因として、「委任情報の取り扱いの不備」と「メッセージ圧縮機能の実装の不具合」の2点を挙げた（図1、図2）。そのうち、委任情報の取り扱いの不備については過去のランチセミナーで取り上げていることから、今回はこれまで取り上げていなかった、メッセージ圧縮機能の実装の不具合を扱うことにしたということであった（図3、図4）。

図1：脆弱性の原因

図2：委任情報の取り扱いとメッセージ圧縮機能

図3：委任情報の取り扱いが関係する問題

図4：委任情報の取り扱いの不備に関するこれまでの発表

　ちなみに、委任情報の取り扱いの不備の身近な例として、サービスプロバイダーの引っ越しの際に起こりがちな「DNSの切り替えがうまくいかない」というケースが挙げられる。いわゆる「DNSの浸透問題」の1つだが、これについてはINTERNET Watchでも過去に記事にしており、関係者への追加取材もしているので、関心のある方は脚注で示した参照先をご覧いただきたい[*1]。

メッセージ圧縮機能が弱点となった理由と現状

　続いて森下氏から、今回取り上げるメッセージ圧縮機能の説明が行われた。メッセージ圧縮機能は図5にあるように、DNSの応答サイズを小さくして伝送効率を上げるための仕組みである。送信側でメッセージを圧縮し、受信側でメッセージを展開するという、セットの動作で機能する。

図5：メッセージ圧縮機能の概要

　具体的な仕組みは、図6～図9で示されたとおりである。図8は、1つのDNSメッセージ中に「example.jp」「ns1.example.jp」「example2.jp」という3つのドメイン名が含まれているケースを例に、メッセージ圧縮の仕組みを説明したものである。

• すでに「example.jp」というドメイン名がDNSメッセージに存在する
• 1つ目の「example.jp」は全く同じなので、そのデータが存在する場所を示す2バイトのポインターだけで済む（10バイトの圧縮）
• 2つ目の「www.example.jp」は、「www」というラベルと「example.jp」への2バイトのポインターで構成できる（10バイトの圧縮）
• 3つ目の「example2.jp」は「jp」というラベルだけが共通なので、「example2」というラベルと「jp」への2バイトのポインターで構成できる（2バイトの圧縮）

　このようにメッセージ圧縮の仕組みは、DNSメッセージ中に存在する既出の名前を使い、名前の文字列そのものに代えて既出部分へのオフセット値（DNSメッセージの先頭から数えて何バイト目か）で指し示すことにより、データの長さを短くするというものである。森下氏は説明を行いながら、「メッセージ圧縮機能はこのように、ドメイン名を少しずつ圧縮することを積み重ねて、全体のサイズを小さくするものである」と述べている。

図6：DNSメッセージにおけるドメイン名の表現形式

図7：メッセージ圧縮機能で使用するポインター

図8：メッセージ圧縮機能の具体例

図9：メッセージ圧縮機能の概要

　ただし、メッセージ圧縮機能はその生成・解析に手間がかかる。また、展開処理において問題となり得るアンチパターン（処理・動作・構造上の不具合につながりやすい不適切な例）がRFC[*2]になっているように、プログラムとしても複雑になりがちである。

　こうした処理の手間・複雑さや、実際に20年にわたりさまざまな製品の脆弱性の原因となっている状況を鑑み、DNSで新たに標準化されるレコードのデータ部分における圧縮・展開は、RFC 1035で定義されるCNAME・MX・NS・PTR・SOAの各RRを除き、2003年に発行されたRFC 3597で明示的に禁止されている（図10、図11）。

　しかし、森下氏からはプロトコルでメッセージ圧縮が禁止されていても、送り付けられた圧縮済みメッセージを柔軟に受け入れて展開してしまう実装が存在し、脆弱性の原因となっているということが示された。さらに、メッセージ圧縮機能はDNS以外のプロトコルでも使われており、脆弱性の原因となっていることも説明された（図12、図13）。

図10：メッセージ圧縮機能に対する指摘

図11：新たに標準化されるレコードのデータ部分の圧縮・展開は禁止されている

図12：プロトコルで禁止されている応答の取り扱い

図13：メッセージ圧縮機能についてのまとめ

IETFにおける2つの活動と、われわれが取るべき今後の針路

　では、このような状況にIETFはどう対応しようとしているのか、また、それを踏まえ、われわれは今後どのような方向に舵を切っていくべきなのであろうか。この部分こそが、この講演の核心である。

　森下氏は、本題に入る前にメッセージ圧縮機能が弱点となってしまった原因を再度整理し、

1. 悪意の存在を想定していなかったこと
2. 不正な入力に柔軟に対応し過ぎる実装が存在すること
3. 使われる範囲が広いこと

の3つを挙げた（図14）。そのうえで、これらの項目に対応する活動として、IETFの活動方針と標準化プロセスを監督するグループであるIAB（Internet Architecture Board）と、IETFの活動と標準化プロセスの技術的な責任を担うグループであるIESG（Internet Engineering Steering Group）で進められている「edmプログラム」と「DNS Directorate」の2つを紹介した。

図14：メッセージ圧縮機能が弱点になってしまった原因

　edmは、IABが2020年8月に開始したプログラムである。「Evolvability, Deployability, & Maintainability」に由来しており、IETFが標準化するプロトコルの進化・普及・保守の戦略を策定・分析する文書の作成を目的としている。この中で注目すべきは、インターネットで長年にわたり重要視されてきたポステルの法則を見直す文書「draft-iab-protocol-maintenance」を作成しているという点である（図15）。

図15：「edmプログラム」の概要

　ジョン・ポステル（Jonathan Bruce Postel）氏はインターネットの創始期において、その発展に多大な貢献をした人物である。TCP/IPやDNSなどさまざまなプロトコルの開発に携わり、インターネットの共通資源を管理するIANA（Internet Assigned Numbers Authority）を創設・運営するなど、偉大な足跡を残している。

　ポステルの法則は「ロバストネス原則」と呼ばれ、「送信では厳密に・受信では寛容に」――つまり、送信するデータは仕様に厳密に則った正しいものを送り、受信するデータはある程度仕様に則っていなくてもできるだけ寛容に解釈して受け入れるという、インターネットにおけるプロトコルの設計指針を表したものである[*3]。

　draft-iab-protocol-maintenanceはロバストネス原則の過剰な適用を見直すことで、より健全なエコシステムを作ることを目的としている。具体的には、悪意の存在を想定し、予期しない（不正な）入力に対する「受信では寛容に」の過剰な適用を止めようというものである（図17、図18）。

図16：ポステルの法則

図17：ポステルの法則を見直す文書「draft-iab-protocol-maintenance」

図18：指摘されている内容

　もう1つのDNS Directorateは、IETFで作成されるさまざまな提案をDNS専門家の立場から早い段階でレビューすることで、標準化活動をより円滑にすることを目的としている（図19、図20）。今回のセミナーではDNSの弱点となったメッセージ圧縮機能がDNS以外のプロトコルでも使われ、それが脆弱性の原因になった事例が紹介されたが、DNS Directorateにはそうした状況を早い段階で見極め、よりよい方向に導くことが求められているということだろう。

図19：「DNS Directorate」の説明

図20：設立目的と活動内容

　ここまで、edmプログラムとDNS Directorateという2つの活動が紹介されたが、これらはいずれも重要な活動であり、その成否はDNSとインターネットの今後に大きく影響する（図21）。予期しない入力を過剰に許容しないようにすることはセキュリティや安定性の向上に確実につながるであろうし、DNSに関連する、または影響を及ぼす提案の標準化に早い段階で適切に対応することは、インターネット全体にとってプラスになるであろう。

図21：「edmプログラム」「DNS Directorate」の位置付け

　森下氏は講演の終わりに際して、「DNSはインターネットを支える基盤技術であり、その針路はインターネットにとどまらず、実社会を含めてそれを取り巻くさまざまなものに影響する」として、「DNSの運用者はDNS以外のことについても幅広く理解し、適切に判断することが必要になっている」ことを示した（図22、図23）。最後に、「よりよい針路を見出せるように力をつけ、みんなで頑張っていきましょう」と述べ、講演を締めくくった。

図22：今後の指針についての考察と提案（1）

図23：今後の指針についての考察と提案（2）

　確かに、最近のDNSは社会的な要請を背景としてプライバシーとセキュリティに対しても敏感になり、通信の暗号化、名前解決アルゴリズムの見直し、新たな需要を背景とした新たなリソースレコードの開発など、さまざまな機能拡張が進められている。おそらくこれからも、社会情勢も含めたさまざまなものから影響を受け、変化していくことになるであろう。

　ただし、そうした流れに対し単に受け身でいると、流されるだけになってしまう。流される側にいるのではなく、多くの人の協力を取り付け、より良い方向に進んでいくというのは望ましい姿である。そのために大事なことは日々の情報収集と内容の正しい理解であり、広い視野を持つこと、判断能力を鍛えていくことが本当に大事なのだと感じた講演であった。