Aggregation device, aggregation method, and program

Abstract

An aggregation device according to one aspect of the present disclosure comprises: a first calculation unit that calculates at least the number of times of co-occurrence between different FQDNs, by using the number of DNS queries with respect to FQDNs for users in each time slot; a second calculation unit that calculates the degree of similarity between the different FQDNs, by using said number of times of co-occurrence; a graph construction unit that constructs a graph composed of nodes representing the FQDNs and branches each having the degree of similarity as a weight; a community analysis unit that detects communities to which the respective nodes included in the graph belong; and an aggregation unit that aggregates the FQDNs represented by the nodes belonging to the same community.

Description

[Technical Field]

[0001] The present disclosure relates to an aggregation device, an aggregation method, and a program. [Background technology]

[0002] As traffic demand increases year by year, telecommunications carriers are required to prepare server resources to prevent degradation of QoS (Quality of Service). However, excessive resource expansion aimed at preventing QoS degradation leads to increased costs. For this reason, it is necessary to expand resources in a way that accurately reflects the traffic demand for services.

[0003] Generally, before traffic occurs, fully qualified domain names (FQDNs) are resolved by DNS (Domain Name System) queries. Furthermore, FQDNs are often associated with service names provided by the destination server. Therefore, the time-series changes in the number of DNS queries can be used as an indicator of traffic demand for a service. However, because there are various patterns in the time-series changes in the number of DNS queries, accurate analysis of the time-series changes in the number of DNS queries requires a technique for classifying DNS queries based on the time-series change patterns. Furthermore, because DNS queries occur before traffic occurs and can be associated with each other, the classification of DNS queries and the classification of traffic can be considered the same.

[0004] Known prior art technologies for traffic classification include those described in, for example, Patent Document 1 and Non-Patent Document 1. However, since a DNS query generally contains a huge number of FQDNs, it is necessary to aggregate the FQDNs to satisfy constraints on calculation time and memory capacity. In response to this, known prior art technologies for FQDN aggregation include those described in, for example, Non-Patent Document 2. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2020-136894 [Non-patent literature]

[0006] [Non-Patent Document 1] C. Zhang, M. Fiore, C. Ziemlicki and P. Patras, "Microscope: Mobile Service Traffic Decomposition for Network Slicing as a Service," MobiCom '20. [Non-patent document 2] M. Stevanovic, JM Pedersen, A. D'Alconzo, S. Ruehrup and A. Berger, "On the ground truth problem of malicious DNS traffic analysis," Computers & Security, vol. 55, pp. 142-158, 2015. Summary of the Invention [Problem to be solved by the invention]

[0007] However, conventional techniques have not been able to aggregate FQDNs appropriately. For example, the technique described in Non-Patent Document 2 aggregates FQDNs by focusing on the similarity of their character strings, which may result in the aggregation of FQDNs related to DNS queries with different patterns of time-series change.

[0008] The present disclosure has been made in consideration of the above points, and provides a technology for aggregating FQDNs. [Means for solving the problem]

[0009] An aggregation device according to one aspect of the present disclosure includes a first calculation unit that calculates at least the number of co-occurrences between different FQDNs using the number of DNS queries for each FQDN of each user in each time period, a second calculation unit that calculates the similarity between different FQDNs using the number of co-occurrences, a graph construction unit that constructs a graph composed of nodes representing FQDNs and branches having the similarity as weights, a community analysis unit that detects communities to which each node included in the graph belongs, and an aggregation unit that aggregates FQDNs represented by nodes belonging to the same community.

Advantages of the Invention

[0010] A technique for aggregating FQDNs is provided.

Brief Description of the Drawings

[0011] [Figure 1] FIG. 1 shows an example of the overall configuration of a system including the aggregation device according to the present embodiment. [Figure 2] FIG. 2 shows an example of the hardware configuration of the aggregation device according to the present embodiment. [Figure 3] FIG. 3 shows an example of the functional configuration of the aggregation device according to the present embodiment. [Figure 4] FIG. 4 is a flowchart showing an example of the aggregation process according to the present embodiment. [Figure 5] FIG. 5 shows an example of a graph and its community detection.

Modes for Carrying Out the Invention

[0012] Hereinafter, an embodiment of the present invention will be described.

[0013] <DNS Query Count and Its Time-Series Variation> Generally, before traffic occurs, FQDN name resolution is performed by a DNS query, and the FQDN is often associated with the service name provided by the destination server. Here, name resolution means obtaining the corresponding IP (Internet Protocol) address from the FQDN. Also, "FQDN is often associated with service name" means, for example, that if the destination server provides service A, the FQDN of that server is often an FQDN associated with the service name, such as "www.service-a.co.jp." Note that name resolution may also be called "DNS name resolution."

[0014] For this reason, as mentioned above, we can focus on the time-series changes in the number of DNS queries as an indicator of traffic demand for a service. However, a characteristic of the time-series changes in the number of DNS queries is that various patterns exist depending on the user sending the DNS queries and the FQDN to be resolved. For example, the number of DNS queries generated when accessing a social networking service (SNS) from a smartphone tends to increase during the day, while the number of DNS queries generated mechanically by the server tends to remain constant.

[0015] <Prior art of traffic classification> If DNS queries can be classified (i.e., traffic can be classified) based on the pattern of time-series changes in the number of DNS queries, it will be possible to distinguish between DNS queries with different patterns even in an environment where DNS queries with various patterns coexist. As a result, it will be possible to accurately analyze the time-series changes in the number of DNS queries (i.e., accurately analyze traffic demand based on the pattern of time-series changes in the number of DNS queries), making it possible to increase resources in a way that accurately reflects traffic demand.

[0016] Conventional technologies for traffic classification can be broadly divided into two types: "methods based on supervised learning" and "methods based on unsupervised learning."

[0017] Supervised learning-based methods As a method based on supervised learning, there is a method that uses a classification model based on a convolutional neural network, which is one of the deep learning models (for example, Non-Patent Document 1, etc.). This method attempts to improve the accuracy of traffic classification by adding information to the classification model by convolving traffic data from nearby base stations.

[0018] Unsupervised learning-based methods One method based on unsupervised learning is a pattern extraction method using non-negative tensor factorization (NTF) (see, for example, Patent Document 1). In this method, DNS queries are first classified into groups based on the similarity of their time-series change patterns, and a time-series prediction model is constructed for each group. Then, during prediction, the total number of DNS queries is predicted for each group using the time-series prediction model for that group. This makes it possible to construct a model that captures the time-series change patterns, and highly accurate predictions can be expected, compared to constructing a model that directly uses all DNS queries.

[0019] Specifically, using data recording the number of DNS queries for each pair (time, user, service) as input, the following steps 1-1 to 1-4 are performed to classify the pair (user, service) into predefined K patterns (where K is an integer equal to or greater than 1), and to predict the total number of future DNS queries (i.e., future traffic demand). Note that in this case, a service corresponds to an FQDN, and a user corresponds to a terminal that made a DNS query related to that FQDN.

[0020] Step 1-1: Create a tensor X with (time, user, service) as its axes and the number of DNS queries as its components.

[0021] Step 1-2: Apply NTF to tensor X and calculate matrices A, B, and C that indicate the similarity to K types of patterns for each element of time, user, and service. Here, for example, B = (b ik ), then b ik represents the similarity of user i to pattern k. The same applies to time and service. For example, A=(a tk ), C=(c jk ), then a tk is the similarity to pattern k at time t, and c jk represents the similarity of service j to pattern k, respectively.

[0022] Step 1-3: Using matrices B and C, the pattern of (user i, service j) is calculated.

[0023]

number

[0024] Step 1-4: For each group, a time series prediction model is constructed from the (user, service) pairs classified into that group, and future traffic demand is predicted using this time series prediction model. Note that any model used for time series prediction can be used as the time series prediction model, but examples that can be used include the ARIMA (autoregressive integrated moving average) model and LSTM (Long Short-Term Memory).

[0025] The above method uses NTF to calculate the time-series change pattern of the number of DNS queries for each pair (user, service). This makes it possible to capture patterns such as "the number of DNS queries generated when accessing a social networking service (service) from a smartphone (user) increases during the day."

[0026] <Issues with conventional technologies regarding traffic classification> Challenges with supervised learning-based methods Methods based on supervised learning have an issue (hereinafter referred to as issue 1) in that it is difficult to prepare the training data required to train a classification model. This is one of the reasons why traffic analysis is costly. For example, in the method described in Non-Patent Document 1, packets are analyzed using DPI (Deep Packet Inspection) and the association between traffic and services is collected as training data. However, introducing DPI requires modifications to the packet processing function, which increases processing time and implementation and management costs. Furthermore, with the increasing use of traffic encryption in recent years, telecommunications carriers are unable to know the contents of the traffic, which is another reason why preparing training data is difficult.

[0027] Challenges with unsupervised learning-based methods When the method described in Patent Document 1 is applied to DNS query logs using services as FQDNs, the number of FQDNs is enormous, so the tensor X created in step 1-1 above becomes extremely large. This poses a problem (hereinafter referred to as problem 2) in that it cannot be applied to large-scale data sets due to constraints on calculation time and memory capacity.

[0028] To solve the above problem 2, it is necessary to aggregate a huge number of FQDNs. However, there is also the problem of needing to find a way to avoid destroying the time-series change patterns that NTF is trying to extract (hereinafter referred to as problem 2-1). To address this issue, for example, a method of aggregating FQDNs by assuming service similarity between FQDNs with the same upper domain (Non-Patent Document 2) can be considered. This method focuses on the string-like similarity of FQDNs; for example, "www.example.co.jp" and "www.example-abc.co.jp" are aggregated to "co.jp." However, as shown in (a) and (b) below, the patterns of time-series change in the number of DNS queries for string-like FQDNs may differ. For this reason, the method described in Non-Patent Document 2 may actually worsen classification accuracy by aggregating FQDNs.

[0029] (a) Regarding services called Content Delivery Networks (CDNs), which are responsible for efficient traffic distribution, the FQDNs of services that use them tend to be similar. However, the time-series patterns of the number of DNS queries corresponding to each FQDN are not necessarily the same.

[0030] (b) Large IT companies often use similar FQDNs to provide a variety of services, such as webmail and cloud storage. Therefore, even in this case, the time-series patterns of DNS query counts for similar FQDNs are not necessarily the same.

[0031] <Proposed method> When classifying traffic, problem 1 above can be resolved by using a method based on unsupervised learning. Problem 2 above can be resolved by aggregating FQDNs as a preprocessing step. Problem 2-1 when aggregating FQDNs can be resolved by extracting a set of co-occurring FQDNs from DNS query logs, rather than focusing on the string similarity of FQDNs, and defining the similarity between FQDNs based on that set of FQDNs. Here, a set of co-occurring FQDNs refers to "a set consisting of FQDNs for which a specific user performed DNS name resolution during a specific time period." In the following, DNS query logs will be referred to as "DNS query logs."

[0032] The method for solving the above problem 2-1 is called the "proposed method," and the following embodiment describes an aggregation device 10 that aggregates FQDNs using this proposed method. Note that, because FQDN aggregation can be positioned as preprocessing for traffic classification, the aggregation device 10 may also be called a "preprocessing device" that performs preprocessing for traffic classification.

[0033] The proposed method described above can easily extract a set of FQDNs of services that tend to be accessed at the same time. Therefore, when classifying traffic using the method described in Patent Document 1, using the proposed method as preprocessing can reduce the impact on the subsequent NTF compared to using the method described in Non-Patent Document 2 as preprocessing.

[0034] <Example of overall configuration of system including aggregation device 10> An example of the overall configuration of a system including an aggregation device 10 according to this embodiment is shown in Fig. 1. As shown in Fig. 1, the system includes the aggregation device 10, a classification device 20, a DNS cache server 30, and one or more terminals 40. The aggregation device 10 and the classification device 20, the aggregation device 10 and the DNS cache server 30, and the DNS cache server 30 and the terminals 40 are connected to each other so that they can communicate with each other.

[0035] The aggregation device 10 calculates the number of DNS queries c obtained from the DNS query log held by the DNS cache server 30. tij The FQDNs are aggregated using the input data. tij represents the number of DNS queries for FQDN j by user i in time slot t. Also, let T, I, and J be the number of time slots, the number of users, and the number of FQDNs, respectively, and 1≦t≦T, 1≦i≦I, and 1≦j≦J.

[0036] The classification device 20 classifies traffic by the method described in Patent Document 1, using the FQDNs aggregated by the aggregation device 10. That is, the classification device 20 receives data recording the number of DNS queries for each pair (time, user, service) using the FQDNs aggregated by the aggregation device 10 as services, and classifies the pairs (user, service) into K types of patterns according to steps 1-1 to 1-3 above. As a result, traffic corresponding to (user, service) is classified into K types of patterns.

[0037] In addition to classifying traffic, the classification device 20 may construct a time series prediction model for each group by the above steps 1-4, and predict future traffic demands using this time series prediction model.

[0038] The DNS cache server 30 receives a DNS query from the terminal 40 and performs name resolution of the FQDN related to the DNS query. The DNS cache server 30 is connected to the Internet 50, and if name resolution is not possible using the information cached by the DNS cache server 30 itself, it sends the DNS query to another DNS cache server.

[0039] Terminal 40 is any of various terminals used by a user (for example, a PC (personal computer), a smartphone, a tablet terminal, a wearable device, a game console, etc.). Terminal 40 is connected to the Internet 50, and when using a service via the Internet 50, it sends a DNS query for the FQDN of the server that provides that service to DNS cache server 30. This performs name resolution of the FQDN, and terminal 40 can access the server that provides that service.

[0040] 1 is an example, and the overall configuration of a system including the aggregation device 10 is not limited to this. For example, the aggregation device 10 and the classification device 20 may be configured integrally, or the aggregation device 10, the classification device 20, and the DNS cache server 30 may be configured integrally. Also, for example, there may be a prediction device that builds a time series prediction model for each group by the above steps 1-4 and predicts future traffic demand using this time series prediction model.

[0041] <Example of hardware configuration of aggregation device 10> An example of the hardware configuration of the aggregation device 10 according to this embodiment is shown in Fig. 2. As shown in Fig. 2, the aggregation device 10 according to this embodiment includes an input device 101, a display device 102, an external I / F 103, a communication I / F 104, a RAM (Random Access Memory) 105, a ROM (Read Only Memory) 106, an auxiliary storage device 107, and a processor 108. Each of these pieces of hardware is connected to each other via a bus 109 so as to be able to communicate with each other.

[0042] The input device 101 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc. The display device 102 is, for example, a display, a display panel, etc. Note that the aggregation device 10 does not necessarily have to have at least one of the input device 101 and the display device 102, for example.

[0043] The external I / F 103 is an interface with an external device such as a recording medium 103a. Examples of the recording medium 103a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

[0044] The communication I / F 104 is an interface through which the aggregation device 10 communicates with the classification device 20, the DNS cache server 30, etc. The RAM 105 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The ROM 106 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off. The auxiliary storage device 107 is a non-volatile storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory. The processor 108 is, for example, one of various arithmetic devices such as a CPU (Central Processing Unit).

[0045] 2 is an example, and the hardware configuration of aggregation device 10 is not limited to this. For example, aggregation device 10 may have multiple auxiliary storage devices 107 or multiple processors 108, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.

[0046] <Example of functional configuration of aggregation device 10> An example of the functional configuration of the aggregation device 10 according to this embodiment is shown in Fig. 3. As shown in Fig. 3, the aggregation device 10 according to this embodiment includes a co-occurrence count calculation unit 201, a similarity calculation unit 202, a graph construction unit 203, a community analysis unit 204, and an FQDN aggregation unit 205. Each of these units is realized by, for example, processing in which one or more programs installed in the aggregation device 10 are executed by the processor 108 or the like.

[0047] The co-occurrence count calculation unit 201 calculates the number of DNS queries c tij (1≦t≦T, 1≦i≦I, 1≦j≦J) is used to calculate the number of co-occurrences between FQDNs and the number of appearances of each FQDN.

[0048] The similarity calculation unit 202 calculates the similarity between the FQDNs using the number of times the FQDNs co-occur and the number of times each FQDN appears.

[0049] The graph construction unit 203 uses the similarity between FQDNs to construct a graph (weighted graph) in which the FQDNs are nodes and the similarity between FQDNs is the weight of each edge.

[0050] The community analysis unit 204 applies a technique called community analysis to the graph to calculate the community to which each FQDN belongs.

[0051] The FQDN aggregation unit 205 aggregates FQDNs that belong to the same community.

[0052] <Aggregation processing> The aggregation process according to this embodiment will be described below with reference to FIG. 4. tij (1≦t≦T, 1≦i≦I, 1≦j≦J) as input data, and the set (input data set) {c tij |1≦t≦T, 1≦i≦I, 1≦j≦J} is given to the aggregation device 10.

[0053] First, the co-occurrence count calculation unit 201 calculates the number of DNS queries c tij Using (1≦t≦T, 1≦i≦I, 1≦j≦J), the number of co-occurrences between FQDNs and the number of appearances of each FQDN are calculated according to the following steps 2-1 to 2-3.

[0054] Step 2-1: The co-occurrence count calculation unit 201 calculates the number of DNS queries c tij (1≦t≦T, 1≦i≦I, 1≦j≦J) for each time period t and each user i. ti :={j|1≦j≦J,c tij >0}.

[0055] Step 2-2: The co-occurrence count calculation unit 201 calculates the number of times that two different FQDNs j1 and j2 co-occur, s(j1, j2):=#{(t, i)|1≦t≦T, 1≦i≦I, j1, j2∈u ti}. Note that s(j1,j2)=s(j2,j1).

[0056] Step 2-3: The co-occurrence count calculation unit 201 calculates the number of occurrences s(j1):=s(j1,1)+···+s(j1,J) of the FQDN j1.

[0057] As a result, the number of co-occurrences s(j1, j2) between FQDNs j1 and j2 (where 1≦j1, j2≦J, j1≠j2) and the number of appearances s(j) of FQDN j (1≦j≦J) are obtained.

[0058] Next, the similarity calculation unit 202 calculates the similarity between the FQDNs using the number of co-occurrences between the FQDNs calculated in step S101 above and the number of appearances of each FQDN (step S102). Hereinafter, the similarity between FQDNs j1 and j2 (where 1≦j1, j2≦J, j1≠j2) is referred to as sim(j1, j2). Since the similarity between FQDNs in the proposed method is intended to reflect co-occurrence tendencies, for example, the Jaccard index or PMI (Pairwise Mutual Information) described in Reference 1 can be used.

[0059] For example, when calculating the similarity sim(j1, j2) for FQDNs j1 and j2 using the Jaccard index, the similarity calculation unit 202 may use the number of co-occurrences s(j1, j2) and the numbers of occurrences s(j1) and s(j2) to calculate the similarity sim(j1, j2) as follows: sim(j1, j2):=s(j1, j2) / (s(j1)+s(j2)-s(j1, j2)).

[0060] However, other than the Jaccard index and PMI, it is also possible to use, for example, the co-occurrence frequency described in Reference 1. For example, when calculating the similarity sim(j1, j2) between FQDNs j1 and j2 based on the co-occurrence frequency, the similarity calculation unit 202 may calculate sim(j1, j2):=s(j1, j2) using the number of co-occurrences s(j1, j2).

[0061] When a similarity sim(j1, j2) that does not use the number of occurrences s(j), such as a co-occurrence frequency, is used, the number of occurrences of the FQDN does not have to be calculated in step S101.

[0062] Next, the graph construction unit 203 uses the similarities between the FQDNs calculated in step S102 to construct a graph in which the FQDNs are nodes and the similarities between the FQDNs are edge weights (step S103). This constructs a graph G=(V, E). Here, V:={j|1≦j≦J}, E:={sim(j1,j2)|1≦j1,j2≦J, j1≠j2}. To prevent the graph from having too many edges, the graph construction unit 203 may set a threshold δ, such that E={sim(j1,j2)|1≦j1,j2≦J, j1≠j2, sim(j1,j2)>δ}, and delete edges with small weights.

[0063] As an example, graph G when J=5 is shown in Figure 5. In the example shown in Figure 5, V={1,2,3,4,5}, E={sim(1,2),sim(1,3),sim(1,5),sim(2,3),sim(3,4),sim(4,5)}={0.5,0.6,0.2,0.7,0.1,0.9}. Note that in the example shown in Figure 5, sim(1,4), sim(2,4), sim(2,5), and sim(3,5) have been deleted.

[0064] Next, the community analysis unit 204 applies a community detection algorithm to the graph constructed in step S103 above, and detects the community to which each node (FQDN) belongs (step S104). Here, the community detection algorithm is an algorithm that detects a subset of nodes in a graph that are closely connected to each other. The community analysis unit 204 may apply, for example, the community detection algorithm described in Reference 2 to the graph G constructed in step S103 above. As a result, the community to which each FQDN j belongs is calculated (detected), and a set (subset of V) consisting of FQDNs that are highly similar to each other is obtained. Hereinafter, assuming that K communities have been calculated in this step, the community to which FQDN j belongs is referred to as α j (1≦α j ≦K).

[0065] As an example, the community detection result for graph G where J = 5 is shown in Fig. 5. In the example shown in Fig. 5, it is calculated that j = 1, 2, 3 belong to community 1, and j = 4, 5 belong to community 2.

[0066] Finally, the FQDN aggregating unit 205 aggregates FQDNs that belong to the same community (step S105). That is, the FQDN aggregating unit 205 calculates j in the input data set by α j This aggregates J FQDNs into K FQDNs, thereby solving the above-mentioned problem 2-1. Therefore, the classification device 20 can classify traffic with high accuracy while satisfying constraints on calculation time and memory capacity.

[0067] <Summary> As described above, the aggregation device 10 according to this embodiment defines similarities between FQDNs based on sets of co-occurring FQDNs and aggregates FQDNs based on those similarities. This enables aggregation of FQDNs without destroying the pattern of time-series changes in the number of DNS queries. Therefore, by performing FQDN aggregation by the aggregation device 10 according to this embodiment as preprocessing, even when a large set of DNS query counts is given as an input data set, it becomes possible to classify traffic with high accuracy while satisfying constraints related to calculation time and memory capacity, for example, by using the method described in Patent Document 1.

[0068] <Supplementary information> The main purpose of the proposed method described above is to aggregate FQDNs as preprocessing for NTF-based methods (such as the method described in Patent Document 1) that classify traffic by (user, service) unit, but it is not limited to this and the proposed method may also be used alone. In this case, unlike NTF-based methods, the classification is rough by service unit, and the classification accuracy is lower than that of existing methods, but the amount of calculation can be reduced.

[0069] Furthermore, in environments where DNS queries are encrypted, such as DoH (DNS over HTTPS), it is not possible to obtain the FQDN that serves as the classification unit, and the proposed method cannot be applied simply. However, it is possible to perform similar calculations by using the destination IP address of the traffic instead of the FQDN. This is because the proposed method can aggregate using the co-occurrence of queries rather than the string similarity of FQDNs. However, it should be noted that IP address classification may not work well if DNS and IP addresses do not necessarily correspond one-to-one, for example, due to the use of anycast DNS.

[0070] The present invention is not limited to the above-described specifically disclosed embodiments, and various modifications, changes, and combinations with known technologies are possible without departing from the scope of the claims.

[0071] [References] Reference 1: Akiko Aizawa, "Similarity Measures Based on Co-occurrence," Operations Research: Management Science, vol. 52, no. 11, pp. 706-712, 2007. Reference 2: A. Clauset, M. Newman and C. Moore, "Finding community structure in very large networks," Physical review.E, vol. 70, p. 06111, 2005. [Explanation of symbols]

[0072] 10 Aggregation Device 20 Classifier 30 DNS cache servers 40 terminals 50 Internet 101 Input Device 102 Display device 103 External I / F 103a Recording media 104 Communication I / F 105 RAM 106 ROM 107 Auxiliary storage 108 processors 109 Bus 201 Co-occurrence count calculation unit 202 Similarity calculation part 203 Graph Construction Department 204 Community Analysis Department 205 FQDN aggregation section

Claims

1. a first calculation unit that calculates at least the number of co-occurrences between different FQDNs using the number of DNS queries for each FQDN of each user in each time period; a second calculation unit that calculates a similarity between different FQDNs using the number of co-occurrences; a graph constructing unit that constructs a graph consisting of nodes representing FQDNs and edges having the similarities as weights; a community analysis unit that detects a community to which each node included in the graph belongs; an aggregator that aggregates FQDNs represented by nodes that belong to the same community; An aggregation device having:

2. The first calculation unit The number of DNS queries is c ｔｉｊ (where T, I, and J are the number of time periods, the number of users, and the number of FQDNs, respectively, and 1≦t≦T, 1≦i≦I, and 1≦j≦J), and the set of FQDNs co-occurring for each time period t and each user i is u ｔｉ :={j|1≦j≦J,c ｔｉｊ >0}, Two different FQDNs j １ , j ２ (where 1≦j １ , j ２ ≦J, j １ ≠j ２ ) with respect to the number of co-occurrences s(j １ , j ２ ):=#{(t, i) | 1≦t≦T, 1≦i≦I, j １ , j ２ ∈u ｔｉ }.

3. The first calculation unit The aggregation device according to claim 2 , further calculating the number of occurrences s(j):=s(j,1)+ . . . +s(j,J) of FQDN j (where 1≦j≦J).

4. The second calculation unit The aggregation device according to claim 3 , wherein the similarity is calculated as a Jaccard index or a PMI.

5. The second calculation unit The aggregation device according to claim 2 , wherein the similarity is calculated based on a co-occurrence frequency.

6. The collecting unit is The FQDN j represented by the nodes belonging to the same community is expressed as information α ｊ (where K is the number of communities, and 1≦α ｊ The aggregation device according to claim 1 , wherein the aggregation device aggregates the FQDNs by replacing the FQDNs with the FQDNs (K or less).

7. a first calculation step of calculating at least the number of co-occurrences between different FQDNs using the number of DNS queries for each FQDN of each user in each time period; a second calculation step of calculating a similarity between different FQDNs using the number of co-occurrences; a graph construction procedure for constructing a graph consisting of nodes representing FQDNs and edges having the similarities as weights; a community analysis procedure for detecting the community to which each node in the graph belongs; an aggregation procedure for aggregating FQDNs represented by nodes belonging to the same community; A computer-implemented aggregation method.

8. a first calculation step of calculating at least the number of co-occurrences between different FQDNs using the number of DNS queries for each FQDN of each user in each time period; a second calculation step of calculating a similarity between different FQDNs using the number of co-occurrences; a graph construction procedure for constructing a graph consisting of nodes representing FQDNs and edges having the similarities as weights; a community analysis procedure for detecting the community to which each node in the graph belongs; an aggregation procedure for aggregating FQDNs represented by nodes belonging to the same community; A program that causes a computer to execute the following.

Images