DNSストレステストを運用サーバに向けてDoS攻撃を起こしてしまう

インターネットの根幹となる機能であり、世界で最もスケーラビリティの高いシステムであるDNS。DNSは、ユーザーの要望に対してなんとしてでもサービスの提供を続けなければならないシステムの1つだ。

そんなわけで、DNSにはパフォーマンスをテストを実施するためのツールやモニタリングを行うためのツールが豊富に用意されている。こうしたツールはサービスを開始する前、システムの構築段階で利用する。想定するクエリに対して落ちることなく、許容範囲内の時間で処理をさばくことができるかどうかを調べ、足りなければロードバランサーを導入したり、サーバの台数を増やしたり、OSやDNSのパフォーマンス・チューニングを実施したりする。

しかし当然ながら、こういうツールはサービスを提供しているサーバに対しても適用できる。CDNを利用するような大規模DNSサーバはその程度のストレステストにはびくともしないが、小規模DNSサーバはサービスの影響を与えるくらいのダメージを受けてしまう。Linuxからそうしたコマンドを簡単に実行できてしまうのだが、絶対に実行しないようにしよう。

ということで、本連載の趣旨に従い試してみる。あくまでも実験だ。実際の環境では絶対に行わないようにしよう。まず、次のように通常のDNSクエリの処理時間を計測する。この場合、5秒ほどかかっている。あえて名前解決に時間がかかるルートから処理を行っているので、長い時間かかっているのだ。

• このDNSサーバで5秒ほどの処理時間

この名前解決を実施したDNSサーバにresperfコマンドでストレスをかけてみる。次の実行例で100万クエリを送信している。

• resperfを使ってDNSサーバに負荷テストを実施

ストレステストを実施している間に同じDNSサーバを利用すると、今度は次の結果が得られる。取得できる情報が減ったほか、10秒くらいかかっている。明らかにストレステストがサービスに影響を与えたことがわかる。

• DNSサーバのレスポンスが10秒くらいまで低下

まだネットワークは飽和していないと思うので、このストレステストを並列で実行しようとすると、さらに負荷が上がる。さらに１台のマシンからではなく、複数のマシンから同じストレステストを実施すると、サーバ側のネットワークも飽和することになり、通常の名前解決サービスはさらに時間がかかるようになる。

Linuxはこうしたストレスツールを簡単に利用することができる。しかし、こうしたストレスツールは同時にサービス妨害攻撃(Denial of Service Attack)にも悪用することができる点に注意が必要だ。利用するのはあくまでも本番運用前の試験段階にとどめるようにしてほしい。本番稼働しているサービスに対して実施すると、DoS攻撃になってしまうので注意してほしい。