(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上述の方法では、暗号化された通信(例えば、SSL(Secure Sockets Layer)暗号化通信等)や独自プロトコルの通信の場合、ヘッダ内のドメイン名を取得することができない。さらに、サーバの負荷を軽減するためのキャッシュサーバが利用されていると、逆引きしてもキャッシュサーバのドメイン名しか取得できない。また、OSI(Open System Interconnection)参照モデルのレイヤ4から上位レイヤをすべて暗号化するようなIPsec(Security Architecture for Internet Protocol)等を利用するVPN(Virtual Private Network)サービスの場合も、上述の方法ではドメイン名を取得できない。
【0006】
ここで、ユーザが体感する通信の品質を維持及び向上させるためのネットワーク設計の実現には、通信網がどのように使われているのか、例えば、サービス種別等を知る必要がある。
【0007】
そこで、通信網を介してユーザ端末が接続するサービスの種別を推定し、その結果、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができる装置が求められている。
【0008】
本発明は、通信網を介してユーザ端末が接続するサービスの種別を推定し、その結果、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができるサービス推定装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【0009】
具体的には、以下のような解決手段を提供する。
【0010】
(1) ユーザ端末とサーバとの通信セッションに基づいて、前記通信セッションのサービス種別を推定するサービス推定装置であって、前記ユーザ端末とDNSサーバとの通信における、前記DNSサーバから前記ユーザ端末に送信されるDNSレスポンスを取得するレスポンス取得手段と、前記レスポンス取得手段によって取得された前記DNSレスポンスに基づいて、ユーザ端末がDNSサーバに問合わせたドメイン名と、DNSサーバが前記ユーザ端末に回答したIPアドレスとを抽出する抽出手段と、前記抽出手段によって抽出された前記ドメイン名と前記IPアドレスとを対応させ、DNSマップ記憶手段に記憶させる記憶制御手段と、前記ユーザ端末と前記サーバとの間の前記通信セッションを取得するセッション取得手段と、前記セッション取得手段によって取得された前記通信セッションから送信先IPアドレスを抽出する送信先アドレス抽出手段と、前記送信先アドレス抽出手段によって抽出された前記送信先IPアドレスに対応付けられた前記ドメイン名を、前記DNSマップ記憶手段に基づいて取得することによって前記サービス種別を推定する推定手段と、を備えるサービス推定装置。
【0011】
(1)の構成によれば、サービス推定装置は、ユーザ端末とDNSサーバとの通信における、DNSサーバからユーザ端末に送信されるDNSレスポンスを取得し、取得したDNSレスポンスに基づいて、ユーザ端末がDNSサーバに問合わせたドメイン名と、DNSサーバがユーザ端末に回答したIPアドレスとを抽出し、抽出したドメイン名とIPアドレスとを対応させ、DNSマップ記憶手段に記憶させる。そして、サービス推定装置は、ユーザ端末とサーバとの間の通信セッションを取得し、取得した通信セッションから送信先IPアドレスを抽出し、抽出した送信先IPアドレスに対応付けられたドメイン名を、DNSマップ記憶手段に基づいて取得することによってサービス種別を推定する。
【0012】
すなわち、(1)の構成に係るサービス推定装置は、ユーザ端末がサーバと通信セッションを開始する前に、ユーザ端末の問合わせによるDNSサーバからの回答に基づいて、サーバのドメイン名とIPアドレスとを対応付けたDNSマップを作成し、作成したDNSマップに基づいて、ユーザ端末が開始した通信セッションの送信先IPアドレスに対応するドメイン名を取得する。ドメイン名は、サーバが提供するサービスを示す単語や、サービスを含む分野において周知な用語を用いて表わされることが多い。
【0013】
したがって、(1)の構成に係るサービス推定装置は、通信網を介してユーザ端末が接続するサーバであって、キャッシュサーバではない本来のサーバのドメイン名を取得することによってサービス種別を推定することができる。その結果、(1)の構成に係るサービス推定装置は、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができる。
【0014】
(2) 前記記憶制御手段は、前記抽出手段によって抽出された前記ドメイン名と前記IPアドレスとを前記ユーザ端末ごとに対応させ、前記DNSマップ記憶手段に記憶させる、(1)に記載のサービス推定装置。
【0015】
したがって、(2)の構成に係るサービス推定装置は、通信網を介してユーザ端末が接続するサーバであって、キャッシュサーバではない本来のサーバのドメイン名を確実に取得することによってサービス種別を推定することができる。その結果、(2)の構成に係るサービス推定装置は、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、確実な情報を提供することができる。
【0016】
(3) 前記レスポンス取得手段によって取得された前記DNSレスポンスに基づいて、前記ドメイン名と前記IPアドレスとの対応付けが有効である時間を示す有効時間を抽出する有効時間抽出手段をさらに備え、前記記憶制御手段は、前記有効時間抽出手段によって抽出された前記有効時間を、前記ドメイン名と前記IPアドレスと共に前記DNSマップ記憶手段に記憶させ、前記推定手段は、前記セッション取得手段によって取得された前記通信セッションが、前記DNSマップ記憶手段に記憶された前記有効時間内である場合に、前記DNSマップ記憶手段に基づいて取得した前記ドメイン名によって前記サービス種別を推定する、(2)に記載のサービス推定装置。
【0017】
すなわち、(3)に係るサービス推定装置は、ドメイン名とIPアドレスとの対応付けが有効である時間を示す有効時間を抽出し、抽出した有効時間を、ドメイン名とIPアドレスと共にDNSマップ記憶手段に記憶させ、取得した通信セッションが、記憶された有効時間内である場合に、DNSマップに基づいて取得したドメイン名によってサービス種別を推定する。
【0018】
したがって、(3)の構成に係るサービス推定装置は、通信網を介してユーザ端末が接続するサーバであって、キャッシュサーバではない本来のサーバのドメイン名をさらに確実に取得することによってサービス種別を推定することができる。その結果、(3)の構成に係るサービス推定装置は、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、さらに確実な情報を提供することができる。
【0019】
(4) (1)に記載のサービス推定装置が実行するサービス推定方法であって、前記レスポンス取得手段が、前記ユーザ端末とDNSサーバとの通信における、前記DNSサーバから前記ユーザ端末に送信されるDNSレスポンスを取得するレスポンス取得ステップと、前記抽出手段が、前記レスポンス取得ステップによって取得された前記DNSレスポンスに基づいて、ユーザ端末がDNSサーバに問合わせたドメイン名と、DNSサーバが前記ユーザ端末に回答したIPアドレスとを抽出する抽出ステップと、前記記憶制御手段が、前記抽出ステップによって抽出された前記ドメイン名と前記IPアドレスとを対応させ、DNSマップ記憶手段に記憶させる記憶制御ステップと、前記セッション取得手段が、前記ユーザ端末と前記サーバとの間の前記通信セッションを取得するセッション取得ステップと、前記送信先アドレス抽出手段が、前記セッション取得ステップによって取得された前記通信セッションから送信先IPアドレスを抽出する送信先アドレス抽出ステップと、推定手段が、前記送信先アドレス抽出ステップによって抽出された前記送信先IPアドレスに対応付けられた前記ドメイン名を、前記DNSマップ記憶手段に基づいて取得することによって前記サービス種別を推定する推定ステップと、を備えるサービス推定方法。
【0020】
したがって、(4)の方法は、(1)と同様に、通信網を介してユーザ端末が接続するサーバであって、キャッシュサーバではない本来のサーバのドメイン名を取得することによってサービス種別を推定することができる。その結果、(4)の方法は、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができる。
【発明の効果】
【0021】
本発明によれば、通信網を介してユーザ端末が接続するサーバであって、キャッシュサーバではない本来のサーバのドメイン名を取得することによってサービス種別を推定することができる。さらに、本発明によれば、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができる。
【発明を実施するための形態】
【0023】
以下、本発明の実施形態について、図を参照しながら説明する。
図1は、本発明の一実施形態に係るサービス種別の推定の概要を説明するための図である。なお、
図1は、1台のDNSサーバ30、サーバ40、ユーザ端末50を示すがこれに限られず、複数台のDNSサーバ、サーバ、ユーザ端末により構成されていてもよい。サーバ40は、例えば、メールサービスを提供するメールサーバや、アプリケーション処理を提供するアプリケーションサーバ、コンテンツ(文章や画像等)を提供するコンテンツサーバやWebサーバ等のように、サービスを提供するサーバである。
【0024】
最初に、ユーザ端末50は、通信網70を介して、サーバ40との通信セッションを行うために、DNSサーバ30に、サーバ40のドメイン名に対応するIPアドレスを調べる名前解決のための問合わせの要求をする。
DNSサーバ30は、問合わせの要求に対し、サーバ40のドメイン名に対応するIPアドレスを求め、ユーザ端末50に回答の応答をする。サービス推定装置10は、DNSサーバ40からの応答に基づいて、サーバ40のドメイン名とIPアドレスとを抽出し、DNSマップ20として記憶させる。
【0025】
次に、ユーザ端末50が、サーバ40に、サービスの要求をする。
サービス推定装置10は、サービスの要求に含まれる送信先IPアドレスに対応するサーバ40のドメイン名をDNSマップ20に基づいて取得し、取得したドメイン名に基づいてサービス種別を推定する。
このようにして、サービス推定装置10は、SSL等に代表される秘匿化技術によって秘匿化された通信セッションがキャッシュサーバによって処理される場合であっても、実際にユーザが利用しているサービス種別を推定することができる。
【0026】
以後の説明において、ユーザ端末50とDNSサーバ30との間で送受信される具体的なデータについて、ドメインシステムとプロトコルとの詳細を説明するRFC1035に基づいた例により説明する。
【0027】
RFC1035によれば、通信メッセージは、Header、Question、Answer、Authority、Additionalのセクションから構成される。
Questionセクションを構成するレコードのうち、QTYPEレコードが「A」の場合に、Questionセクションを構成するQNAMEレコードにドメイン名(例えば、example.com)が格納されている。
また、Answerセクションを構成するレコードのうち、TYPEレコードが「A」の場合に、Answerセクションを構成するRDATAレコードにIPアドレスが格納されている。さらに、Answerセクションを構成するTTLレコードにTTL(Time to live)が格納されている。
【0028】
図2は、本発明の一実施形態に係るサービス推定装置10の構成を示す図である。サービス推定装置10は、レスポンス取得手段11と、抽出手段12と、有効時間抽出手段13と、記憶制御手段14と、セッション取得手段15と、送信先アドレス抽出手段16と、推定手段17と、DNSマップ20とを備える。以下、各手段について詳述する。
【0029】
レスポンス取得手段11は、ユーザ端末50とDNSサーバ30との通信における、DNSサーバ30からユーザ端末50に送信されるDNSレスポンスを取得する。具体的には、レスポンス取得手段11は、ユーザ端末50からDNSサーバ30への問合わせの要求に対する、DNSサーバ30からユーザ端末50への回答の応答を取得する。すなわち、ユーザ端末50は、サーバ40と通信を行うために、サーバ40のIPアドレスを求めるための問合わせの要求をDNSサーバ30に対し行う。この問合わせの要求に対し、DNSサーバ30は、サーバ40のドメイン名に対応するIPアドレスを求め、回答の応答をユーザ端末50に対し行う。レスポンス取得手段11は、この回答の応答であるDNSレスポンスを取得する。
【0030】
抽出手段12は、レスポンス取得手段11によって取得されたDNSレスポンスに基づいて、ユーザ端末50がDNSサーバ30に問合わせたドメイン名と、DNSサーバ30がユーザ端末50に回答したIPアドレスとを抽出する。具体的には、抽出手段12は、DNSサーバ30からユーザ端末50への応答に基づいて、例えば、Questionセクションに含まれるドメイン名と、Answerセクションに含まれるIPアドレスとを抽出する。
【0031】
記憶制御手段14は、抽出手段12によって抽出されたドメイン名とIPアドレスとを対応させ、DNSマップ20に記憶させる。具体的には、記憶制御手段14は、サーバ40のドメイン名と、サーバ40のIPアドレスとを対応させたDNSマップ20を作成する。記憶制御手段14は、通信網内を流れるDNSサーバ30のDNSレスポンスをすべてピックアップしてDNSマップ20を作るとしてもよい。作成されたDNSマップ20は、全ユーザにおいて共通である。例えば、一部のユーザ端末50が、端末側DNSキャッシュにより、DNSサーバ30に問合わせの要求をしない場合でも、他のユーザ端末50が、DNSサーバ30に問合わせの要求をしていれば、記憶制御手段14は、DNSマップ20を作成することができるので、効率がよい。
【0032】
なお、ドメイン名とIPアドレスとの対応関係に有効期限があり、対応関係が頻繁に変更される場合、記憶制御手段14は、ドメイン名とIPアドレスとの対応関係についての最新の情報に基づいて、DNSマップ20を更新するとしてもよい。
【0033】
セッション取得手段15は、ユーザ端末50とサーバ40との間の通信セッションを取得する。具体的には、セッション取得手段15は、推定対象とする通信セッションとして、ユーザ端末50からサーバ40へ送信されるアプリケーション・プロセス間のパケットを取得する。
【0034】
送信先アドレス抽出手段16は、セッション取得手段15によって取得された通信セッションから送信先IPアドレスを抽出する。具体的には、送信先アドレス抽出手段16は、セッション取得手段15によって取得されたパケットの送信先IPアドレスを抽出する。
【0035】
推定手段17は、送信先アドレス抽出手段16によって抽出された送信先IPアドレスに対応付けられたドメイン名を、DNSマップ20に基づいて取得することによってサービス種別を推定する。具体的には、推定手段17は、抽出された送信先IPアドレスによってDNSマップ20を検索し、検索した送信先IPアドレスに対応付けられたドメイン名を取得する。さらに、推定手段17は、通信セッションごとに、推定したサービス種別を対応付けた通信セッション履歴を記憶させるとしてもよい。このような通信セッション履歴を解析することによって、ネットワーク設計をするための情報が得られるので、サービス推定装置10は、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができる。
【0036】
さらに、記憶制御手段14は、抽出手段12によって抽出されたドメイン名とIPアドレスとをユーザ端末50ごとに対応させたDNSマップ20を作成するとしてもよい。具体的には、記憶制御手段14は、ユーザ端末50のIPアドレス(例えば、DNSサーバ30からのDNSレスポンスに含まれる送信先IPアドレス)ごとに、サーバ40のドメイン名及びIPアドレスを対応させたDNSマップ20を作成する(後述する
図3を参照)。推定手段17は、セッション取得手段15によって取得されたパケットの送信元IPアドレス(すなわち、ユーザ端末50のIPアドレス)によってDNSマップ20を検索し、検索した送信元IPアドレス(すなわち、ユーザ端末50)に対応付けられた情報のうち、抽出されたパケットの送信先IPアドレス(すなわち、サーバ40のIPアドレス)に対応付けられたドメイン名を取得する。
【0037】
さらに、有効時間抽出手段13は、レスポンス取得手段11によって取得されたDNSレスポンスに基づいて、ドメイン名とIPアドレスとの対応付けが有効である時間を示す有効時間を抽出する。記憶制御手段14は、有効時間抽出手段13によって抽出された有効時間を、ドメイン名とIPアドレスと共にDNSマップ20に記憶させる。推定手段17は、セッション取得手段15によって取得された通信セッションが、DNSマップ20に記憶された有効時間内である場合に、DNSマップ20に基づいて取得したドメイン名によってサービス種別を推定する。
【0038】
具体的には、有効時間抽出手段13は、例えば、Answerセクションに格納された有効時間であるTTLと、DNSレスポンスの通信時刻であるDNSレスポンス時刻とを抽出し、該DNSレスポンスの有効期間を抽出する。記憶制御手段14は、後述する
図3に示すように、抽出されたTTL及びDNSレスポンス時刻を、ドメイン名とIPアドレスと共にDNSマップ20に記憶させる。推定手段17は、取得された通信セッションのセッション開始時刻が、DNSマップ20に記憶された対応する有効期間内である場合に、ドメイン名によってサービス種別を推定する。
すなわち、推定手段17は、通信セッションのセッション開始時刻(例えば、session_begin_time)≧DNSレスポンス時刻(例えば、Response_timing)であり、かつ、通信セッションのセッション開始時刻<DNSレスポンス時刻+有効時間(例えば、Response_timing+TTL)である場合に、取得したドメイン名を有効なドメイン名であると判断し、ドメイン名によってサービス種別を推定する。
【0039】
図3は、本発明の一実施形態に係るサービス推定装置10によるDNSマップ20の例を示す図である。
図3に示すように、DNSマップ20は、ユーザ端末50のIPアドレスごとに、サーバ40のドメイン名と、サーバ40のIPアドレスと、DNSレスポンス時刻と、TTLとを対応付けて記憶する。
ユーザ端末50のIPアドレス、サーバ40のドメイン名及びサーバ40のIPアドレスは、抽出手段12によって抽出され、DNSレスポンス時刻及びTTLは、有効時間抽出手段13によって抽出される。
【0040】
図4は、本発明の一実施形態に係るサービス推定装置10のDNSマップ作成処理を示すフローチャートである。
図5及び
図6は、本発明の一実施形態に係るサービス推定装置10のサービス種別推定処理を示すフローチャートである。サービス推定装置10は、コンピュータ及びその周辺装置が備えるハードウェア並びに該ハードウェアを制御するソフトウェアによって構成され、以下の処理は、制御部(例えば、CPU)が所定のソフトウェアに従い実行する処理である。なお、DNSマップ作成処理及びサービス種別推定処理は、互いに独立に発生する複数の通信セッションを、それぞれ並行して処理する。
【0041】
(DNSマップ作成処理)
ステップS101において、CPU(レスポンス取得手段11)は、DNSレスポンスを取得する。より具体的には、CPUは、ユーザ端末50からDNSサーバ30に対する問合わせの要求に対する、DNSサーバ30からユーザ端末50に対する回答の応答を取得する。
【0042】
ステップS102において、CPU(抽出手段12、有効時間抽出手段13)は、サーバ40のドメイン名及びIPアドレスと、有効期間とを抽出する。より具体的には、CPUは、DNSサーバ30からユーザ端末50への応答に基づいて、Questionセクションに含まれるドメイン名と、Answerセクションに含まれるIPアドレスと、DNSレスポンスの有効期間として、Answerセクションに含まれるTTL(有効時間)と、応答の時刻であるDNSレスポンス時刻とを抽出する。
【0043】
ステップS103において、CPU(記憶制御手段14)は、DNSマップ20を作成する。より具体的には、CPUは、ユーザ端末50ごとに、サーバ40のドメイン名とサーバ40のIPアドレスとDNSレスポンス時刻とTTLとを対応させたDNSマップ20を作成する。その後、CPUは処理をステップS101に移す。
【0044】
(サービス種別推定処理)
ステップS201において、CPU(セッション取得手段15)は、サービス種別を推定するための、ユーザ端末50とサーバ40との間の通信セッションを取得する。より具体的には、CPUは、ユーザ端末50からサーバ40へ送信されるアプリケーション・プロセス間のパケットを取得する。
【0045】
ステップS202において、CPU(送信先アドレス抽出手段16)は、通信セッションから送信先IPアドレスと送信元IPアドレスとを抽出する。より具体的には、CPUは、取得されたパケットの送信先IPアドレス(サーバ40のIPアドレス)と送信元IPアドレス(ユーザ端末50のIPアドレス)とを抽出する。
【0046】
ステップS203において、CPU(推定手段17)は、送信元IPアドレス及び送信先IPアドレスによってDNSマップ20を検索する。より具体的には、CPUは、抽出された送信元IPアドレス(ユーザ端末50のIPアドレス)によってDNSマップ20を検索し、検索したユーザ端末50のIPアドレスに対応付けられたサーバ40のIPアドレスのうち、抽出された送信先IPアドレスと同一のIPアドレスを検索する。
【0047】
ステップS204において、CPU(推定手段17)は、該当レコードが存在するか否かを判断する。この判断がYESの場合、CPUは処理をステップS205に移し、この判断がNOの場合、CPUは処理をステップS209に移す。
【0048】
ステップS205において、CPU(推定手段17)は、DNSレスポンスが有効期間内であるか否かを判断するために、通信セッションのセッション開始時刻がDNSレスポンス時刻以降か否かを判断する。より具体的には、CPUは、ステップS203において検索したレコードのDNSレスポンス時刻と、ステップS201において取得した通信セッションのセッション開始時刻とを比較し、通信セッションのセッション開始時刻≧DNSレスポンス時刻であるか否かを判断する。この判断がYESの場合、CPUは処理をステップS206に移し、この判断がNOの場合、CPUは処理をステップS208に移す。
【0049】
ステップS206において、CPU(推定手段17)は、DNSレスポンスが有効期間内であるか否かを判断するために、通信セッションのセッション開始時刻がDNSレスポンス時刻から有効時間以内か否かを判断する。より具体的には、CPUは、ステップS203において検索したレコードのデータのうち、ステップS202において抽出された送信先IPアドレス(サーバ40のIPアドレス)に対応付けられたTTL及びDNSレスポンス時刻と、通信セッションのセッション開始時刻とを比較し、通信セッションのセッション開始時刻<DNSレスポンス時刻+TTLであるか否かを判断する。この判断がYESの場合、CPUは処理をステップS207に移し、この判断がNOの場合、CPUは処理をステップS208に移す。
【0050】
ステップS207において、CPU(推定手段17)は、サービス種別を推定する。より具体的には、CPUは、有効期間内のDNSレスポンスを記憶するDNSマップ20に基づいて、通信セッションの送信先IPアドレスと同一のIPアドレスに対応付けられたサーバ40のドメイン名を抽出して、通信セッションのサービス種別を推定する。さらに、CPUは、通信セッションの情報と、推定したサービス種別(ドメイン名)とを対応付けて記憶させ、後述する
図8に示すような通信セッションの履歴を作成することによって、ネットワーク設計のための情報を提供する。その後、CPUは処理をステップS201に移す。
【0051】
ステップS208において、CPU(推定手段17)は、他に該当レコードが存在するか否かを判断する。この判断がYESの場合、CPUは処理をステップS205に移し、この判断がNOの場合、CPUは処理をステップS209に移す。
【0052】
ステップS209において、CPU(推定手段17)は、送信先IPアドレスによってDNSマップ20を再度検索する。より具体的には、CPUは、抽出された送信元IPアドレス(ユーザ端末50のIPアドレス)に関わらず、抽出された送信先IPアドレスによってDNSマップ20のサーバ40のIPアドレスを再度検索する。
【0053】
ステップS210において、CPU(推定手段17)は、該当レコードが存在するか否かを判断する。この判断がYESの場合、CPUは処理をステップS211に移し、この判断がNOの場合、CPUは処理をステップS201に移す。
【0054】
ステップS211において、CPU(推定手段17)は、サービス種別を推定する。より具体的には、CPUは、ステップS207と同様に、DNSマップ20に基づいて、通信セッションの送信先IPアドレスと同一のIPアドレスに対応付けられたサーバ40のドメイン名を抽出して、通信セッションのサービス種別を推定し、後述する
図8に示すような通信セッションの履歴を作成する。その後、CPUは処理をステップS201に移す。
【0055】
図7は、本発明の一実施形態に係るサービス推定装置10による処理の例を示す図である。
図7の例は、サービス推定装置10が、DNSサーバ30からの応答に基づいて、サーバ40のドメイン名とIPアドレスとを抽出し、DNSマップ20を作成したことを示している。さらに、
図7の例は、ユーザ端末50がサービスの要求をした通信セッションによって、サービス推定装置10が、DNSマップ20に基づいて、サービスの要求に含まれる送信先IPアドレス(例えば、dst_ipaddr:198.51.100.2)に対応するサーバ40のドメイン名(例えば、example.com)を取得したことを示す例である。
【0056】
図8は、本発明の一実施形態に係るサービス推定装置10によるサービス種別の推定の結果の例を示す図である。
図8の例は、サービス種別の推定の結果として、サービス推定装置10が、通信セッションごとの情報(例えば、セッション開始時刻、送信元IPアドレス、送信元ポート、送信先IPアドレス及び送信先ポート)に、推定したサービス種別(サーバ40のドメイン名)を対応付けて記憶させた例である。
【0057】
本実施形態では、サービス推定装置10は、ユーザ端末50とDNSサーバ30との通信における、DNSサーバ30からユーザ端末50に送信されるDNSレスポンスを取得し、取得したDNSレスポンスに基づいて、ユーザ端末50がDNSサーバ30に問合わせたドメイン名と、DNSサーバ30がユーザ端末50に回答したIPアドレスとを抽出し、抽出したドメイン名とIPアドレスとを対応させ、DNSマップ20に記憶させる。そして、サービス推定装置10は、ユーザ端末50とサーバ40との間の通信セッションを取得し、取得した通信セッションから送信先IPアドレスを抽出し、抽出した送信先IPアドレスに対応付けられたドメイン名を、DNSマップ20に基づいて取得することによってサービス種別を推定する。
【0058】
さらに、サービス推定装置10は、ドメイン名とIPアドレスとの対応付けが有効である時間を示す有効時間を抽出し、ユーザ端末50ごとに、ドメイン名及びIPアドレスとDNSレスポンスの有効期間とを対応付けたDNSマップ20を作成し、取得した通信セッションが、DNSマップ20に記憶されたDNSレスポンスの有効期間内である場合に、DNSマップ20に基づいて取得したドメイン名によってサービス種別を推定する。
【0059】
したがって、サービス推定装置10は、通信網を介してユーザ端末50が接続するサーバ40であって、キャッシュサーバではない本来のサーバ40のドメイン名を確実に取得することによってサービス種別を推定することができる。その結果、サービス推定装置10は、ユーザが体感する通信の品質を維持及び向上させるようなネットワーク設計を実現させるために、情報を提供することができる。
【0060】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。
【0061】
本実施形態では、DNSレスポンスのQTYPE値が「A」であるAレコードの場合に関する例のみを記載したがこれに限られない。DNSのRFCによれば、これ以外に、AAAAレコードやCNAME、TXT、SRV等の様々なQTYPE値に対応して、DNSレスポンスレコード中にAnswerごとのTYPE値が存在する。サービス推定装置10は、Aレコード以外にも、取得したDNSレスポンスの様々なレコードタイプに対応する情報(例えば、ホスト名等のサービスに関する情報)をDNSマップ20に記憶させるとしてもよい。サービス推定装置10は、DNSマップ20により、通信セッションの送信先IPアドレスに対応するドメイン名を抽出すると共に、これらのサービスに関する情報をも抽出することによって、サービス種別を推定することができる。
【0062】
本実施形態では、サービス推定装置10は、送信元IPアドレス(ユーザ端末50)及び送信先IPアドレス(サーバ40のIPアドレス)によって検索しても検索できなかった場合に、条件を緩和して送信先IPアドレス(サーバ40のIPアドレス)によって再度検索するとしたがこれに限られない。例えば、送信元IPアドレス(ユーザ端末50)及び送信先IPアドレス(サーバ40のIPアドレス)によって検索できた場合には、有効期間の条件の判断を行わないとしてもよい。また、送信先IPアドレス(サーバ40のIPアドレス)によって再度検索した場合に、有効期間の条件を判断するとしてもよい。
サービス推定装置10は、検索条件を緩和して、サーバ40のドメイン名等を得やすくすることによって、ネットワーク設計に適用可能な多くの情報を提供することができる。
【0063】
本実施形態では、DNSマップ20における有効期限の切れたレコードについて特に記載していないが、サービス推定装置10は、DNSマップ20から有効期限の切れたレコードを削除するとしてもよい。サービス推定装置10は、DNSマップ20の増大を防止することができる。