イベントレポート
Internet Week 2013
DNSのUDPメッセージサイズが512バイト以下に制限された背景とは
（2013/12/2 16:34）
東京・秋葉原の富士ソフトアキバプラザで開催された「Internet Week 2013」において11月28日、株式会社日本レジストリサービス（JPRS）による恒例のランチセミナーが開催された。DNS関係者の注目を集める今回のテーマは、「DNSのメッセージサイズについて考える」。DNSのUDPメッセージサイズが512バイト以下に制限された理由や、DNSのメッセージサイズに関する標準化や検討の歴史について振り返るとともに、最近の状況や今後の展望といった話題を取り上げた。
DNSのメッセージサイズが話題に選ばれた理由
インターネット関係者の間では、DNSを悪用した“リフレクター攻撃”の存在が問題になっている。今年3月に発生した、極めて大規模なDDoS攻撃を覚えている読者の方も多いことと思う（本誌3月28日付記事「ネットを崩壊の瀬戸際に追い込んだ『史上最大のサイバー攻撃』が明るみに～早急な対策が望まれるオープンリゾルバーDNS問題」参照）。
この詳細やDNSリフレクター攻撃と呼ばれる攻撃手法そのものについてはJPRSへのインタビュー（本誌4月26日付記事「過去最大300Gbps超のDDoS攻撃に悪用されたDNSの『オープンリゾルバー』とは」）において詳しく書いたのでそちらを参照していただきたい。まずは、DNSが狙われるポイントを簡単に振り返ってみよう。悪用するための条件は、主として3つある。
1つ目は、送信元IPアドレスを詐称しやすいこと。TCPと異なり、UDPでは相手との間で通信をする際に事前確認をすることなく実際のデータを送信する仕様になっているため、送信元IPアドレスの詐称による攻撃を実行しやすい。2つ目は、攻撃に使えるサーバーがインターネット上に数多く存在していること。オープンリゾルバーや権威DNSサーバーに加え、DNSプロキシー機能を持つ家庭用ルーターの一部も攻撃に使われる危険性がある。3つ目は、攻撃の際に多量のデータを送りつけることができること。DDoS攻撃においては、小さいデータをより大きなデータに増幅してくれるDNSはとても便利な存在である。
今回のテーマである「DNSのメッセージサイズ」はこの3つ目について焦点を当て、DNSのメッセージサイズ決定の背景や問題点、対応といったものを考える材料を提供しようというものだ。確かに、1つ目のIPアドレスの詐称問題や、2つ目のいわゆるオープンリゾルバー問題はさまざまな場所で議論され関連する資料もそれなりにあるが、このメッセージサイズに関するきちんとした振り返りや議論がされている例は、これまであまり見られなかったように思う。
セミナー前半は、JPRSシステム部の堀五月氏が「メッセージサイズ決定の背景」と「メッセージサイズの検討と標準化の歴史」についてを説明し、後半では広報宣伝室の森下泰宏氏が「メッセージサイズに関する最新トピックスと検討状況」と「考察・まとめ」を説明するという構成だった。
徐々に拡大されていったメッセージサイズ
堀氏は、これまでに発行されたRFCを丹念にあたり、そこに記されている仕様を抜粋し整理したものをベースに説明を行った。DNSとDNSメッセージサイズの関係、DNSでUDPが採用された理由、当初は512バイト以下としてスタートしたDNSメッセージサイズがどのようにして拡大されていったのかといったことが整理された資料は、後々にも有用なものだ。
DNSの通信については、1987年に発行されたRFC 1034とRFC 1035に記述があり、UDPとTCPの双方を使用すること、UDPメッセージサイズは512バイトまでに制限されることが定められている。
ではなぜ、UDPメッセージサイズは512バイトに制限されたのだろうか。堀氏によると、DNSの現在の仕様であるRFC 1035に理由の記載は無いが、1983年に発行されたDNSの最初の仕様であるRFC 883にその記載があるという。そこには、「non-reliable method（非信頼型、UDPを想定）のメッセージは512オクテットに制限する」と書かれており（1オクテットとは、8ビットで構成される単位。昔は、1バイトが必ずしも8ビットでなかったためにこのような単位が使われた）、この値がRFC 1035に引き継がれたのだろうということである。
詳細については、後日公開されるであろう資料を見ていただきたいが、このようにして決まったDNSのメッセージをUDPを使って問い合わせるか、TCPを使って問い合わせるかについてはRFC 1034およびRFC 1035では明確にされていなかった。
当時のコンピューターの能力は、それほど高いものではなかった。名前解決にかかる負荷・コストをできるだけ低いものにするため、1989年発行のRFC 1123では最初に（DNSサーバーにとって負荷の低い）UDPによって問い合わせることが必須となり、同時にTCPフォールバックも義務付けられることになる。
こうして、「最初は常にUDPで問い合わせる」「応答が512バイトを超えた場合、TCPで同じ内容を再問い合わせする（TCPフォールバック）」という、DNSにおける標準的な問い合わせ手順が決まった。この手順の決定は、名前解決にかかるコストやレイテンシーの点で大きなメリットを生んだが、その一方で、メッセージサイズが512バイトを超える場合の「512の壁」といったデメリットも併せ持つことになった。
その後、DNSキェッシュポイズニング問題をきっかけとしてDNSSECが標準化された。しかし、それに伴うメッセージサイズの増加によるUDPパケットのオーバーフローとTCP通信による高いオーバーヘッドが問題になり、その対策として1999年にRFC 2671としてEDNS0が標準化されることになる。
RFC 2671では、EDNS0のサイズは「Ethernetの場合1280バイトがリーズナブル」であるとされた。しかし、現行のDNSSECの基本仕様を標準化した2005年のDNSSECbisで「少なくとも1220バイトをサポートしなければならず、4000バイトをサポートすべき」となった。そして、2013年に発行されたEDNS0の改訂版であるRFC 6891では、RFC 2671では明確ではなかった最大ペイロードサイズについて「良い妥協点は4096バイト」と定められるなど、DNSのUDPメッセージサイズは徐々に拡大していくこととなる。堀氏の説明は、こうしたことを丁寧に伝えていた。
IPフラグメンテーションが持つリスク
続いて森下氏にマイクが渡り、UDPメッセージサイズの現状についての説明が行われた。G. Huston氏の調査によると、UDPメッセージサイズの主な値として512、1024、1232、1480、2048、4000、4096、8192、65535といった数字が観測されているとのことである。8192や65535といった大きなデータも見られたが、結論としては「現状において、数多くのDNSサーバーが4096をサポートしている」ということである。
UDPメッセージサイズが大きくなるということは、データの増幅率が上がるためにDNSリフレクター攻撃のリスクが増大すること、応答が1パケットに収まらなくなることからIPフラグメンテーションが発生するということになる。森下氏はこの2点について詳細な説明をしていたが、ここでは比較的新しい話題である、IPフラグメンテーションを悪用した攻撃手法を取り上げる。
IPフラグメンテーションとは、IPにおいて1回で送れる最大の単位（MTU）よりも大きなデータを送る場合に必ず発生するパケットの分割（フラグメント）である。森下氏によると、これは「IPの仕様上、有害であることは古くから知られており、DNSのUDPメッセージサイズの検討においても、IPフラグメンテーションを防ぐ配慮がされていた」とのことである。DNSの基本仕様における512バイト、EDNS0において当初定められた1280バイト、その後改訂された1280バイトから1410バイトの間といった数値にも、そうした配慮が現れているとのことだ。
そうした背景の中、2012年5月にイスラエル・バル＝イラン大学のA. Herzberg教授とH. Shulman氏がIPフラグメンテーションの脆弱性を突いたキャッシュポイズニング手法を論文として発表した。同氏らはこの攻撃手法を「第一フラグメント便乗攻撃（1st-fragment piggybacking attacks）」と命名している。発表当初はさして話題にならなかったが、2013年8月に行われたIETF 87 saag（Security Area Advisory Group）の招待講演において発表され、関係者の間に広く知られたことでその問題点が大きな話題になった。
では、その攻撃手法とはどのようなものなのであろうか。森下氏の説明によると、フラグメントされたUDPによるDNS応答がある時に、その2つ目以降のフラグメントを偽物と差し替えることができる。偽物のフラグメントに偽の情報を仕込めば、キャッシュポイズニングができるというものだそうだ。これは、フラグメントされた結果、DNS応答の同定に使える要素（UDPポート番号、問い合わせID、問い合わせ名）が最初のフラグメントにしか無く、2つ目以降のフラグメントでは再構築のために、IPv4では16ビットしか無いIdentificationフィールドに頼るしかない点を突いたものである。この攻撃手法の成否はTCP/IPの実装にも依存するものであり成功率は一概に言えないが、実験環境とはいえ、デモを成立させるぐらいの確率はあるようである。
この攻撃への対策は、どのようにすればよいのだろうか。考えられるものとしてはBCP38の適用やDNSSECの適用などがあるが、これという決定版は無いようである。今後も、この話題の動向には注意が必要であろう。
DNSとUDPのかかわり合いは？
森下氏は、DNSのUDPメッセージサイズはいくつが適切なのかという問題に対し、現状を考えると4000（4096）バイトは少し大きすぎたかもしれないが、DNSSEC、IPv6、SPF/DKIM、DANEといった技術の利用を考えると512バイトはあまりに小さいと述べ、その指標として、2013年に発行された改定版EDNS0（RFC 6891）に記述されている「Ethernetにおけるリーズナブルな値」としての「1280バイトから1410バイトまでの間」という数字を挙げた。この数字はEthernetのサイズを基準として、「1パケットで送受信」を重要視した値である。
そして、次の問題として、DNSはそもそもUDPでいいのかという点にも言及し、「この問題は真面目に考えていかなければいけない」と述べた。しかしながら、TCPに移行するためにはさまざまな問題を解決する必要がある。特に大きな問題として、スケーラビリティがあり、UDPより確実に増えるレイテンシー、DoS攻撃耐性、UDPであることを前提としている既存サービスへの影響などが説明された。
森下氏は最後に、広く普及し、長期にわたり基盤技術として利用されているという意味において、DNSはインターネットにおいて大成功した技術の1つであるといえること、しかしその結果、DNSに関するRFCの本数はこの30年で200本を超え（かつ、その多くが「仕様の明確化」と「更新」であった）、数多くの「運用でカバー」が存在する状況になってしまったという現状を説明した。
そして森下氏は、それらを「見方を変えれば、それらはDNSを維持・発展させてきた“戦いの足跡”」であるとし、それは今日取り上げたDNSのUDPメッセージサイズについても言えること、そして、DNSにおけるその“戦い”は今後も続いていくであろうことを説明し、本ランチセミナーを終了した。
なかなか注目されることのないDNSだが、インターネットにとっては欠かすことのできない仕組みである。インターネットの発展に伴ってその利用範囲が拡大の一途をたどってきている現状は、かなりの試練であると見ることもできる。言い方は悪いが、これまでDNSは「それなりの設定をすれば何となく動く」と見られてきた。しかし、これからはDNSが単に動くだけでなく、安定と安全をどれだけ提供することができるかという問題を抜きにすることはできないということだろう。DNSをこれからも安定して使っていくためには、利用者の側もISPやホスティングサービスなどのDNS品質に注目し、ネットワークサービスを提供する企業や組織に対して利用者側からもDNSの健全化を働きかけることが必要なのではないかと思えた内容だった。