Title: DNS WG 2019年度活動報告書 Author(s): 石原知洋(sho@c.u-tokyo.ac.jp) 　　　関谷勇司(sekiya@wide.ad.jp) Date: 2019-12-31 本ドキュメントは、DNS-WG の2019年活動報告である。 1. はじめに DNS WG では、DNS における実装上や運用上の問題点に関して、情報共有とそれ を解決するための活動を行っている。秋の WIDE 研究会においてミーティングを 開催し、DNS に関するホットトピックについて情報交換を行った。本報告書では、 これらのミーティングにおいて発表、議論がなされた事項についてまとめる。 2. 2019年WIDE 春合宿での議論まとめ 2019年9月の WIDE 秋合宿において、DNS WG のミーティングを開催した。この ミーティングでは、下記の事項について発表と議論が行われた。 - UDP 第一フラグメント便乗攻撃の概要と対策案 2.1 UDP 第一フラグメント便乗攻撃の概要と対策案 JPRS の藤原氏より、UDP 第一フラグメント便乗攻撃の概要と対策について発表 があった。UDP 第一フラグメント便乗攻撃は、UDP のフラグメントを悪用し DNS のキャッシュ汚染攻撃をおこなうものである。 DNS のキャッシュ汚染攻撃を成功させるためには、UDP のポート番号(16bit)と DNS ヘッダの ID(16bit)を推測し適合させる必要があり、多くの場合こちらは ランダム化されているため、攻撃者は手あたり次第に 32 bit 空間の予測を する必要があるため成功させることは難しい。しかし、UDP のフラグメント が発生した際には第二パケットにはこの情報が含まれておらず、攻撃者が適合 させる必要のある情報は16bitのUDPのフラグメンテーションIDのみとなり、 またこの情報はいくつかの問題がある実装では予測可能である。すなわち、悪意をもって フラグメントを発生させることにより、DNSキャッシュ汚染攻撃を通常の場合と 比べて容易に成功させることができる。 UDP 第一フラグメント便乗攻撃を行うにあたり、任意の場所でフラグメントを 発生させるため、不正に加工した ICMP のパケットを利用する。これらの パケットを利用して、誤った Path MTU Discovery 結果を被害者に使用させる ことができる。対象の TCP/IP の実装によるが、最低で 296 バイトまで MTU を現象させることができ、容易にフラグメントを発生させることが可能となる。 本発表ではこちらの対策として、UDP payload のサイズを 1220 に限定させる ことにより、IPv6 の最低 MTU である 1280 を上回らないようにして フラグメントを抑制しつつ、フラグメントしたパケットを破棄する、 TCP のみ利用する、DNSSEC を有効にする、DNS Cookie を使用する、 などのいくつかの対抗策が提案された。特に UDP payload のサイズを 限定させる提案については、秋合宿でも議論がおこなわれたため、 3.1 においてその詳細を述べる。 3. 2019年WIDE 秋合宿での議論まとめ 2019年9月の WIDE 秋合宿において、DNS WG のミーティングを開催した。この ミーティングでは、以下の事項に関して発表と議論が行われた。 - フラグメント回避のためのDNSおよびRFC8085 でのUDP 利用ガイドライン - DITL データを用いたルートサーバへ問い合わせを送るホストの解析 - DNSのIPv6対応とIPv6の普及状況 3.1 フラグメント回避のためのDNSおよびRFC8085でのUDP利用ガイドライン 　　(日本レジストリサービス 藤原) JPRS の藤原氏より、春合宿で発表があった UDP 第一フラグメント便乗攻撃の 対策について発表があった。現在、RFC 8085 では「アプリケーションは その宛先に対する MTU より大きいサイズになる UDP データグラムを送る べきではない」と規定されており、またその MTU については「フラグメントを 避けるために、IP レイヤから得られた情報か、Path MTU Discovery を 実装することにより得られた値を使用する」と規定されている。 RFC8085 は UDP 全般について書かれた仕様であり、DNS については一例として 触れられているのみである。したがって、DNS の挙動について RFC8085 に従って 更新すべきである、との提案があった。本提案は下記の通りである。 1)ある宛先について MTU が既知であればその値を、不明である場合は ペイロードサイズを 1220 バイトに（ヘッダを含めて IPv6 の最低 MTU サイズである 1280 以下になるように）指定する 2)DNS のリクエストを送る側は EDNS0 のオプションにより 送ろうとしている対象への先述のサイズを通知する 3)DNS の応答側はすべてのフラグメントされたパケットを再構成する前に UDP 第一フラグメント便乗攻撃の対策として捨ててもよい 4)DNS のリクエストを送る側は、UDP の返答が得られなかった場合には TCP にフォールバックしてもよい これに加えて、多重のトンネルの先など、MTU ペイロードサイズが 1280 を割る 環境に DNS サーバがある場合には、フラグメントが発生しない最小の MTU サイズを使用すべきか、もしくは DNS サーバ自体、そのような MTU が 小さい環境に置くべきではないと規定すべきか、などの議論があった。 また、普及モデルについて、まずはフルサービスリゾルバ側に対して実装を おこない、フルサービスリゾルバへの普及が進んだ後に権威サーバ側に （フラグメントパケットを捨てるように）実装をおこなうべき、という提案が あった。 本提案は draft-fujiwara-dnsop-avoid-fragmentation として IETF の dnsop で 標準化に向けて議論がおこなわれている。 3.2 DITL データを用いたルートサーバへ問い合わせを送るホストの解析 　　(日本レジストリサービス 藤原) JPRS の藤原氏より、ルートネームサーバ上で取得されたトラフィックデータを 用いた、ルートネームサーバに対してDNSクエリを送信するDNSホストの、 実装および設定などの推定について、発表があった。 　解析に使用したルートネームサーバに対するトラフィックデータは "A Day in the Life of the Internet(DITL)"と呼ばれるもので、 2006年より、ルートネームサーバでは毎年数回、48時間分（ルートレコードの キャッシュ有効期間）のトラフィックを同時に取得しており、これらのデータは DNSの研究者に対して一部のデータを匿名化したうえで提供されている。今回の解析 には2018年4月に取得されたDITLのデータを使用している。 解析は、全問い合わせを対象に、個々の問い合わせに含まれていヘッダ情報や、 問い合わせの名前やタイプ別に集計をおこなった。また、ルートの全データを 含んでいるため、いくつかの自分の管理しているフルサービスリゾルバからの 問い合わせも観測できる。データの比較のため、これら複数のホストごとに 問い合わせの集計も併せておこなった。 解析の結果得られた知見のうち興味深いものを下記に挙げる。 1)負荷が高いフルサービスリゾルバにおいては、先に問い合わせて キャッシュされているはずのレコードを頻繁に問い合わせている。 これは、同ホストのネームサーバのキャッシュ実装に問題がある可能性がある。 2)IPv4/IPv6デュアルスタックのフルサービスリゾルバのうちいくつかでは、 IPv6での問い合わせの方が多かった。 3)ほとんどのフルサービスリゾルバは5種類以上のレターのルートネーム サーバに対して問い合わせを出している。 4)最も問い合わせが多いホストを抽出したところ、トップ２つはfルートネーム サーバにのみ送信しており、攻撃か誤設定が疑われる 5)3番目に多く問い合わせを出していたホストは多くのルートネームサーバに 対してクエリを出しており、こちらはキャッシュが動作していないホストの 可能性がある 3.3 DNSのIPv6対応とIPv6の普及状況 (日本レジストリサービス 藤原) JPRS の藤原氏より、DNS における IPv6 の普及状況について、 JPRS のゾーンファイルと、実際に名前解決を実施し得られた返答を 解析した結果について発表があった。 JP に登録されている名前について、ゾーン頂点もしくは www.(ゾーン名)の ドメイン名に IPv6 アドレスが振られているものは約 4% であり、 そのうち、88%は IPv6 アドレスがその名前の権威サーバに降られていたが、 残り 12% は IPv4 アドレスしか権威サーバに割り振られておらず、 名前解決自体に IPv4 が必要な状態であるように見えた。 JP ゾーンの権威サーバに寄せられる問い合わせについては、2019年現在では 14%程度がIPv6トランスポートでの問い合わせであり、また20%がAAAA レコードの問い合わせとなっている。 また、ドメインネーム全体で、alexa から公開されている人気ドメイン名 上位100万について、そこから重複を取り除いた上位10万ドメインについて 実際に問い合わせを出し調査したところ、63% のドメイン名が IPv6 のみで 名前解決が可能な状態であった。しかし、ゾーン頂点もしくは www.(ゾーン名)の ドメイン名にIPv6 アドレスが振られているものは約 15% であった。 この結果より、人気ドメイン名のDNSサーバのIPv6対応は進んでいるが、まだ 大多数の web サーバが IPv6 対応しているとは言い難い状態であった。 しかしながら、世界の上位ドメインにおける IPv6 対応は JP 全体 の同結果よりは多いという結果が得られた。