DNS control device and DNS control method

Abstract

In order to make it possible to update DNS records in a shorter time even when communication terminals perform reconnection simultaneously in a DNS system, this DNS control device comprises: a storage unit that stores management information for managing change content of the DNS records in the DNS system; and a DNS control unit that aggregates the change content in host zone units and reflects the change content in the DNS records.

Description

DNS Control Device and DNS Control Method

[0001] The present invention relates to a DNS control device and a DNS control method.

[0002] As a method for performing name resolution using an IP address leased from an ISP (Internet Service Provider) or the like without fixing the IP (Internet Protocol) address, Dynamic DNS (Domain Name System) is known (for example, see Non-Patent Document 1).

[0003] "What is Dynamic DNS (DDNS)? Explanation of Merits and Mechanisms", NVR Blog, System K, [Searched on September 17, Reiwa 6], Internet <URL: https: / / nvr.bz / topics / information / dns.php>

[0004] In Dynamic DNS, by changing the records of the authoritative DNS server according to the change of the IP address, name resolution of the IP address can be performed after a certain period.

[0005] However, DNS is not a system assumed to rewrite a large number of DNS records in a short period. Therefore, for example, in an API (Application Programming Interface) for rewriting DNS records, the change request is restricted per unit time.

[0006] On the other hand, as a countermeasure against large-scale disasters such as a building being damaged by a disaster, a building in a remote location may be configured as a redundant system so that disaster recovery can be performed. In this case, when a switchover due to disaster recovery occurs, communication terminals will all reconnect at once. Therefore, for example, even when the network-side authentication and the IP address issuance process have sufficient throughput, there is a problem that the rewriting of DNS records is delayed.

[0007] An embodiment of the present invention has been made in view of the above problems, and in a DNS system, even when communication terminals reconnect all at once, the update of DNS records can be performed in a shorter time.

[0008] To solve the above problems, a DNS control device according to an embodiment of the present invention includes, in a DNS system, a storage unit that stores management information for managing changes to DNS records, and a DNS control unit that aggregates the changes on a host zone basis and reflects them in the DNS records.

[0009] According to an embodiment of the present invention, in a DNS system, even when communication terminals simultaneously reconnect, the DNS record can be updated in a shorter time.

[0010] This figure shows an example of the system configuration of the DNS system according to Example 1. This is Figure (1) showing an example of management information according to Example 1. This is Figure (2) showing an example of management information according to Example 1. This is a flowchart showing an example of change management processing according to Example 1. This is a flowchart showing an example of change management processing for domain information according to Example 1. This is Figure (1) showing an example of a domain information management table according to Example 1. This figure shows an example of change management processing for host information according to Example 1. This is Figure (1) showing an example of a host information management table according to Example 1. This is a flowchart showing an example of change management processing for IP addresses according to Example 1. This is Figure (2) showing an example of a host information management table according to Example 1. This is a flowchart showing an example of DNS control processing according to Example 1. This is a flowchart showing an example of domain addition processing according to Example 1. This is Figure (2) showing an example of a domain information management table according to Example 1. This is a flowchart showing an example of host information update processing according to Example 1. This is Figure (3) showing an example of a host information management table according to Example 1. This is a flowchart showing an example of domain deletion processing according to Example 1. This is Figure (4) showing an example of a host information management table according to Example 1. This figure shows an example of the system configuration of the DNS system according to Example 2. This figure shows an example of an IP address management table according to Example 2. This flowchart shows an example of a change management process according to Example 2. This flowchart shows an example of a building switching process according to Example 2. This figure shows an example of a host information management table according to Example 2. This flowchart shows an example of an authentication unit process according to Example 2. This figure shows an example of a computer hardware configuration. This is Figure (1) for explaining the background. This is Figure (2) for explaining the background. This is a figure for explaining the problem.

[0011] Hereinafter, embodiments of the present invention (this embodiment) will be described with reference to the drawings. The embodiments described below are merely examples, and the embodiments to which the present invention is applied are not limited to the embodiments described below.

[0012] <Background and Challenges> As a countermeasure against large-scale disasters such as building damage, for example, buildings in remote locations should be configured as redundant systems to enable disaster recovery.

[0013] When switching between buildings, network limitations may arise, such as a change in the IP address range. Even in this case, for example, as shown in Figure 24, by changing the IP address resolved by DNS (Domain Name System) to the new address, clients 12 can access the site using the domain name as before the switch.

[0014] In the example shown in Figure 24, for instance, if building 10a is damaged and server 11a becomes unavailable, the DNS switches the IP address "IP1" of server 11a to the IP address "IP2" of server 11b. As a result, client 12 can access server 11b located in building 10b using the domain name (FQDN: Fully Qualified Domain Name) from before the disaster.

[0015] In this embodiment, for example, as shown in Figure 25, a domain name (FQDN) is assigned to the mobile terminal, and the building is configured to recover from disaster as a redundant system even if building 20a is damaged.

[0016] In the example shown in Figure 25, for example, if building 20a is damaged and the mobile terminal 21c in building 20a becomes unusable, the DNS will, for example, switch the IP address "IP1" of the mobile terminal 21c to the IP address "IP2" of server 11b. As a result, client 22 will be able to access the mobile terminal 21c in building 20b using the domain name (FQDN) from before the disaster.

[0017] (Challenge) DNS is not a system designed for frequent record rewriting in a short period of time. The same applies to managed services; the API (Application Programming Interface) for rewriting records has an hourly limit on the number of change requests.

[0018] On the other hand, when a network switchover occurs due to disaster recovery, communication terminals will all reconnect simultaneously. Therefore, even if, for example, the network-side authentication and IP address allocation processes have sufficient throughput, there is a problem in that DNS record rewriting will be delayed.

[0019] Figure 26 is a diagram illustrating the problem. For example, suppose a network switchover occurs due to disaster recovery, and mobile terminals 31 simultaneously request to reconnect to the mobile network 32. This results in the allocation of a large number of IP addresses (for example, 10,000).

[0020] On the other hand, DNS37 limits the number of APIs that accept the addition, modification, or deletion of host zones and the addition, modification, or deletion of host records to five per second. In this case, due to the limitations on the DNS37 side, switching the IP address of the mobile terminal 31 would take a long time, as long as 10,000 / 5 = 2,000 seconds.

[0021] (Solution) In both DNS systems and DNS services, host zones are managed on a per-subdomain basis, and it is common for multiple host record updates within the same host zone to be processed at once (for example, configuration files are separate for each host zone, or an API for bulk updates of host zones is provided).

[0022] Changes are reflected in the hosted zone, for example, when an administrator creates a new hosted zone, changes existing settings, or deletes existing settings. Changes are reflected in the host records, for example, when an IP address is assigned from the network to the UE, when a hostname is set, changed, or deleted to resolve the UE's IP address, or when DNS cache time is set or changed.

[0023] The DNS system according to this embodiment improves the speed of updating by grouping the changes to these DNS records into zone-level changes and processing them all at once. This embodiment is applicable not only to mobile networks but also to any network that manages the allocation of IP addresses to communication terminals.

[0024] [Example 1] <System Configuration> Figure 1 shows an example of the system configuration of a DNS system according to this embodiment. In the example in Figure 1, the DNS system 100 includes a DNS control device 110, an operating terminal 101, a mobile terminal 102, a mobile network 103, an authentication unit 104, and a DNS 105, etc. Of the above-mentioned components, the mobile terminal 102, the mobile network 103, the authentication unit 104, and the DNS 105 may be provided outside the system.

[0025] The operation terminal 101 is an information processing device with a computer configuration, used by administrators (or operators) who manage the DNS system 100. The operation terminal 101 is connected to the DNS control device 110 so as to be able to communicate with it, and administrators can use the operation terminal 101 to perform operations on the DNS control device 110 such as adding, changing, and deleting domains, and adding, changing, and deleting hosts.

[0026] The DNS control device 110 is an information processing device with a computer configuration, or a system including multiple computers. The DNS control device 110 stores and manages the allocation of IP addresses to terminals that need to be reflected in the DNS 105 (authentication events), and the details of various changes made by administrators, etc., in the management information 115. The DNS control device 110 also reflects multiple changes stored in the management information 115 to the DNS 105 all at once.

[0027] For example, the DNS control device 110 implements the functional configurations shown in Figure 1 by executing a predetermined program on the computer provided in the DNS control device 110. In the example in Figure 1, the DNS control device 110 has functional configurations such as a change reception unit 111, an authentication event reception unit 112, a DNS control unit 113, and a storage unit 114. At least some of the above functional configurations may be implemented by hardware.

[0028] The change reception unit 111 receives the details of the DNS record changes from the operation terminal 101 and performs a change reception process to store and manage the received changes in the management information 115. For example, the change reception unit 111 provides the operation terminal 101, etc., with an API that accepts changes such as domain changes (addition, modification, deletion, etc.) and host changes (addition, modification, deletion, etc.).

[0029] The management information 115 includes, for example, a domain information management table 201 as shown in Figure 2A, and a host information management table 202 as shown in Figure 2B.

[0030] For example, when the change reception unit 111 receives a request to change (add, modify, or delete) a domain, it adds, modifies, or deletes a record in the domain information management table 201, stores in the "Expected Operation" field whether the change is an addition, modification, or deletion, and stores in the "Timestamp" field the date and time of the change, etc.

[0031] As a result, as shown in Figure 2A, in the domain information management table 201, records being added (records for which an addition request has been received but the addition is not yet complete) will have "Add" stored in the "Expected Operation" field. Similarly, in the domain information management table 201, records being deleted will have "Delete" stored in the "Expected Operation" field.

[0032] Furthermore, when the change reception unit 111 receives a request to change (add, modify, or delete) host information, it adds, modifies, or deletes a record in the host information management table 202, stores in the "Expected Operation" field whether the change is an addition, modification, or deletion, and stores the date and time of the change in the "Timestamp" field. In this way, the status of each record can be managed in the host information management table 202 in the same way as in the domain information management table 201.

[0033] The authentication event reception unit 112 receives an authentication event from the authentication unit 104 and executes an authentication event reception process that stores and manages the details of the IP address change caused by the authentication event in the management information 115.

[0034] The authentication unit 104 in Embodiment 1 authenticates the mobile terminal 102 requesting connection to the mobile network 103 on the mobile network 103 side and assigns (allocates) an IP address. The authentication unit 104 also notifies the authentication event reception unit 112 of authentication event information, including the MSISDN (Mobile Station International Subscriber Directory Number), which is identification information for the mobile terminal 102, and the IP address assigned to the mobile terminal 102. Note that the mobile terminal 102 is an example of a communication terminal according to this embodiment.

[0035] For example, the authentication event reception unit 112 retrieves a record containing the MSISDN included in the authentication event information from the host information management table 202, and stores the IP address included in the authentication event information in the "IP address" field of the retrieved record. The authentication event reception unit 112 also stores "change" in the "expected operation" field of the retrieved record, and stores the date and time of the change in the "timestamp" field.

[0036] The DNS control unit 113 performs DNS control processing to reflect the changes stored in the management information 115 in the DNS records of the DNS 105, grouped by host zone for each subdomain. Preferably, the DNS control unit 113 reflects the changes stored in the management information 115 in the DNS records so as not to exceed the limits of the DNS system 1.

[0037] The storage unit 114 is implemented, for example, by a program executed by a computer provided in the DNS control device 110, and a storage device provided in the DNS control device 110, and stores management information 115 that manages the changes made to the DNS record. In Embodiment 1, the management information 115 includes the domain information management table 201 and the host information management table 202 described above.

[0038] DNS105 is a system (or service) that manages the correspondence between domain names and IP addresses, and translates domain names into IP addresses.

[0039] Note that the system configuration of the DNS system 1 shown in FIG. 1 is an example. For example, the change reception unit 111 and the authentication event reception unit 112 may be a single reception unit. Also, the change reception unit 111 and the authentication event reception unit 112 may only receive the change content, and the management of the management information 115 may be performed by an information management unit or the like.

[0040] <Processing Flow> Next, the processing flow of the DNS control method according to the present embodiment will be described.

[0041] (Change Content Management Processing) FIG. 3 is a flowchart showing an example of the change content management processing according to the first embodiment. This processing shows an example of a process in which the DNS control device 110 reflects the change content of the DNS record received by the change reception unit 111 and the authentication event reception unit 112 in the management information 115.

[0042] In step S301, the change reception unit 111 determines whether it has received a domain change request. If it has received a domain change request, the change reception unit 111 transfers the process to step S302. On the other hand, if it has not received a domain change request, the change reception unit 111 transfers the process to step S303.

[0043] When transferring to step S302, the change reception unit 111 executes, for example, the change content management process of the domain information as shown in FIG. 4. The change content management process of the domain information will be described later.

[0044] When transferring from step S301 to S303, the change reception unit 111 determines whether it has received a host information change request. If it has received a host information change request, the change reception unit 111 transfers the process to step S304. On the other hand, if it has not received a host information change request, the change reception unit 111 transfers the process to step S305.

[0045] When transferring to step S304, the change reception unit 111 executes, for example, the change content management process of the host information as shown in FIG. 6. The change content management process of the host information will be described later.

[0046] When shifting from step S303 to S305, the authentication event reception unit 112 determines whether it has received authentication event information. If it has received the authentication event information, the authentication event reception unit 112 causes the process to shift to step S306. On the other hand, if it has not received the authentication event information, the authentication event reception unit 112 ends the process of FIG. 3.

[0047] When shifting to step S306, the authentication event reception unit 112 executes, for example, a process for managing changes in IP addresses as shown in FIG. 8. The process for managing changes in IP addresses will be described later.

[0048] The DNS control device 110 stores and manages the changes in DNS records in the management information 115 by, for example, repeatedly executing the process of FIG. 3.

[0049] Note that the change content management process shown in FIG. 3 is an example. For example, the processes of steps S301 to S304 and the processes of steps S305 and S306 may be executed separately in parallel.

[0050] (Change content management process for domain information) FIG. 4 is a flowchart showing an example of a change content management process for domain information according to the first embodiment. This process shows, for example, an example of a change content management process for domain information executed by the change reception unit 111 in step S302 of FIG. 3.

[0051] In step S401, the change reception unit 111 determines whether it has received a domain addition request. If it has received the domain addition request, the change reception unit 111 causes the process to shift to step S402. On the other hand, if it has not received the domain addition request, the change reception unit 111 causes the process to shift to step S403.

[0052] When the process moves to step S402, the change reception unit 111 adds the domain to the domain information management table 201 according to the received domain addition request and stores the management information "addition". For example, if the change reception unit 111 adds the domain "domain-0.com" to a record in the domain information management table 201 as shown in Figure 5, it stores "addition" in the "expected operation" field of the record and stores information indicating the date and time of the change in the "timestamp" field. At this point, no value is set in the "ID" field of the record.

[0053] When the process moves from step S401 to S403, the change reception unit 111 determines whether or not it has received a domain change request (change). Here, a domain change request (change) refers to a request for a domain change, among domain change requests that request the addition, modification, or deletion of a domain. If a domain change request (change) has been received, the change reception unit 111 moves the process to step S404. On the other hand, if a domain change request (change) has not been received, the change reception unit 111 moves the process to step S406.

[0054] When the process moves to step S404, the change reception unit 111 retrieves a record from the domain information management table 201 that matches the domain of the received domain change request.

[0055] In step S405, the change reception unit 111 makes changes to the acquired records in accordance with the received domain change request and stores the "change" management information.

[0056] For example, when the change reception unit 111 modifies a record in the domain information management table 201 as shown in Figure 5, it stores "Modified" in the "Expected Operation" field of the record and stores information indicating the date and time of the modification in the "Timestamp" field. Preferably, the change reception unit 111 stores information such as the modified value or modified item in the "Other Attributes" field of the modified record.

[0057] When the process moves to step S406, the change reception unit 111 determines whether or not it has received a request to delete the domain. If it has received a request to delete the domain, the change reception unit 111 proceeds to step S407. On the other hand, if it has not received a request to delete the domain, the change reception unit 111 terminates the process shown in Figure 4.

[0058] When the process moves to step S407, the change reception unit 111 retrieves a record from the domain information management table 201 that matches the domain of the domain deletion request that was received.

[0059] In step S408, the change reception unit 111 stores the management information for "deletion". For example, when the change reception unit 111 deletes a record in the domain information management table 201 as shown in Figure 5, it stores "delete" in the "expected operation" field of the record and stores information indicating the deletion date and time in the "timestamp" field.

[0060] As shown in Figure 4, when the change reception unit 111 receives a request to change a domain (add, change, or delete), it can store and manage the change details in the domain information management table 201.

[0061] (Host Information Change Management Process) Figure 6 is a flowchart showing an example of the host information change management process according to Embodiment 1. This process shows an example of the host information change management process executed by the change reception unit 111 in step S304 of Figure 3.

[0062] In step S601, the change reception unit 111 determines whether or not it has received a request to add host information. If it has received a request to add host information, the change reception unit 111 moves the process to step S602. On the other hand, if it has not received a request to add host information, the change reception unit 111 moves the process to step S603.

[0063] When the process moves to step S602, the change reception unit 111 adds the host to the host information management table 202 and stores the management information for "addition". For example, if the change reception unit 111 adds a record for the host name "host-01" to the host information management table 202 as shown in Figure 7, it stores "addition" in the "expected operation" field of the record and stores information indicating the date and time of the change in the "timestamp" field.

[0064] When the process moves from step S601 to S603, the change reception unit 111 determines whether or not it has received a request (change) for host information. Here, a request (change) for host information refers to a request for a change to host information, among requests for the addition, modification, or deletion of host information.

[0065] If a request (change) to host information is received, the change reception unit 111 moves the process to step S604. On the other hand, if no request (change) to host information is received, the change reception unit 111 moves the process to step S606.

[0066] When the process moves to step S604, the change reception unit 111 retrieves from the host information management table 202 the record in which the received host information change request (change) matches the MSISDN.

[0067] In step S605, the change reception unit 111 makes changes to the acquired record in accordance with the received host information change request (change) and stores the "change" management information. For example, if the change reception unit 111 changes a record in the host information management table 202 as shown in Figure 7, it stores "change" in the "expected operation" field of the record and stores information indicating the date and time of the change in the "timestamp" field.

[0068] When the process moves from step S603 to step S606, the change reception unit 111 determines whether or not it has received a request to delete host information. If it has received a request to delete host information, the change reception unit 111 moves the process to step S607. On the other hand, if it has not received a request to delete host information, the change reception unit 111 terminates the process shown in Figure 6.

[0069] When the process moves to step S607, the change reception unit 111 retrieves from the host information management table 202 the record in which the received host information deletion request matches the MSISDN.

[0070] In step S608, the change reception unit 111 stores "delete" management information for the acquired record. For example, when the change reception unit 111 deletes a record in the host information management table 202 as shown in Figure 7, it stores "delete" in the "expected operation" field of the record and stores information indicating the date and time of the change in the "timestamp" field.

[0071] As shown in Figure 6, when the change reception unit 111 receives a request to change host information (addition, modification, or deletion), it can store and manage the changes in the host information management table 202.

[0072] (IP Address Change Management Process) Figure 8 is a flowchart showing an example of the IP address change management process according to Embodiment 1. This process shows an example of the IP address change management process executed by the authentication event reception unit 112 in step S306 of Figure 3.

[0073] In step S801, the authentication event reception unit 112 retrieves a record from the host information management table 202 in which the received authentication event information matches the MSISDN.

[0074] In step S802, the authentication event reception unit 112 stores the IP address of the received authentication event information in the "IP address" field of the acquired record, and stores the "change" management information.

[0075] For example, if the IP address of record No. 3 in the host information management table shown in Figure 9 is changed, the authentication event reception unit 112 stores "Change" in the "Expected Operation" field of the record and stores information indicating the date and time of the change in the "Timestamp" field.

[0076] As shown in Figure 8, when the authentication event receiving unit 112 receives authentication event information, it can store and manage the changes to the IP address included in the authentication event information in the host information management table 202.

[0077] (DNS control processing) Figure 10 is a flowchart showing an example of DNS control processing according to Embodiment 1. This process shows an example of DNS control processing in which the DNS control unit 113 aggregates the changes stored in the management information 115 on a host zone basis and reflects them in the DNS record of the DNS 105, so as not to exceed the limits of the DNS system 1.

[0078] In step S1001, the DNS control unit 113 initializes the processing start time t0 to the current time, the final request time t1 to the current time, and the number of requests r to "0".

[0079] In step S1002, the DNS control unit 113 determines whether or not there is management information for "addition" in the domain information management table 201. For example, if there is a record in the domain information management table 201, as shown in Figure 5, where "addition" is stored in the "expected operation" field, the DNS control unit 113 determines that there is management information for "addition" in the domain information management table 201.

[0080] If there is "addition" management information in the domain information management table 201, the DNS control unit 113 moves the process to step S2003. On the other hand, if there is no "addition" management information in the domain information management table 201, the DNS control unit 113 moves the process to step S1004.

[0081] When the process moves to step S1003, the DNS control unit 113 performs a domain addition process, for example, as shown in Figure 11. The domain addition process will be described later.

[0082] When the process moves from step S1002 to S1004, the DNS control unit 113 determines whether or not there is management information in the host information management table 202. For example, the DNS control unit 113 determines that there is management information in the host information management table 202 if there is a record in the host information management table 202, as shown in Figure 9, in which the "Expected Operation" item contains "Add", "Change", or "Delete".

[0083] If there is management information in the host information management table 202, the DNS control unit 113 proceeds to step S1005. On the other hand, if there is no management information in the host information management table 202, the DNS control unit 113 proceeds to step S1006.

[0084] When the process moves to step S1005, the DNS control unit 113 performs a host information update process, for example, as shown in Figure 13. The host information update process will be described later.

[0085] When the process moves from step S1004 to S1006, the DNS control unit 113 determines whether or not there is management information for "delete" in the domain information management table 201. For example, if there is a record in the domain information management table 201, as shown in Figure 5, where "delete" is stored in the "expected operation" field, the DNS control unit 113 determines that there is management information for "delete" in the domain information management table 201.

[0086] If the domain information management table 201 contains "delete" management information, the DNS control unit 113 proceeds to step S1007. On the other hand, if the domain information management table 201 does not contain "delete" management information, the DNS control unit 113 proceeds to step S1008.

[0087] When the process moves to step S1007, the DNS control unit 113 executes a domain deletion process, for example, as shown in Figure 15. The domain deletion process will be described later.

[0088] When the process moves to step S1008, the DNS control unit 113 determines whether "t1 - t0 < 1 second" and "r <= 5". Here, t0 is the processing start time, t1 is the time of the last request, and r is the number of requests.

[0089] If "t1 - t0 < 1 second" and "r <= 5", the DNS control unit 113 proceeds to step S1002. On the other hand, if "t1 - t0 < 1 second" and "r <= 5" are not true, the DNS control unit 113 proceeds to step S1009.

[0090] When the process moves to step S1009, the DNS control unit 113 sleeps for a time of "1 second - (t1 - t0)" and then proceeds to step S1001.

[0091] As shown in Figure 10, the DNS control unit 113 can reflect multiple changes to the DNS 105, optimized to the limitations of the DNS side.

[0092] (Domain Addition Processing) Figure 11 is a flowchart showing an example of domain addition processing according to Embodiment 1. This processing shows an example of domain addition processing executed by the DNS control unit 113 in step S1003 of Figure 10.

[0093] In step S1101, the DNS control unit 113 retrieves one record of "Add" management information from the domain information management table 201. For example, the DNS control unit 113 retrieves a record (record with management No. 1) from the domain information management table 201 in which the "Expected Operation" item is "Add" as shown in Figure 5.

[0094] In step S1102, the DNS control unit 113 adds a host zone to the DNS 105 based on the acquired record.

[0095] In step S1103, the DNS control unit 113 stores the ID issued by DNS 105 when the host zone was added in the "ID" field of the acquired record in the domain information management table 201.

[0096] In step S1104, the DNS control unit 113 deletes the "additional" management information from the retrieved record in the domain information management table 201. For example, as shown in Figure 12, the DNS control unit 113 deletes the information stored in the "expected operation" field and the "timestamp" field of the retrieved record (the record with management No. 1) in the domain information management table 201.

[0097] In step S1105, the DNS control unit 113 updates the last request time t1 to the current time and adds 1 to the number of requests r.

[0098] (Host Information Management Processing) Figure 13 is a flowchart showing an example of host information update processing according to Embodiment 1. This process shows an example of host information update processing executed by the DNS control unit 113 in step S1005 of Figure 10.

[0099] In step S1301, the DNS control unit 113 retrieves the "domain" information from the record with the oldest "timestamp" among the records containing management information in the host information management table 202. For example, the DNS control unit 113 retrieves the record with the oldest date and time stored in the "timestamp" field (for example, the record with management No. 2) from the host information management table 202 as shown in Figure 9.

[0100] In step S1302, the DNS control unit 113 retrieves all records in the host information management table 202 that have management information and belong to the same domain as the retrieved domain. For example, the DNS control unit 113 retrieves records with management numbers 2, 3, and 5 from the host information management table 202 as shown in Figure 9, where information is stored in the "Expected Operation" and "Timestamp" fields, and the "Domain" field is "domain-1.com".

[0101] In step S1303, the DNS control unit 113 changes the host zone of DNS 105 all at once based on all the acquired records.

[0102] In step S1304, the DNS control unit 113 deletes the management information (expected operation and timestamp) from the records in the host information management table 202 that reflect additions or changes to the DNS 105. For example, as shown in Figure 14, the DNS control unit 113 deletes the management information stored in the "expected operation" and "timestamp" fields of records No. 2 and No. 3.

[0103] Furthermore, the DNS control unit 113 deletes the record in the host information management table 202 that reflects the deletion to the DNS 105. For example, as shown in Figure 14, the DNS control unit 113 deletes the record with management No. 5.

[0104] In step S1305, the DNS control unit 113 updates the last request time t1 to the current time and adds 1 to the number of requests r.

[0105] (Domain Deletion Process) Figure 15 is a flowchart showing an example of the domain deletion process according to Embodiment 1. This process shows an example of the domain deletion process executed by the DNS control unit 113 in step S1007 of Figure 10.

[0106] In step S1501, the DNS control unit 113 retrieves one record from the domain information management table 201 that stores the management information "delete". For example, the DNS control unit 113 retrieves a record with management No. 3 from the domain information management table 201, as shown in Figure 5, in which "delete" is stored in the "expected operation" field.

[0107] In step S1502, the DNS control unit 113 retrieves all records from the host information management table 202 that are in the same domain as the acquired record, and deletes them. For example, in the host information management table 202 as shown in Figure 16, the DNS control unit 113 deletes record 1601, which is in the same domain as the record acquired in step S1501 (domain-2.com).

[0108] In step S1504, the DNS control unit 113 deletes the host zone from DNS 105 based on the record obtained in step S1501.

[0109] In step S1505, the DNS control unit 113 deletes the record obtained in step S1501 from the domain information management table 201.

[0110] In step S1305, the DNS control unit 113 updates the last request time t1 to the current time and adds 1 to the number of requests r.

[0111] As explained in Figures 10-16, the DNS control unit 113 consolidates the changes stored in the management information 115 on a host zone basis and reflects them in the DNS record of the DNS 105, so as not to exceed the limits of the DNS system 1.

[0112] Note that the DNS control process shown in Figure 10 is just one example. For example, the conditions "t1 - t0 < 1 second" and "r <= 5" in step S1008 of Figure 10 can be changed to match the limitations of DNS 105 or DNS system 1. For example, if DNS 105 can accept n requests (where n is an integer greater than or equal to 1) per second, then "r <= 5" can be changed to "r <= n".

[0113] [Example 2] Example 2 describes an example of processing when the IP addresses to be allocated (assigned) to the mobile terminal (communication terminal) 102 are predetermined for each building. In Example 2, when the building is switched, the DNS control device 110 can reflect the IP address of the mobile terminal 102 after the building switch to the DNS 105 without waiting for the mobile terminal 102 to be re-authenticated. Note that "building" is an example of a predetermined area. The predetermined area may be, for example, a business establishment including one or more buildings, or a district including one or more buildings or business establishments. Here, the following explanation will be given assuming that the predetermined area is a "building".

[0114] Figure 17 shows an example of the system configuration of the DNS system according to Embodiment 2. As shown in Figure 17, the DNS control device 110 according to Embodiment 2 has an authentication unit 1701 that authenticates the mobile terminal 102 in the mobile network 103, instead of the authentication event reception unit 112 described in Figure 1.

[0115] Furthermore, the storage unit 114 according to Embodiment 2 also stores IP address management information for managing the IP addresses of multiple communication terminals in each predetermined area. For example, the management information 115 according to Embodiment 2 includes an IP address management table 1801 as shown in Figure 18. The IP address management table 1801 is information for managing the IP addresses corresponding to the MSISDN that identify each mobile terminal 102, on a building-by-building basis. Note that the IP address management table 1801 is just one example of IP address management information.

[0116] Furthermore, the change reception unit 111 according to Embodiment 2 receives a switching instruction for a predetermined area. When a switching instruction is received, it determines the changes to the DNS records of multiple communication terminals based on the IP address management information and stores them in the management information 115. For example, when the change reception unit 111 receives a switching instruction from the operation terminal 101 to switch from building A to building B, it uses the IP address of building B in the IP address management table 1801 to update the "IP address" item in the host information management table 202 included in the management information 115.

[0117] As a result, when the building is switched, the DNS control device 110 can reflect the IP address of the mobile terminal 102 after the building switch to the DNS 105 without waiting for the mobile terminal 102 to re-authenticate.

[0118] The authentication unit 1701 is implemented, for example, by a program executed on a computer provided in the DNS control device 110. The authentication unit 1701 performs authentication in response to an authentication request from the mobile terminal 102 and issues (assigns) an IP address stored in the host information management table 202 included in the management information 115. Therefore, when the authentication unit 1701 receives an authentication request from the mobile terminal 102 after the change acceptance unit 111 has received a building switching instruction, it can assign an IP address corresponding to the target building to the mobile terminal 102.

[0119] <Processing Flow> (Change Management Processing) Figure 19 is a flowchart showing an example of change management processing according to Embodiment 2. This process shows an example of how the DNS control device 110 reflects the changes in the DNS record received by the change reception unit 111 and the changes in the IP address due to the building switching instruction in the management information 115.

[0120] In step S1901, the change reception unit 111 determines whether or not it has received a request to change the domain. If it has received a request to change the domain, the change reception unit 111 proceeds to step S1902. On the other hand, if it has not received a request to change the domain, the change reception unit 111 proceeds to step S1903.

[0121] When the process moves to step S1902, the change reception unit 111 executes a domain information change management process, for example, as shown in Figure 3. The process in step S1902 may be the same as the domain information change management process described in Embodiment 1 in Figure 4.

[0122] When the process moves from step S1901 to S1903, the change reception unit 111 determines whether or not it has received a request to change the host information. If it has received a request to change the host information, the change reception unit 111 moves the process to step S1904. On the other hand, if it has not received a request to change the host information, the change reception unit 111 moves the process to step S1905.

[0123] When the process moves to step S1904, the change reception unit 111 executes a host information change management process, for example, as shown in Figure 6. The process in step S1904 may be the same as the host information change management process described in Embodiment 1 in Figure 6.

[0124] When the process moves from step S1903 to S1905, the change reception unit 111 determines whether or not it has received a building switchover instruction. If it has received a building switchover instruction, the change reception unit 111 proceeds to step S1906. On the other hand, if it has not received a building switchover instruction, the change reception unit 111 terminates the process shown in Figure 19.

[0125] When the process moves to step S1906, the change acceptance unit 111 executes a building switching process, for example, as shown in Figure 20.

[0126] (Building Switching Process) Figure 20 is a flowchart showing an example of the building switching process according to Embodiment 2. This process shows an example of the building switching process executed by the change reception unit 111 in step S1906 of Figure 19.

[0127] In step S2001, the change acceptance unit 111 executes the processes in steps S2011 to S2014 for all records in the IP address management table 1801.

[0128] In step S2011, the change reception unit 111 retrieves one unprocessed record from the IP address management table 1801.

[0129] In step S2012, the change acceptance unit 111 retrieves a record from the host information management table 202 in which the acquired record matches the MSISDN.

[0130] In step S2013, the change reception unit 111 overwrites the IP address of the record obtained from the host information management table 202 with the IP address of the target building obtained from the IP address management table 1801.

[0131] In step S2014, the change reception unit 111 stores the "change" management information in the rewritten record of the host information management table 202.

[0132] For example, suppose the building switching instruction received by the change reception unit 111 is a switching instruction from building A to building B. Also, suppose that in step S2011, the change reception unit 111 retrieves a record with MSISDN "00000000" from the IP address management table 1801, as shown in Figure 18.

[0133] In this case, in steps S2012 and S2013, the change reception unit 111 rewrites the "IP address" field of the record in the host information management table 202, as shown in Figure 21, where MSISDN is "00000000", to "22.11.11.11". Also, in step S2014, the change reception unit 111 stores "Change" in the "Expected Operation" field of the record in the host information management table 202, as shown in Figure 21, where MSISDN is "00000000", and stores information indicating the date and time the IP address was rewritten in the "Timestamp" field.

[0134] The change acceptance unit 111 performs the same process for all mobile terminals 102 managed in the IP address management table 1801.

[0135] (Authentication Unit Processing) Figure 22 is a flowchart showing an example of the authentication unit processing according to Embodiment 2. This processing shows an example of the processing that the authentication unit 1701 executes when it receives an authentication request.

[0136] In step S2201, when the authentication unit 1701 receives an authentication request from the mobile terminal 102 or the mobile network 103 requesting authentication of the mobile terminal 102, it executes the processing from step S2202 onward.

[0137] In step S2202, the authentication unit 1701 retrieves a record from the host information management table 202 in which the authentication request and the MSISDN match.

[0138] In step S2203, the authentication unit 1701 obtains the IP address from the acquired record and sets it as an attribute value in the response to the authentication request.

[0139] After executing the process shown in Figure 20, the authentication unit 1701 can then issue (assign) an IP address corresponding to the target building to the mobile terminal 102 requesting authentication by executing the process shown in Figure 22.

[0140] As described above, according to Embodiment 2, by pre-determining the IP address to be assigned to the mobile terminal 102 for each building, the IP address after the building switch can be reflected in the DNS 105 without waiting for re-authentication on the mobile terminal 102 side when switching buildings.

[0141] (DNS control processing) The DNS control processing according to Example 2 may be the same as the DNS control processing according to Example 1, as described in Figures 10 to 16.

[0142] <Hardware Configuration> The DNS control device 110 and the operating terminal 101 according to this embodiment have, for example, the hardware configuration of a computer 2300 as shown in Figure 23. The DNS control device 110 may be implemented by multiple computers 2300. Furthermore, the computer is not limited to a physical machine, but may be, for example, a virtual machine on the cloud.

[0143] Figure 23 shows an example of a computer hardware configuration. In the example in Figure 23, the computer 2300 includes a drive device 2301, an auxiliary storage device 2302, a memory device 2303, a CPU 2304, an interface device 2305, a display device 2306, an input device 2307, and an output device 2308, all of which are interconnected by bus B. The computer 2300 may also include other processors such as a GPU (Graphics Processing Unit).

[0144] The program that enables processing by the computer 2300 is provided on a recording medium 2311, such as a CD-ROM or memory card. When the recording medium 2311 containing the program is set in the drive device 2301, the program is installed from the recording medium 2311 to the auxiliary storage device 2302 via the drive device 2301. However, the program does not necessarily have to be installed from the recording medium 2311; it may also be downloaded from another computer via a network. The auxiliary storage device 2302 stores the installed program as well as necessary files and data.

[0145] The memory device 2303 reads and stores a program from the auxiliary storage device 2302 when a program startup command is received. The CPU 2304 implements functions related to the DNS control device 110 (or operation terminal 101), for example, according to the program stored in the memory device 2303. The interface device 2305 is used as an interface for connecting to a communication network, etc. The display device 2306 displays a GUI (Graphical User Interface) etc., based on a program. The input device 2307 consists of a keyboard, mouse, buttons, and / or touch panel etc., and is used to input various operation commands. The output device 2308 outputs the calculation results.

[0146] The CPU 2304 may be other processors such as a DSP (Digital Signal Processor), a PLD (Programmable Logic Device), or an FPGA (Field Programmable Gate Array).

[0147] <Effects of the Embodiment> According to this embodiment, even when communication terminals simultaneously reconnect in the DNS system, the DNS record can be updated in a shorter time. This makes it possible to reduce the time required to restore services in the event of a disaster such as building damage.

[0148] <Summary of Embodiments> This specification discloses at least the following DNS control devices, DNS control methods, and DNS systems: (Section 1) A DNS control device comprising: a storage unit that stores management information for managing changes to DNS records; and a DNS control unit that aggregates the changes on a host zone basis and reflects them in the DNS records. (Section 2) The DNS control device according to Section 1, wherein the DNS control unit reflects the changes to the DNS records in a manner that does not exceed the limits of the DNS system. (Section 3) The DNS control device according to Section 1 or Section 2, wherein the storage unit further stores IP address management information for managing the IP addresses of a plurality of communication terminals for each predetermined area; and the DNS control device has a change reception unit that receives a switching instruction for the predetermined area, and when it receives the switching instruction, determines the changes to the IP addresses of the plurality of communication terminals in the DNS records based on the IP address management information and stores them in the management information. (Clause 4) A DNS control method comprising: a computer in a DNS system which performs a storage process for storing management information for managing changes to DNS records; and a DNS control process for grouping the changes on a host zone basis and reflecting them in the DNS records. (Clause 5) A DNS system comprising: a storage unit for storing management information for managing changes to DNS records; and a DNS control unit for grouping the changes on a host zone basis and reflecting them in the DNS records.

[0149] Although this embodiment has been described above, the present invention is not limited to this specific embodiment, and various modifications and changes are possible within the scope of the gist of the invention as described in the claims.

[0150] 100 DNS system 101 Operating terminal 102 Mobile terminal (communication terminal) 105 DNS 110 DNS control device 111 Change reception unit 112 Authentication event reception unit 113 DNS control unit 114 Storage unit 115 Management information 1701 Authentication unit 201 Domain information management table 202 Host information management table 1801 IP address management table

Claims

1. A DNS control device comprising: a storage unit for storing management information that manages changes to DNS records in a DNS system; and a DNS control unit that aggregates the changes on a host zone basis and reflects them in the DNS records.

2. The DNS control device according to claim 1, wherein the DNS control unit reflects the changes in the DNS record so as not to exceed the limits of the DNS system.

3. The DNS control device according to claim 1 or 2, wherein the storage unit further stores IP address management information for managing the IP addresses of a plurality of communication terminals for each predetermined area, and the DNS control device has a change reception unit that receives a switching instruction for the predetermined area, and when the switching instruction is received, determines the content of the change to the IP addresses of the plurality of communication terminals in the DNS record based on the IP address management information and stores it in the management information.

4. A DNS control method comprising: a computer in a DNS system that performs a storage process for storing management information that manages changes to DNS records; and a DNS control process that aggregates the changes on a host zone basis and reflects them in the DNS records.

Images