(57)【要約】【課題】  膨大かつ複雑なドメイン空間を適切な粒度で分解・整理し、効率的にDNSトラヒックの詳細情報を記憶、取得する。【解決手段】  本発明は、DNSトラヒックデータのFQDNを抽出し、該FQDNを複数の粒度の文字列データに分解するFQDN解析手段と、DNSトラヒックデータのトラヒック統計情報を計算する統計情報計算手段と、文字列データから２種類の木を生成し、該木及びグラフの各ノードにトラヒック統計情報を対応付けてトラヒック統計情報としてトラヒック統計情報記憶手段に記憶する木構造データ構築手段と、を有する。また、トラヒック統計情報記憶手段に時系列に格納されている全てのトラヒック統計情報を読み出して、異なる時刻の全トラヒック統計情報を比較して、トラヒックの変化を検知するトラヒック変化検知手段を更に有する。【選択図】  図１
2015173342.tif 000002
【特許請求の範囲】
【請求項１】
DNS(Domain Name System)トラヒックデータから統計情報を取得して分析する統計情報分析装置であって、
前記DNSトラヒックデータのFQDN(Fully Qualified Domain Name)を抽出し、該FQDNを複数の粒度の文字列データに分解するFQDN解析手段と、
前記DNSトラヒックデータのトラヒック統計情報を計算する統計情報計算手段と、
前記文字列データから２種類の木を生成し、該木及びグラフの各ノードに前記トラヒック統計情報を対応付けてトラヒック統計情報としてトラヒック統計情報記憶手段に記憶する木構造データ構築手段と、
を有することを特徴とする統計情報分析装置。
【請求項２】
前記FQDN解析手段は、
前記FQDNのドメイン名をPublic suffix、Private label、Host labelに分解するドメイン名分解手段を含み、
前記木構造データ構築手段は、
前記Public suffixと前記Private labelからPrivate suffix木を生成する手段を含む
請求項１記載の統計情報分析装置。
【請求項３】
前記トラヒック統計情報記憶手段に時系列に格納されている全てのトラヒック統計情報を読み出して、異なる時刻の全トラヒック統計情報を比較して、トラヒックの変化を検知するトラヒック変化検知手段を更に有する
請求項１記載の統計情報分析装置。
【請求項４】
前記トラヒック変化検知手段は、
全トラヒック統計情報の変化を検知し、その要因となるPublic suffixを特定する第１の検知手段と、
前記Public suffixのトラヒック統計情報の変化を検知し、その要因となるPrivate suffixを特定する第２の検知手段と、
前記Private suffixのトラヒック統計情報の変化を検知し、その要因となるFQDMを特定する第３の検知手段と、
トラヒック量上位N個のFQDNトラヒック統計量を比較し、トラヒック変化の検知を行う第４の検知手段と、
を含む請求項３記載の統計情報分析装置。
【請求項５】
前記トラヒック変化検知手段は、
ある時刻t1とt2のトラヒック統計情報の差や商が所定の閾値を越えた場合に変化があったと判断する方法；
スケッチを用いた異常トラヒック検知技術を用いる方法；
トラヒックの時系列データを予測し、予測から大きく外れた場合に変化があったと判断する方法；
のいずれかを用いる請求項３記載の統計情報分析装置。
【請求項６】
DNS(Domain Name System)トラヒックデータから統計情報を取得して分析する装置における統計情報分析方法であって、
前記DNSトラヒックデータのFQDN(Fully Qualified Domain Name)を抽出し、該FQDNを複数の粒度の文字列データに分解するFQDN解析ステップと、
前記DNSトラヒックデータのトラヒック統計情報を計算する統計情報計算ステップと、
前記文字列データから２種類の木を生成し、該木及びグラフの各ノードに前記トラヒック統計情報を対応付けてトラヒック統計情報としてトラヒック統計情報記憶手段に記憶する木構造データ構築ステップと、
前記トラヒック統計情報記憶手段の前記及び前記グラフからトラヒック統計情報を取得して出力する統計情報検索ステップと、
を行うことを特徴とする統計情報分析方法。
【請求項７】
前記トラヒック統計情報記憶手段に時系列に格納されている全てのトラヒック統計情報を読み出して、異なる時刻の全トラヒック統計情報を比較して、トラヒックの変化を検知するトラヒック変化検知ステップを更に行う
請求項６記載の統計情報分析方法。
【請求項８】
コンピュータを、
請求項１乃至５のいずれか１項に記載の統計情報分析装置の各手段として機能させるための統計情報分析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、DNSトラヒック統計情報分析装置及び方法及びプログラムに係り、特に、DNSトラヒック統計情報を複数の粒度で記憶し、検索する、及び、DNSトラヒック統計所情報の変化を検知するDNSトラヒック統計情報分析装置及び方法及びプログラムに関する。
【背景技術】
【０００２】
DNSサーバおよびネットワーク安定運用のために、ユーザのDNS利用動向を把握することは非常に重要である。ユーザの利用動向として、例えば問い合わせドメイン名ごとのサーバへのパケット数やネットワークの使用帯域などが挙げられる。これらの統計情報を得る既存ツールとしてdnstop（例えば、非特許文献１参照）などが挙げられる。このツールではFQDN(Fully Qualified Domain Name)ごとのパケット数ランキングなどを作成することができ、ユーザの利用動向を得ることができる。
【０００３】
しかしながら、DNS運用においては、FQDNごとではなく特定組織へのトラヒック統計情報など異なる粒度で利用動向を把握したいケースがある。例えば、exampleという組織が、www1.example.jp、www2.example.co.jp、www.example.com、exampl.netなど異なるFQDNでサービスを提供しているケースを考える。既存ツールを用いる場合では、exampleという組織のトラヒック統計情報を得るためには上記のFQDN全てを抽出し、トラヒック統計情報を再計算しなければならず、情報を取得するために時間を要する可能性がある。
【０００４】
また、他のDNSトラヒックの詳細を把握する技術として、DNSの階層構造に注目し、ドメイン名の各ラベルをノードとした木構造として表現し、木のノードに対してトラヒック情報を付与する手法が提案されている（例えば、非特許文献２参照）。
【０００５】
また、DNSサーバ運用において、サーバ負荷やネットワーク負荷を把握するための問い合わせパケットや応答パケット、ネットワークの使用帯域の監視などが行われている。これらの数値を見ることによって、異常を検知することができる。
【０００６】
しかしながら、上記の技術では異常発生の検知は可能であるが、その要因までは特定することは困難である。例えば、DoS（Denial of Service）攻撃によってある特定のドメイン名への問い合わせが急増した場合、パケット数の急増は検知できるが、どのドメイン名への問い合わせが増加したかを把握することができない。要因特定に時間を要すると、その間サービスが停止してしまうなどの問題が発生する。
【０００７】
上記の理由から、DNSサーバ運用において、異常の要因を特定するためにはトラヒックの全体統計値のみではなく、ドメイン名ごとのパケット数などの比較など、より細かい粒度での統計情報の比較が必要である。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】The Measurement Factory, "dnstop", http://dns.measurement-factory.com/tools/dnstop/
【非特許文献２】D. Plonka and P. Barford, "Context-aware clustering of DNS query traffic.", In proceedings of the 8th IMC, 2008, ACM.
【非特許文献３】P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", https://www.ietf.org/rfc/rfc1035.txt
【非特許文献４】Mozilla Foundation, "PUBLIC SUFFIX LIST", http://publicsuffix.org/list/
【非特許文献５】Dewaele, Guillaume, et al. "Extracting hidden anomalies using sketch and non gaussian multiresolution statistical detection procedures."Proceedings of the 2007 workshop on Large scale attack defense. ACM, 2007.
【非特許文献６】Chatfield, Chris, and Mohammad Yar. "Holt-Winters forecasting: some practical issues." The Statistician (1988): 129-140.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、現在のドメイン空間は膨大であり、上記の非特許文献１のように、DNSラベルを用いた木構造では、記憶、取得のための計算リソースが大きくなってしまう。
【００１０】
また、非特許文献２の技術のように、DNSのラベルを用いた木構造では、ドメイン名のラベル毎に階層を深くしていくことから、記憶、取得のための計算リソースが大きくなってしまうという問題がある。
【００１１】
本発明は、上記の点に鑑みなされたもので、膨大かつ複雑なドメイン空間を適切な粒度で分解・整理し、効率的にDNSトラヒックの詳細情報を記憶、取得し、さらに、その粒度毎のトラヒック統計情報の比較を行うことで、効率的なDNSトラヒック変化検知を行うことが可能なDNSトラヒック統計情報分析装置及び方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
一態様によれば、DNSトラヒックデータから統計情報を取得して分析する統計情報分析装置であって、
前記DNSトラヒックデータのFQDN(Fully Qualified Domain Name)を抽出し、該FQDNを複数の粒度の文字列データに分解するFQDN解析手段と、
前記DNSトラヒックデータのトラヒック統計情報を計算する統計情報計算手段と、
前記文字列データから２種類の木を生成し、該木及びグラフの各ノードに前記トラヒック統計情報を対応付けてトラヒック統計情報としてトラヒック統計情報記憶手段に記憶する木構造データ構築手段と、を有する統計情報分析装置が提供される。
【発明の効果】
【００１３】
一態様によれば、DNSトラヒック統計情報を複数の粒度で記憶することで、任意のドメイン名の粒度でトラヒック統計情報を検索可能となるため、効率的にトラヒック情報を取得することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の第１の実施の形態におけるDNSトラヒック統計情報分析装置の構成例。
【図２】本発明の第１の実施の形態における粒度分解の例。
【図３】本発明の第１の実施の形態におけるFQDN木の例。
【図４】本発明の第１の実施の形態におけるPrivate Suffix木の例。
【図５】本発明の第１の実施の形態における構築したFQDN木のノードにトラヒック統計情報を付与する例。
【図６】本発明の第１の実施の形態におけるPrivate Suffix木の各ノードにDNSトラヒック統計情報を付与する例。
【図７】本発明の第２の実施の形態におけるDNSトラヒック統計情報分析装置の構成例。
【図８】本発明の第２の実施の形態における粒度分解の例。
【発明を実施するための形態】
【００１５】
以下、図面と共に本発明の実施の形態を説明する。
【００１６】
［第１の実施の形態］
図１は、本発明の第１の形態におけるDNSトラヒック統計情報分析装置の構成例を示す。
【００１７】
DNSトラヒック統計情報分析装置１００は、DNSサーバ1による発着トラヒックをキャプチャするDNSトラヒック情報収集装置１０及び、DNSオペレータ端末３側のDNSトラヒック統計情報検索部３０に接続されている。
【００１８】
DNSトラヒック統計情報分析装置１００は、FQDN解析部１１０、DSNトラヒック統計情報計算部１２０、木構造データ構築部１３０を有する。
【００１９】
FQDN解析部１１０は、DNSトラヒック情報収集装置１０で収集されたDNSトラヒックデータからFQDNを抽出し、図２に示す粒度に分解する。
【００２０】
DNSトラヒック統計情報計算部１２０は、DNSトラヒック情報収集装置１０で収集されたトラヒック情報からトラック統計情報を求める。
【００２１】
木構造データ構築部１３０は、FQDN解析部１１０から得られた分解されたFQDNの文字列データを木構造とし、統計情報を付与してDNSトラヒック統計情報記憶部２０に格納する。
【００２２】
DNSオペレータ端末３は、DNSトラヒック統計情報検索部３０を介してトラヒック情報を取得することができる。
【００２３】
本実施の形態では、以下の流れで処理を行う。
【００２４】
［１］DNSトラヒック情報収集装置１０がDNSトラヒックを収集する。
【００２５】
［２］FQDN解析部１１０が、DNSトラヒック情報収集装置１０で収集されたトラヒック情報からFQDNを抽出する。また、DNSトラヒック統計情報計算部１２０が、既存方法によりDNSトラヒック情報からトラヒック統計情報を抽出する。
【００２６】
［３］FQDN解析部１１０が、抽出したFQDNを複数の粒度の文字列データに分解する。
【００２７】
［４］木構造データ構築部１３０が、分解した文字列データをもとに2種類の木(FQDN木、Private suffix木)を構築する。
【００２８】
［５］木構造データ構築部１３０が、構築した木のノードにトラヒック統計情報をDNSトラヒック統計情報記憶部２０に記憶する.
［６］DNSオペレータがDNSトラヒック統計情報検索部３０を介して、構築した木からトラヒック統計情報を取得する。
【００２９】
なお、以下では、FQDNを例として説明するが、本発明は、FQDNのみならず、組織ごとなど複数の粒度のトラヒック統計情報を、木構造を用いて表現することで、効率的に保持、参照することができる。
【００３０】
以下に、上記の［３］〜［６］の処理の詳細を記す。
【００３１】
［３］の処理（抽出したFQDNを複数の粒度の文字列データに分解する）の詳細：
FQDN解析部１１０は、DNSトラヒック収集装置１０から取得したDNSトラヒックデータ(パケットデータ)からFQDNを抽出する。FQDNはDNSパケットのアプリケーションレイヤ内の"質問/応答/権威/追加レコードセクション"（非特許文献３参照）の"QNAMEフィールド"に含まれる。なお、DNSトラヒックデータは、DNSトラヒック収集装置１０から取得するものとして説明するが、この例に限定されることなく、DNSトラヒック収集装置１０が収集したデータをディスク等の記憶手段に格納し、当該記憶手段から読み出して取得してもよい。
【００３２】
次に、FQDN解析部１１０は、取得したFQDNからPublic suffix、Private label、Host labelを抽出する。これらの情報を取得するために、まずFQDNを"."を区切り文字としてラベル列Lに分解する。ラベル列Lの添字は図２に示すように、最も右側を0とし、左側にゆくにつれ1つずつ増加するものとする。例として以下を挙げる。
【００３３】
FQDN：test.www.example.co.jp
ラベル列L：L[0] = jp、L[1] = co、L[2] = example、L[3] = www、L[4] = test
以下ラベル列LからPublic suffix、Private label、Host labelを取得する方法を記す。
【００３４】
・Public suffixの取得
Public suffixの定義はMozilla Foundationが管理しており、非特許文献４に公開されている。Public suffixを取得するために、この公開リストをメモリ等の記憶手段に格納し、当該公開リストとラベル列Lの突合(文字列右端からの最長マッチング)を行う。具体的な処理は以下の通りである。ここで、ラベル列Lの長さ(ラベルの個数)をnとする。
【００３５】
(1)変数iを0に設定する(i := 0)。
【００３６】
(2)変数DOMAINをL[i]に設定する(DOMAIN := L[i])。
【００３７】
(3)DOMAINがPublic suffix listに含まれているか検索する。
【００３８】
(4)検索の結果、含まれていない場合、DOMAINをPublic suffixとし、処理を終了する(DOMAINを返す)。
【００３９】
(5)検索の結果、含まれている場合、DOMAINの先頭にL[i + 1]を追加(LABELS := L[i + 1] +"."+ DOMAIN)し、iを1つ増加させ(i := i + 1)、(3)に戻る。
【００４０】
・Private labelの取得
Private labelはPublic suffixの1つ左のラベルである。すなわち、Public suffixのラベル列の長さ(ラベルの個数)をmとすると、Private labelはL[m + 1]を参照することで取得することができる。
【００４１】
・Host labelの取得
Host labelはPrivate labelより左側のラベル全てである。すなわち、Host labelはPrivate labelより左側のラベル全てを"."で結合することで取得することができる。
【００４２】
［４］の処理（分解した文字列データをもとに２種類の木を構築）の詳細：
＜FQDN木の構築＞
木構造データ構築部１３０は、上記の［３］の処理で得られたPublic suffix、Private label、Host labelを用いて、図３のようなFQDN木を構築する。木の深さは3であり、最上位のルートノード、深さ1のPublic suffixノード、深さ2のPrivate labelノード、深さ3のHost labelノードから成る。以下、具体的な木の構築方法を記す(例として『test.www.example.co.jp』を入力とする)。
【００４３】
(1)ルートノードの追加:
木が空の場合、まずルートノードを追加する。ルートノードはDNSトラヒック全体の情報を持つノードであり、ラベルとして空文字を持つ。既にルートノードが存在する場合は何もしない。
【００４４】
(2)Public suffixノードの追加：
ルートノードの子ノードとして、Public suffixの文字列(co.jp)をラベルに持つPublic suffixノードを追加する。既に同一ラベルを持つPublic suffixノードが存在する場合は何もしない。
【００４５】
(3)Private labelノードの追加：
Public suffixノードの子ノードとして、Private labelの文字列(example)をラベルに持つPrivate labelノードを追加する。既に同一ラベルを持つPrivate labelノードが存在する場合は何もしない。
【００４６】
(4)Host labelノードの追加：
Private labelノードの子ノードとして、Host labelの文字列(test.www)をラベルに持つHost labelノードを追加する。既に同一ラベルを持つHost labelノードが存在する場合は何もしない。
【００４７】
＜Private suffix木の構築＞
木構造データ構築部１３０は、上記の［３］の処理で得られたPublic suffix、Private labelを用いて、図４のようなPrivate suffix木を構築する。木の深さは2であり、最上位のルートノード、深さ1のPrivate labelノード、深さ2のPublic suffixノードから成る。以下、具体的な木の構築方法を記す(例として『test.www.example.co.jp』を入力とする)。
【００４８】
(1)ルートノードの追加：
グラフが空の場合、まずルートノードを追加する。ルートノードはDNSトラヒック全体の情報を持つノードであり、ラベルとして空文字を持つ。既にルートノードが存在する場合は何もしない。
【００４９】
(2)Private labelノードの追加：
ルートノードの子ノードとして、Private label の文字列(example)をラベルに持つPrivate labelノードを追加する。既に同一ラベルを持つPrivate labelノードが存在する場合は何もしない。
【００５０】
(3)Public suffixノードの追加：
Private labelノードの子ノードとして、Public suffixの文字列(co.jp)をラベルに持つPublic suffixノードを追加する。既に同一ラベルを持つPublic suffixノードが存在する場合は何もしない。
【００５１】
［５］の処理（構築した木のノードにトラヒック統計情報を記憶）の詳細：
＜FQDN木のノードへの情報付与＞
木構造構築部１３０は、上記の［４］の処理で構築したFQDN木の各ノードに対し、図５に示すように、DNSトラヒック統計情報計算部１２０で計算されたDNSトラヒック統計情報を付与または更新する。付与するDNSトラヒック統計情報としては、パケット数、パケットサイズ、送信元ユーザ数、DNSクエリタイプなど、DNSパケットに含まれるあらゆる統計情報とする。以下、具体的な処理方法を記す(例として、『test.www.example.co.jp』を入力とする)。
【００５２】
(1)ルートノードへの情報付与または更新：
ルートノードのトラヒック統計情報を付与または更新する。例えば、パケット数を1増加させる、送信元ユーザ数を1増加させるなどが挙げられる。ルートノードはいかなるFQDNの入力においても情報が更新されるノードであり、これはDNSトラヒック全体の統計情報を持つものである。
【００５３】
(2)Public suffixノードへの情報付与または更新：
ルートノードの子から入力Public suffixと一致するPublic suffixノードを検索し、そのノードのトラヒック統計情報を付与または更新する。Public suffixノードは当該Public suffixを持つ全てのFQDN(*.co.jpなど)のトラヒック統計情報を持つものである。
【００５４】
(3)Private labelノードへの情報付与または更新：
(2)で更新したPublic suffixノードの子から入力Private labelと一致するPrivate labelノードを検索し、そのノードのトラヒック統計情報を付与または更新する。Private labelノードは図２におけるPrivate suffixを持つ全てのFQDN(example.co.jpなど)のトラヒック統計情報を持つものである。
【００５５】
(4)Host labelノードへの情報付与または更新：
(3)で更新したPrivate labelノードの子から入力Host labelと一致するHost labelノードを検索し、そのノードとトラヒック統計情報を付与または更新する。Host labelノードはFQDN(test.www.example.co.jpなど)のトラヒック統計情報を持つものである。
【００５６】
＜Private suffix木のノードへの情報付与＞
木構造構築部１３０は、上記の［４］の処理で構築したPrivate suffix木の各ノードに対し、図６に示すように、DNSトラヒック統計情報を付与または更新する。付与する情報としては、パケット数、パケットサイズ、送信元ユーザ数、DNSクエリタイプなど、DNSパケットに含まれるあらゆる統計情報とする。以下、具体的な処理方法を記す(例として、『test.www.example.co.jp』を入力とする)。
【００５７】
(1)ルートノードへの情報付与または更新：
FQDN木のルートノードと同様に、ルートノードのトラヒック統計情報を付与、または、更新する。
【００５８】
(2)Private labelノードへの情報付与または更新：
ルートノードの子から入力Private labelと一致するPrivate labelノードを検索し、そのノードのトラヒック統計情報を付与または更新する。Private labelノードは図２におけるPrivate suffixを持つ全てのFQDN(example.co.jpなど)のトラヒック統計情報を持つものである。
【００５９】
(3)Public suffixノードへの情報付与または更新：
ルートノードの子から入力Public suffixと一致するPublic suffixノードを検索し、そのノードのトラヒック統計情報を付与または更新する。Public suffixノードは当該入力FQDNのPrivate suffix(example.co.jpなど)のトラヒック統計情報を持つものである。
【００６０】
上記の［３］〜［５］により得られたDNSトラヒック統計情報はDNSトラヒック統計情報記憶部２０に格納される。
【００６１】
［６］の処理（構築した木からトラヒック情報を取得）の詳細：
本発明では、DNSオペレータは、DNSトラヒック統計情報検索部３０を介して、上記の［３］〜［５］の処理により構築され、DNSトラヒック統計情報記憶部２０に格納されている木およびグラフを用いることによって、以下の粒度でのトラヒック統計情報を取得することができる。
【００６２】
A:全DNSトラヒック
B：Public suffix
C：Private suffix
D：FQDN
E：Private label
以下、DNSトラヒック統計情報検索部３０による具体的なトラヒック統計情報取得方法を述べる。
【００６３】
＜A：全DNSトラヒック統計情報の取得＞
全てのDNSトラヒック統計情報は、DNSトラヒック統計情報記憶部２０のFQDN木のルートノードのトラヒック統計情報を参照することで取得することができる。
【００６４】
＜B：Public suffixトラヒック統計情報の取得＞
DNSトラヒック統計情報検索部３０を介して、DNSトラヒック統計情報記憶部２０のFQDN木のルートノードの子ノードから、入力Public suffixと一致するラベルを持つノードを検索し、そのノードのトラヒック統計情報を参照することで取得することができる。
【００６５】
＜C：Private suffixトラヒック統計情報の取得＞
まず、DNSトラヒック統計情報検索部３０において、入力Private suffixをPublic suffixとPrivate labelに分解する。次に、DNSトラヒック統計情報記憶部２０からFQDN木のルートノードの子ノードからPublic suffixと一致するラベルを持つノードを検索し、そのノードの子ノードからPrivate labelと一致するラベルを持つノードを検索する。最終的に得られたノードのトラヒック統計情報を参照することでPrivate suffixトラヒック統計情報を取得することができる。
【００６６】
＜D：FQDNトラヒック統計情報の取得＞
まず、DNSトラヒック統計情報検索部３０は、入力FQDNをPublic suffix、Private labelおよびHost labelに分解する。次に、DNSトラヒック統計情報記憶部２０のFQDN木のルートノードの子ノードからPublic suffixと一致するラベルを持つノードを検索し、そのノードの子ノードからPrivate labelと一致するラベルを持つノードを検索する。さらに、そのノードの子ノードからHost labelと一致するラベルを持つノードを検索し、最終的に得られたノードのトラヒック統計情報を参照することでFQDNトラヒック統計情報を取得することができる。
【００６７】
＜E：Private labelのトラヒック統計情報の取得＞
DNSトラヒック統計情報検索部３０は、DNSトラヒック統計情報記憶部２０のPrivate suffix木のルートノードの子ノードから、Private labelと一致するラベルを持つノードを検索し、そのノードのトラヒック統計情報を参照することで取得することができる。また、そのノードの子ノードのトラヒック統計情報を参照することで、Public suffixごとのトラヒック統計情報を取得することができる。 
本実施の形態によれば、任意のドメイン名の粒度でトラヒック統計情報を効率的に取得することができる。非特許文献1と本発明の差分は階層構造を作成する粒度の違いである。非特許文献1ではドメイン名のラベルごとに階層を深くしていく手法であるが、本発明はドメイン名をPublic suffix、Private label、Host Labelの3つの情報を用いて深さが3木またはグラフを構築する。
【００６８】
例として、exampleという事業者が以下のドメイン名を用いてあるサービスを提供しており、DNS運用者がその組織全体のトラヒック情報をDNSトラヒック統計情報検索部３０を介して取得しようとしているものとする。
example.jp
example.co.jp
example.com
example.net
非特許文献1にあるように、DNSの木構造を用いた方法の場合、上記4つのドメイン名のトラヒック統計情報を取得するためには木構造をルートノードから以下の4つのパターンを辿る必要がある。
【００６９】
(1)ルート → jp → example.jp
(2)ルート → jp → co.jp → example.co.jp
(3)ルート → com → example.com
(4)ルート → net → example.net
しかしながら、ドメインの階層構造は深くなるにつれ爆発的に多くなることから、検索に時間を要する。
【００７０】
本発明におけるグラフ構造では、Private labelノード(上記例ではexample)に同一Private labelを持つドメイン名全てをまとめたトラヒック統計情報が含まれる。すなわち、上記の4つのパターンのいずれか1つを検索することにより、4つのドメイン名をまとめた全てのトラヒック統計情報を取得することが可能となる。
【００７１】
［第２の実施の形態］
本実施の形態では、第１の実施の形態においてDNSトラヒック統計情報記憶部２０に格納されたトラヒック統計情報からDNSトラヒックの変化点を検知する。
【００７２】
図７は、本発明の第２の実施の形態におけるDNSトラヒック統計情報分析装置の構成例を示す。
【００７３】
同図のDNSトラヒック統計情報分析装置２００は、FQDN解析部２１０、DNSトラヒック統計情報計算部２２０、木構造データ構築部２３０、統計情報記憶部２４０、変化検知部２５０を有し、FQDN解析部２１０、DNSトラヒック統計情報計算部２２０はDNSトラヒック収集装置１０に接続されている。
【００７４】
本実施の形態では、DNSトラヒック収集装置１０は、DNSトラヒックを一定期間毎に時系列に収集し、FQDN解析部２１０、DNSトラヒック統計情報計算部２２０も時系列にDNSトラヒック情報を取得する。
【００７５】
FQDN解析部２１０は、第１の実施の形態と同様に、収集したトラヒックデータからFQDNを抽出し、図８の粒度に分解する。
【００７６】
ドメイン名は、英数字およびハイフンからなるラベルと呼ばれる文字列と、ラベルを区切るドット(".")によって構成されるものである。ドメイン名は階層構造になっており、最も右側にあるラベルはトップレベルドメイン、右から2番目のラベルはセカンドレベルドメイン(SLD)と呼ばれる。例えば、www.example.co.jpというドメイン名において、TLD(Top Lavel Domain)は"jp"、SLDは"co"となる。
【００７７】
本実施の形態では、ドメイン名の分解粒度として以下の３つを定義する。
【００７８】
(1)Public suffix：一般ユーザが登録することが出来ないドメイン;
(2)Private suffix：Public suffixの1つ左側のラベルまで含めたドメイン;
(3)FQDN：全てのラベルがドットで連結された文字列;
DNSトラヒック統計情報計算部２２０は、DNSトラヒック収集装置１０から取得したトラヒック情報のトラヒック統計情報を計算する。
【００７９】
木構造データ構築部２３０は、FQDN解析部２１０で得られた上記の(1)〜(3)Public suffix、Private suffix, FQDNを取得し、木を生成し、そのノードやグラフにトラヒック統計情報を付与し、統計情報記憶部２４０に格納する。当該処理の方法は、第1の実施の形態と同様である。
【００８０】
変化検知部２５０は、統計情報記憶部２４０からDNSトラヒック統計情報を取得し、異なる時刻のDNSトラヒック統計情報を比較し、トラヒック変化検知を行い、その結果を出力する。
【００８１】
上記で得られた変化検知結果を、DNSオペレータが利用し、制御などの対処を行うことができる。
【００８２】
以下に、上記の構成における処理を説明する。
【００８３】
本発明の処理は以下の通りである。
【００８４】
［１］DNSトラヒック収集装置１０は、DNSトラヒックを監視し、DNSトラヒックデータを一定期間ごとに収集する。
【００８５】
［２］FQDN解析部２１０が、DNSトラヒック収集装置１０によって収集されたDNSトラヒックデータに含まれる問い合わせFQDNをPublic suffix、Private suffix、に分解し、木構造データ算出部２３０に出力する。
【００８６】
［３］DNSトラヒック統計情報計算部２２０が、DNSトラヒック収集装置１０によって収集された全DNSトラヒックデータの統計情報を算出し、木構造データ算出部２３０に出力する。
【００８７】
［４］木構造データ構築部２３０が、上記のFQDNおよび分解した情報ごと木のノードやグラフにトラヒック統計情報を付与し、統計情報記憶部２４０に保存する。
【００８８】
［５］変化検知部２５０が、統計情報記憶部２４０の異なる時刻のトラヒック統計情報を比較し、トラヒック変化の検知を行う。
【００８９】
以下、上記の［２］〜［５］の処理の詳細を記す。
【００９０】
［２］の処理（収集したDNSトラヒックに含まれる問い合わせFQDNを分解）の詳細：
FQDN解析部２１０は、DNSトラヒック収集装置１０で収集されたDNSトラヒックデータ(パケットデータ)からFQDNを取得する。FQDNはDNSパケットのアプリケーションレイヤ内の"質問/応答/権威/追加レコードセクション"（非特許文献３）の"QNAMEフィールド"に含まれる。
【００９１】
次に、FQDN解析部２１０は、取得したFQDNからPublic suffix、Private suffixを取得する。これらの情報を取得するために、図８に示すように、まずFQDNを"."を区切り文字としてラベル列Lに分解する。ラベル列Lの添字は、最も右側を0とし、左側にゆくにつれ1つずつ増加するものとする。例として以下を挙げる。
【００９２】
FQDN：test.www.example.co.jp
ラベル列L：L[0] = jp、L[1] = co、L[2] = example、L[3] = www、L[4] = test
以下ラベル列LからPublic suffix、Private suffixを取得する方法を記す。
【００９３】
・Public suffixの取得
Public suffixの定義はMozilla Foundationが管理しており、[非特許文献3]に公開されている。Public suffixを取得するために、この公開リストとラベル列Lの突合を行う。具体的な処理は以下の通りである。ここで、ラベル列Lの長さ(ラベルの個数)をnとする。
【００９４】
(1)変数iを0に設定する(i := 0)。
【００９５】
(2)変数DOMAINをL[i]に設定する(DOMAIN := L[i])。
【００９６】
(3)DOMAINがPublic suffix listに含まれているか検索する。
【００９７】
(4)含まれていない場合、DOMAINをPublic suffixとし、処理を終了する(DOMAINを返す。)
(5)含まれている場合、DOMAINの先頭にL[i + 1]を追加(LABELS := L[i + 1] + "." + DOMAIN)し、iを１つ増加させ(i := i + 1)、(3)に戻る。
【００９８】
・Private suffixの取得
Private suffixはPublic suffixの1つ左のラベルまで含めたドメインである。すなわち、Public suffixのラベル列の長さをmとすると、Private suffixはPublic suffixにL[m + 1]に追加したものとなる。
【００９９】
［３］の処理（収集した全DNSトラヒックの統計情報を算出）の詳細：
DNSトラヒック統計情報計算部２２０は、DNSトラヒック収集装置１０で収集された時系列のDNSトラヒックデータの全トラヒック統計情報を算出し、木構造データ構築部２３０に出力する。トラヒック統計情報は、全パケット数、DNSクエリ数、DNS応答数、問い合わせ端末数、DNSパケットのヘッダに含まれるフラブ別パケット数など、DNSプロトコルに含まれるあらゆる情報とする。ここで、フラグ別パケット数のフラグとしては、AA、RD（DNSにおける再帰問い合わせ要求）、CD、AD、DO、RA等がある。
【０１００】
［４］の処理（FQDN及び分解した情報毎にトラヒック統計情報を付与）の詳細：
木構造データ構築部２３０は、［３］の処理で算出された統計情報を、処理［２］で記述したFQDN、Public suffix、Private suffixごとに、第１の実施の形態における図５，６に示す方法により付与する。
【０１０１】
［５］の処理（異なる時刻のトラヒック統計情報を比較し、トラヒック変化の検知）の詳細：
変化検知部２５０は、以下の処理を行う。
【０１０２】
＜A：全DNSトラヒック統計情報の比較＞
まず、異なる時刻の全DNSトラヒック統計情報を比較する。具体的には、同じ日付の0時と1時、0時5分と0時10分、異なる日付(1日前と現在)の0時同士を比較する。このとき、統計情報に大きな変化が見られた場合、次の処理へ進む。
【０１０３】
ここで、トラヒック統計情報の変化を検知する例として以下を挙げる。
【０１０４】
a. 時刻t1とt2のトラヒック統計情報(パケット数など)の差や商が閾値を越えた場合に変化が発生したとする。
【０１０５】
b. スケッチを用いた異常トラヒック検知技術を用いて変化検知を行う（例えば、非特許文献５参照）。
【０１０６】
c. olt-Winters法（例えば、非特許文献６参照）などを用いてトラヒックの時系列データを予測し、予測から大きく外れた場合に変化が発生したとする。
【０１０７】
＜B：Public suffixトラヒック統計情報の比較＞
次に、異なる時刻の全Public suffixのトラヒック統計情報を比較し、変化が大きいPublic suffixを抽出する。このとき、全てのPublic suffixにおいて同等のトラヒック変化が発生している場合は変化要因が全Public suffixとして処理を終了する。特定のPublic suffixのみ大きな変化が見られた場合は、次の処理に進む。なお、変化検知手法は前述の例などを利用する。ここで、大きな変化とは、上記のAの処理と同様に、所定の閾値を設け、当該閾値を超えた場合を指す。
【０１０８】
＜C：Private suffixトラヒック統計情報の比較＞
次に、上記で特定したPublic suffixを持つ全てのPrivate suffixの異なる時刻のトラヒック統計情報を比較し、変化が大きいPrivate suffixを抽出する。このとき、全てのPrivate suffixにおいて同等のトラヒック変化が発生している場合は抽出したPrivate suffixが変化の要因として処理を終了する。特定のPrivate suffixのみ大きな変化が見られた場合は、次の処理に進む。ここでの大きな変化とは、上記のA：全DNSトラヒック統計情報の比較に示す、a.b.c.等に示す変化をさす。なお、変化検知手法は前述の例などを利用する。
【０１０９】
＜D：FQDNトラヒック統計情報の比較＞
最後に、上記で特定したPrivate suffixを持つ全てのFQDNの異なる時刻のトラヒック統計情報を比較し、変化が大きいFQDNをトラヒック変化要因として抽出する。
【０１１０】
＜E：任意の粒度でのトラヒック統計情報の比較＞
上記までの手法は、全トラヒック統計情報が大きく変化した場合に粒度を細かくしていきその要因を特定する技術である。しかしながら、上記では変化要因が特定できない場合が存在する。例えば、全体で1日1億クエリのNWがあり、その中の特定ドメインへのクエリが1日1万のケースを考える。そのドメイン名を持つサーバがダウンしたとき、全体量だけで見ていると1万/1億しか変化しないように見えるが、実際にはサーバがダウンして顧客がサービスを受けられない状態になっていると考えられ、NW事業者にとって問題になる。
【０１１１】
例えば、あるFQDNのトラヒック変化が発生したとき、その変化量が全DNSトラヒック量に対して小さい場合は、最初のステップで検知されず変化を検知することができない。そこで、任意の粒度のトラヒック変化検知を行う。
【０１１２】
具体的には、全Public suffixから変化検知を行う方法と、全Private suffixから変化検知を行う方法と、FQDNの上位N個のトラヒック変化検知を行う方法である。ここで、上位N個としたのは、ドメイン空間は膨大であり、全てのFQDNの変化検知を行うために必要な計算リソースが膨大となるためである。
【０１１３】
なお、上記の図１、図７に示すDNSトラヒック統計情報分析装置１００，２００の各構成要素をプログラムとして構築し、DNSトラヒック統計情報分析装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【０１１４】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１１５】
１  DNSサーバ
２  ユーザ端末
３  DNSオペレータ端末
１０  DNSトラヒック収集装置
２０  DNSトラヒック統計情報記憶部
１００，２００  DNSトラヒック統計情報分析装置
１１０，２１０  FQDN解析部
１２０，２２０  DNSトラヒック統計情報計算部
１３０，２３０  木構造データ構築部
２４０  統計情報記憶部
２５０  変化検知部
【図２】
2015173342.tif 000003
【図３】
2015173342.tif 000004
【図４】
2015173342.tif 000005
【図５】
2015173342.tif 000006
【図６】
2015173342.tif 000007
【図８】
2015173342.tif 000008
【図１】
2015173342.tif 000009
【図７】
2015173342.tif 000010
【手続補正書】
【提出日】平成27年6月2日(2015.6.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項６
【補正方法】変更
【補正の内容】
【請求項６】
DNS(Domain  Name  System)トラヒックデータから統計情報を取得して分析する装置における統計情報分析方法であって、
前記DNSトラヒックデータのFQDN(Fully  Qualified  Domain  Name)を抽出し、該FQDNを複数の粒度の文字列データに分解するFQDN解析ステップと、
前記DNSトラヒックデータのトラヒック統計情報を計算する統計情報計算ステップと、
前記文字列データから２種類の木を生成し、該木及びグラフの各ノードに前記トラヒック統計情報を対応付けてトラヒック統計情報としてトラヒック統計情報記憶手段に記憶する木構造データ構築ステップと、
前記トラヒック統計情報記憶手段の前記木及び前記グラフからトラヒック統計情報を取得して出力する統計情報検索ステップと、
を行うことを特徴とする統計情報分析方法。