WO2017067443A1 - 一种安全域名系统及其故障处理方法 - Google Patents

一种安全域名系统及其故障处理方法 Download PDF

Info

Publication number
WO2017067443A1
WO2017067443A1 PCT/CN2016/102424 CN2016102424W WO2017067443A1 WO 2017067443 A1 WO2017067443 A1 WO 2017067443A1 CN 2016102424 W CN2016102424 W CN 2016102424W WO 2017067443 A1 WO2017067443 A1 WO 2017067443A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
dns
domain name
dns request
authorization information
Prior art date
Application number
PCT/CN2016/102424
Other languages
English (en)
French (fr)
Inventor
濮灿
Original Assignee
北京奇虎科技有限公司
奇智软件（北京）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京奇虎科技有限公司, 奇智软件（北京）有限公司 filed Critical 北京奇虎科技有限公司
Publication of WO2017067443A1 publication Critical patent/WO2017067443A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL

Definitions

  • the present invention relates to the field of Internet application technologies, and in particular, to a secure domain name system and a fault processing method thereof.
  • DNS Domain Name System
  • IP address resolution a distributed database on the Internet that maps domain names and IP addresses to each other, enabling users to access the Internet more easily without having to remember the number of IPs that can be directly read by the machine. string.
  • the process of obtaining the IP address corresponding to the host name by the host name is called domain name resolution or host name resolution.
  • the general structure of an Internet host domain name is: host name, third-level domain name, second-level domain name, top-level domain name.
  • the Internet's top-level domain name is registered and managed by the Internet Network Association domain name registration query committee responsible for network address allocation. It also assigns a unique IP address to each host on the Internet.
  • FIG. 1 is a flowchart of a domain name resolution of a DNS in the prior art, and an analysis process of accessing the NetEase portal address www.163.com is taken as an example. The process is:
  • Step 1 The user's computer (or client) sends a request to resolve the www.163.com to the local DNS server set up on its system.
  • the so-called local DNS server refers to a DNS service IP address, which can be obtained automatically from the operator or manually.
  • Step 2 The local DNS server will check whether there is a cache of the domain name in its own space. If not, it will send a domain name resolution request of www.163.com to the root domain server.
  • Step 3 After receiving the resolution request of the local DNS server for the domain name, the root domain server analyzes the requested domain name and returns the IP address of the server of the domain name node of the local DNS server.com.
  • Step 4 After receiving the IP address of the server of the top-level domain of the .com, the local DNS server sends a request for parsing the www.163.com to the top-level domain server of the .com.
  • Step 5 After receiving the resolution request for www.163.com, the .com top-level domain server returns to the local DNS server the IP address of the DNS server of the secondary domain 163.
  • step 6 the local DNS server continues to initiate a resolution request for www.163.com to the DNS server of the secondary domain 163.
  • Step 7,163 The management server of this domain manages all subdomains under 163.com. Its domain name space has the subdomain of www, and its corresponding IP address is 111.1.53.220, so the DNS server of the 163.com domain will return the IP address 111.1.53.220 corresponding to www.163.com to the local DNS server.
  • Step 8 After receiving the parsing result of the domain server 163.com about www.163.com, the local DNS server returns the corresponding IP address 111.1.53.220 to the user, and the result is retained for a period of time for other users to query. .
  • Step 9 After obtaining the IP address 111.1.53.220 corresponding to the domain name of www.163.com, the user computer starts to request the content of the webpage to the IP address 111.1.53.220. At this point, a complete request resolution process for DNS ends.
  • the present invention has been made in order to provide a secure domain name system that overcomes the above problems or at least partially solves the above problems, and a method for troubleshooting based on a secure domain name system.
  • a secure domain name system comprising:
  • a first node configured to provide a domain name resolution service for a DNS request initiated by the client
  • a second node which is a proxy node of the first node, is adapted to request the third node to respond to the DNS request when the first node has a DNS resolution fault;
  • the authorization information database is adapted to store all DNS requests and corresponding authorization information of the designated area;
  • the third node is adapted to receive a DNS request from the second node, invoke corresponding authorization information in the authorization information database, and respond to the DNS request.
  • a method for troubleshooting based on a secure domain name system comprising:
  • the second node that is the proxy node of the first node is started, and the second node requests the third node to respond to the DNS request, where the first node pair
  • the DNS request initiated by the client provides a domain name resolution service
  • the authorization information database stores all DNS requests of the designated area and corresponding authorization information.
  • a computer program comprising computer readable code, when said computer readable code is run on a computing device, causing said computing device to perform security based on said The method of troubleshooting the domain name system.
  • a computer readable medium storing the above computer program is provided.
  • the first node in a normal state, can provide a domain name resolution service to a DNS request initiated by the client, and when the first node has a DNS resolution failure, the second node in the system acts as a proxy node.
  • the node requests the third node to answer the DNS request, and the third node invokes the corresponding authorization information in the authorization information database to respond to the DNS request.
  • all the DNS requests and corresponding authorization information in the specified area are stored in the authorization information database, so that The third node can have enough information resources to respond to the DNS request.
  • the second node in the secure domain name system serves as a proxy node of the first node.
  • the third node When the first node has a DNS resolution failure, the third node requests a response to the DNS request, so that the third node can directly provide the domain name.
  • the service is resolved, but when the first node has a DNS resolution fault, the DNS request forwarded by the second node is responded, thereby ensuring the responsiveness and speed of the third node when providing the domain name resolution service, and improving the security of the domain name resolution. And stability.
  • FIG. 1 shows a domain name resolution process of a DNS in the prior art
  • FIG. 2 is a schematic structural diagram of a secure domain name system according to an embodiment of the present invention.
  • FIG. 3 is a schematic structural diagram of a secure domain name system according to another embodiment of the present invention.
  • FIG. 4 shows a flow chart of a method for fault handling based on a secure domain name system in accordance with one embodiment of the present invention
  • FIG. 5 is a flow chart showing a method for performing fault processing based on a secure domain name system according to another embodiment of the present invention.
  • Figure 6 is a schematic block diagram of a computing device for performing a method for fault handling based on a secure domain name system in accordance with the present invention
  • Fig. 7 schematically shows a storage unit for holding or carrying program code implementing a method for fault handling based on a secure domain name system according to the present invention.
  • FIG. 2 shows a schematic structural diagram of a secure domain name system according to an embodiment of the present invention.
  • the secure domain name system 200 can include at least:
  • the first node 210 is adapted to provide a domain name resolution service for the DNS request initiated by the client;
  • the second node 220 which is a proxy node of the first node 210, is coupled to the first node 210 and is adapted to When the first node has a DNS resolution failure, requesting the third node 230 to answer the DNS request;
  • the authorization information database 240 is coupled to the third node 230 and is adapted to store all DNS requests and corresponding authorization information of the designated area;
  • the third node 230 is adapted to receive a DNS request from the second node 220, invoke corresponding authorization information in the authorization information database 240, and respond to the DNS request.
  • the first node in a normal state, can provide a domain name resolution service to a DNS request initiated by the client, and when the first node has a DNS resolution failure, the second node in the system acts as a proxy node.
  • the node requests the third node to answer the DNS request, and the third node invokes the corresponding authorization information in the authorization information database to respond to the DNS request.
  • all the DNS requests and corresponding authorization information in the specified area are stored in the authorization information database, so that the third node can have sufficient information resources to respond to the DNS request.
  • the second node in the secure domain name system serves as a proxy node of the first node.
  • the third node When the first node has a DNS resolution failure, the third node requests a response to the DNS request, so that the third node can directly provide the domain name.
  • the service is resolved, but when the first node has a DNS resolution fault, the DNS request forwarded by the second node is responded, thereby ensuring the responsiveness and speed of the third node when providing the domain name resolution service, and improving the security of the domain name resolution. And stability.
  • each node mentioned in the embodiment of the present invention may be a single server, or a server cluster composed of multiple servers, or a cluster group composed of multiple server clusters.
  • the first node 210 mentioned above may provide a domain name resolution service to the client-initiated DNS request, and thus the first node 210 may be the local DNS server, the root domain server (ie, the root node) shown in FIG.
  • the distribution is: the main root domain server (A), the United States, set up in Virginia, the secondary root domain server (B to M), the United States, 9 in Sweden, the Netherlands, and Japan.
  • the domain name system is the basic service of the Internet, and the root domain server is the basis of the entire domain name system.
  • the root domain server that controls the domain name resolution controls all the corresponding domain names and IP addresses. If the country where the root domain server suddenly blocks the domain name of a certain region, the website pointed to by these domain names will disappear from the Internet.
  • the second node 220 requests the third node 230 to answer the DNS request, and the third node 230 calls the authorization information database 240 to provide domain name resolution.
  • each level node in the hierarchical space stores the authorization information record of the relevant node of the next level.
  • the local DNS server accesses all nodes in the domain name space. Therefore, the authorization records that store the information of these nodes can be backed up, and a backup domain name hierarchy space is formed according to the mutual relationship of the records.
  • Information database 240 In addition, taking China as an example, because the root node and the authorization server of the international domain name are all abroad, it is possible to capture packets at the backbone of the Chinese backbone network, extract and analyze the DNS resolution records, and store the corresponding authorization information records.
  • the authorization information database 240 is stored in a distributed manner, that is, the authorization information database 240 corresponds to each level of the domain name space, and the data information is updated in real time. Therefore, the authorization information database 240 may be a mirror image of the Internet domain name hierarchy. . Since the authorization information database 240 has all the authorization information records, the domain name resolution service can be replaced by the server of this level when the root node or even the domain name node server of any level fails.
  • some commonly used DNS resolving records with a large amount of access, or DNS resolution records of some important domain names may be separately stored in a specified location of the authorization information database 240, so that When the third node 230 queries the authorization information database 240, it can perform a quick reply to implement an emergency response. That is, in the authorization information database 240, the authorization information may include a DNS resolution record in which the storage access amount exceeds the access threshold, and/or a DNS resolution record of the important domain name.
  • the third node 230 may adopt a distributed deployment to respond to the DNS request by means of BGP (Border Gateway Protocol, a routing protocol used to connect to an independent system on the Internet).
  • BGP Border Gateway Protocol, a routing protocol used to connect to an independent system on the Internet.
  • the BGP mode can be anycast mode.
  • the second node 220 can be at the exit of the critical area of the designated area of the backbone network.
  • the monitoring of the DNS data message is performed to determine whether the first node 210 has a DNS resolution failure. Specifically, taking China as an example, it is possible to monitor DNS data packets at the overseas exits in China, and monitor the correctness of the DNS resolution records.
  • the export is performed. The corresponding request packet can be transmitted to the second node 220 for response, preventing the data from continuing to the foreign server and causing tampering.
  • the result of the root domain name resolution is generally not easily modified. If the currently returned parsing result does not match the pre-stored result in the history record, it proves that the parsing is falsified, and an alarm or manual intervention is required. In addition, if the authorization of a top-level domain does not work properly or the returned one is "ServFail", it can be directly judged that the analysis result is wrong.
  • a processing method in which the DNS analysis result is incorrect is: after the analytic result is falsified, the judgment is performed according to the alarm information, and the interface operation is clicked, the system automatically switches to the second node 220 in batches, and the second node 220 forwards to the third node. 230 performs DNS resolution.
  • the foregoing alarm information may be determined by combining the pre-collected illegal DNS IP and the legal DNS IP address whitelist list address.
  • the pre-collected malicious DNS IP address list may be a set of illegal DNS IP addresses pre-collected by the security vendor, and the pre-collection
  • the list of malicious DNS IP addresses can be a list of malicious DNS IP addresses pre-collected in the client database, or it can be a list of malicious DNS IP addresses downloaded from the website to the client database.
  • the pre-set legal DNS IP address whitelist can be pre-stored in the client database or downloaded from a website server (such as a cloud security server).
  • the main security levels include “danger”, “warning” and “security”, among them, A security level of “dangerous” indicates the greatest threat to the user, followed by “warning” and “weak”.
  • the prompts on the interface can also be performed accordingly.
  • the third node 230 mentioned above only responds to the DNS request from the second node 220, thereby being able to ensure the responsiveness and speed of the third node 230 when providing the domain name resolution service.
  • the data link of the third node 230 is independent of the data link of the first node 210.
  • the first node 210 and the third node 230 can be placed in different equipment rooms, and guaranteed. The link data is consistent.
  • the access authority control can be set by the second node 220 to block the DNS attack data, thereby further improving the security and stability of the DNS resolution, and improving the defense against DNS attacks. That is, the second node 220 filters the abnormality request in the DNS request, and further requests the third node 230 to respond to the filtered DNS request. Since each network data packet has a signature code, and each signature code is unique, the attribute of the DNS request of the network data packet can be judged according to the signature code, and the DNS attack operation disguised as a normal data packet can be seen. According to the following steps, it is determined whether the network packet carries the DNS attack behavior:
  • Step A calculating a signature of the network data packet
  • Step B determining whether the feature code is a signature code of the DNS attack behavior, and if so, executing step C, and if not, performing step D;
  • Step C determining that the network data packet carries a DNS attack behavior
  • Step D Determine that the network packet does not carry the DNS attack behavior.
  • the feature code of the known DNS attack behavior may be pre-stored.
  • the feature code calculated in step A is matched with the pre-stored feature code. If the match is successful, the DNS attack behavior is performed, and vice versa. No.
  • the feature code here may be determined according to domain name information such as IP or domain name, for example, calculating the number of network packets received from the same IP within a specified time to obtain a signature, and/or calculating a network packet received from the same domain within a specified time. number. If the number of network packets received from the same IP or the same domain name in one second is much larger than the number of packets that should be received, it proves that the IP address or domain name has been turned into an attack source. This is also the basic principle of the IP rate limiting policy and the domain name rate limiting policy. The IP address or domain name that proves to be the source of the attack, and then receive the network packet from this source, can be directly discarded or filtered to avoid being attacked by it, improving system security performance and processing efficiency.
  • domain name information such as IP or domain name
  • the secure domain name system 200 shown in FIG. 2 above may further include:
  • the recursive server 250 coupled to the first node 210 and the second node 220, is adapted to receive a client initiated DNS request and request a response to the first node and/or the second node.
  • the second node 220 refuses to answer the DNS request. Further, when the first node 210 can provide a normal domain name resolution service, the second node 220 rejects When the DNS request is answered, the recursive server 250 requests the first node 210 to answer the DNS request.
  • the second node 220 is further adapted to: when the first node 210 has a DNS resolution fault, query whether the node caches the authorization information corresponding to the DNS request, if the node does not cache the DNS request correspondingly The authorization information is then requested from the third node 230 to answer the DNS request. On the other hand, if the node caches the authorization information corresponding to the DNS request, it directly responds to the DNS request by using the authorization information corresponding to the DNS request cached by the node.
  • the embodiment of the present invention further provides a method for performing fault processing by using the secure domain name system provided by any of the foregoing optional embodiments or a combination thereof.
  • 4 shows a flow chart of a method for fault handling based on a secure domain name system in accordance with one embodiment of the present invention. Referring to FIG. 4, the method may at least include steps S402 to S404:
  • Step S402 when the first node has a DNS resolution fault, start a second node that is the proxy node of the first node, and the second node requests the third node to answer the DNS request, where the first node initiates the DNS to the client.
  • Step S404 The third node invokes the corresponding authorization information in the authorization information database to respond to the DNS request, wherein the authorization information database stores all the DNS requests of the designated area and the corresponding authorization information.
  • the first node in a normal state, can provide a domain name resolution service to the DNS request initiated by the client, and when the first node has a DNS resolution failure, the second node that is the proxy node of the first node.
  • the third node requests a response DNS request, and the third node invokes the corresponding authorization information in the authorization information database to respond to the DNS request. Since all the DNS requests and corresponding authorization information in the specified area are stored in the authorization information database, the third node can have sufficient information resources to respond to the DNS request.
  • the second node in the embodiment of the present invention serves as a proxy node of the first node, and when the first node has a DNS resolution fault, requests the third node to respond to the DNS request, so that the third node can not directly provide the external request.
  • the domain name resolution service when the first node has a DNS resolution failure, responds to the DNS request forwarded by the second node, thereby ensuring the response capability and speed of the third node when providing the domain name resolution service, and improving the security of the domain name resolution. Sex and stability.
  • each node mentioned in the embodiment of the present invention may be a single server, or a server cluster composed of multiple servers, or a cluster group composed of multiple server clusters.
  • the first node mentioned in step S402 can provide a domain name resolution service for the DNS request initiated by the client, and thus the first node can be the local DNS server, the root domain server (ie, the root node) shown in FIG.
  • the domain server ie, the top-level domain node
  • other authorization server ie, other authorized nodes
  • the second node When the first node has a DNS resolution fault, the second node requests the third node to answer the DNS request, and the third node invokes the authorization information database to provide domain name resolution.
  • each level node in the hierarchical space stores the next level of correlation.
  • the authorization information record of the node Due to the hierarchical relationship and distributed structure of the DNS (Domain Name System), each level node in the hierarchical space stores the next level of correlation.
  • the authorization information record of the node During the process of layer-by-layer resolution, the local DNS server accesses all nodes in the domain name space. Therefore, the authorization records that store the information of these nodes can be backed up, and a backup domain name hierarchy space is formed according to the mutual relationship of the records. Information database.
  • taking China as an example because the root node and the authorization server of the international domain name are all abroad, it is possible to capture packets at the backbone of the Chinese backbone network, extract and analyze the DNS resolution records, and store the corresponding authorization information records.
  • the authorization information database is stored in a distributed manner, that is, the authorization information database corresponds to each level of the domain name space, and the data information is updated in real time. Therefore, the authorization information database may be a mirror image of the Internet domain name hierarchy. Since the authorization information database has all the authorization information records, the domain name resolution service can be replaced by the server of this level when the root node or even the domain name node server of any level fails.
  • some commonly used DNS resolving records with a large amount of access may be separately stored in a specified location of the authorization information database, so that When the three nodes query into the authorization information database, they can quickly reply and implement an emergency response. That is, in the authorization information database, the authorization information may include a DNS resolution record in which the storage access amount exceeds the access threshold, and/or a DNS resolution record of the important domain name.
  • the third node may adopt a distributed deployment and respond to the DNS request by means of BGP (Border Gateway Protocol, a routing protocol used to connect to an independent system on the Internet).
  • BGP Border Gateway Protocol, a routing protocol used to connect to an independent system on the Internet.
  • the BGP mode can be anycast mode.
  • the second node may perform a DNS data report on the backbone network to the critical area exit of the designated area. Listening to the file to determine if the first node has a DNS resolution failure. Specifically, taking China as an example, it is possible to monitor DNS data packets at the exits of China, and monitor the correctness of DNS resolution records. Once the first node and other uncontrollable domain name resolution abnormalities are found, at the exit. The corresponding request packet can be transmitted to the second node for answering, preventing the data from continuing to the foreign server and causing tampering.
  • the third node mentioned above only responds to the DNS request from the second node, thereby being able to ensure the responsiveness and speed of the third node when providing the domain name resolution service.
  • the data link of the third node is independent of the data link of the first node, for example, the first node and the third node may be placed in different equipment rooms, and the link data is consistent. .
  • the access authority control may be set by the second node to block the DNS attack data, thereby further improving the security and stability of the DNS resolution, and improving the defense against DNS attacks. That is, the second node filters the abnormal request in the DNS request, and then requests the third node to respond to the filtered DNS request.
  • the judgment of the attack data of the DNS can be referred to the foregoing introduction, and details are not described herein again.
  • the client initiates a DNS request by the recursive server and requests the first node and/or the second node to answer the DNS request. If the first node can provide normal domain name resolution service The second node refuses to answer the DNS request.
  • the recursive server requests the second node to answer the DNS request, and the second node refuses to answer the DNS request (because the first node can provide a normal domain name resolution service, and the second node refuses to answer the DNS request), the recursive server is The DNS protocol re-initiates the secondary query and requests the first node to answer the DNS request.
  • the second node when the first node has a DNS resolution fault, the second node queries whether the node caches the authorization information corresponding to the DNS request, and if the node does not cache the authorization information corresponding to the DNS request, The third node requests to answer the DNS request. On the other hand, if the node caches the authorization information corresponding to the DNS request, it directly responds to the DNS request by using the authorization information corresponding to the DNS request cached by the node.
  • FIG. 5 illustrates a flow chart of a method for fault handling based on a secure domain name system in accordance with another embodiment of the present invention.
  • the first node is an authorization server (or an authoritative server), and the domain name resolution service is provided for the DNS request initiated by the client;
  • the second node is a super protection node (ie, NS-IP-safe), which is the first
  • the proxy node of a node, the IPs of the first node and the second node are all publicly disclosed;
  • the third node is a hidden node (ie, DNS-IP-backup), and only responds to the DNS request from the second node.
  • the first node and the third node are located in different equipment rooms, and the link data is consistent.
  • the method may at least include steps S502 to S512.
  • Step S502 receiving, by the recursive server, a DNS request initiated by the client, and requesting the first node to answer the DNS request.
  • Step S504 determining whether the first node has a DNS resolution fault, and if yes, proceeding to step S506; if not, proceeding to step S508.
  • Step S506 starting the second node as the proxy node of the first node, and proceeding to step S510.
  • Step S508 the first node answers the DNS request.
  • Step S510 The second node responds to the DNS request, filters the abnormal request in the DNS request, and further requests the third node to respond to the filtered DNS request.
  • the second node sets the access permission control to block the DNS attack data, thereby further improving the security and stability of the DNS resolution, and improving the defense against DNS attacks.
  • the judgment of the attack data of the DNS can be referred to the foregoing introduction, and details are not described herein again.
  • Step S512 using the third node to invoke the corresponding authorization information in the authorization information database to respond to the DNS request.
  • step S502 if the recursive server requests a response from the second node DNS request, and in step S504, it is determined that the first node can provide a normal domain name resolution service, and the second node refuses to answer the DNS request, and the recursive server re-initiates the secondary query according to the DNS protocol, and requests the first node to respond to the DNS request.
  • the embodiments of the present invention can achieve the following beneficial effects:
  • the first node in a normal state, can provide a domain name resolution service to a DNS request initiated by the client, and when the first node has a DNS resolution failure, the second node in the system acts as a proxy node.
  • the node requests the third node to answer the DNS request, and the third node invokes the corresponding authorization information in the authorization information database to respond to the DNS request.
  • all the DNS requests and corresponding authorization information in the specified area are stored in the authorization information database, so that the third node can have sufficient information resources to respond to the DNS request.
  • the second node in the secure domain name system serves as a proxy node of the first node.
  • the third node When the first node has a DNS resolution failure, the third node requests a response to the DNS request, so that the third node can directly provide the domain name.
  • the service is resolved, but when the first node has a DNS resolution fault, the DNS request forwarded by the second node is responded, thereby ensuring the responsiveness and speed of the third node when providing the domain name resolution service, and improving the security of the domain name resolution. And stability.
  • modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment.
  • the modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components.
  • any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and any methods so disclosed, or All processes or units of the device are combined.
  • Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor may be used in practice to implement some or all of the functionality of some or all of the components of the secure domain name system in accordance with embodiments of the present invention.
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
  • Figure 6 illustrates a computing device that can implement a method of fault handling based on a secure domain name system.
  • the computing device conventionally includes a processor 610 and a computer program product or computer readable medium in the form of a memory 620.
  • the memory 620 may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM, a hard disk, or a ROM.
  • Memory 620 has a memory space 630 for program code 631 for performing any of the method steps described above.
  • storage space 630 for program code may include various program code 631 for implementing various steps in the above methods, respectively.
  • the program code can be read from or written to one or more computer program products.
  • Such computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks.
  • Such a computer program product is typically a portable or fixed storage unit as described with reference to FIG.
  • the storage unit may have storage segments, storage spaces, and the like that are similarly arranged to memory 620 in the computing device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit includes computer readable code 631', ie, code readable by a processor, such as 610, that when executed by a computing device causes the computing device to perform each of the methods described above step.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种安全域名系统及其故障处理方法。该安全域名系统包括：第一节点，适于对客户端发起的DNS请求提供域名解析服务；作为所述第一节点的代理节点的第二节点，适于当所述第一节点出现DNS解析故障时，向第三节点请求应答所述DNS请求；授权信息数据库，适于存储指定区域的所有DNS请求及对应的授权信息；第三节点，适于接收来自所述第二节点的DNS请求，调用所述授权信息数据库中相应的授权信息，对所述DNS请求进行应答。本发明实施例中，第三节点仅对第二节点转发的DNS请求进行应答，从而保证了第三节点在提供域名解析服务时的响应能力和速度，提高域名解析的安全性和稳定性。

Description

一种安全域名系统及其故障处理方法 技术领域
本发明涉及互联网应用技术领域，特别涉及一种安全域名系统及其故障处理方法。
背景技术
DNS(Domain Name System，域名系统)，Internet(因特网)上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便地访问互联网，而不用去记住能够被机器直接读的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析或主机名解析。
Internet主机域名的一般结构为：主机名.三级域名.二级域名.顶级域名。Internet的顶级域名由Internet网络协会域名注册查询负责网络地址分配的委员会进行登记和管理，它还为Internet的每一台主机分配唯一的IP地址。
图1是现有技术中DNS的一个域名解析流程图，以访问网易门户地址www.163.com的解析过程为例进行介绍。其流程为：
步骤1，用户电脑(或客户端)向其系统上设置的本地DNS服务器发送解析www.163.com的请求。所谓本地DNS服务器是指一个DNS服务IP地址，可以是从运营商自动获取的，也可以是手动设置的。
步骤2，本地DNS服务器会在自己的空间里查看是否有这个域名的缓存，如果没有，就会向根域服务器发送www.163.com的域名解析请求。
步骤3，根域服务器接收到本地DNS服务器关于域名的解析请求后，分析请求的域名，返回给本地DNS服务器.com这个域名节点的服务器的IP地址。
步骤4，本地DNS服务器在接到.com顶级域的服务器IP地址后，向.com顶级域服务器发出查询www.163.com的解析请求。
步骤5，.com顶级域服务器在接收到关于www.163.com的解析请求后，返回给本地DNS服务器关于163这个二级域的DNS服务器的IP地址。
步骤6，本地DNS服务器继续向163这个二级域的DNS服务器发起关于www.163.com的解析请求。
步骤7，163这个域的管理服务器管理163.com下的所有的子域名。它的域名空间中有www这个子域名，其对应的IP地址为111.1.53.220，因此163.com域的DNS服务器会返回www.163.com对应的IP地址111.1.53.220给本地DNS服务器。
步骤8，本地DNS服务器接收到163.com这个域服务器关于www.163.com解析结果后，返回给用户对应的IP地址111.1.53.220，同时会将这个结果保留一段时间，以备其他用户的查询。
步骤9，用户电脑在获得www.163.com域名对应的IP地址111.1.53.220后，就开始向111.1.53.220这个IP请求网页内容。到此，DNS的一个完整请求解析流程结束。
然而，当根域服务器、顶级域服务器或者其他授权服务器发生故障不能提供正常的域名解析服务时，如何进行域名解析成为亟待解决的技术问题。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的安全域名系统以及基于安全域名系统进行故障处理的方法。
根据本发明的一方面，提供了一种安全域名系统，包括：
第一节点，适于对客户端发起的DNS请求提供域名解析服务；
作为所述第一节点的代理节点的第二节点，适于当所述第一节点出现DNS解析故障时，向第三节点请求应答所述DNS请求；
授权信息数据库，适于存储指定区域的所有DNS请求及对应的授权信息；
第三节点，适于接收来自所述第二节点的DNS请求，调用所述授权信息数据库中相应的授权信息，对所述DNS请求进行应答。
根据本发明的另一方面，还提供了一种基于安全域名系统进行故障处理的方法，包括：
当第一节点出现DNS解析故障时，启动作为所述第一节点的代理节点的第二节点，由所述第二节点向第三节点请求应答所述DNS请求，其中，所述第一节点对客户端发起的DNS请求提供域名解析服务；
利用所述第三节点调用授权信息数据库中相应的授权信息，对所述DNS请求进行应答，其中，所述授权信息数据库中存储了指定区域的所有DNS请求及对应的授权信息。
根据本发明的又一方面，提供了一种计算机程序，其包括计算机可读代码，当所述计算机可读代码在计算设备上运行时，导致所述计算设备执行根据上文所述的基于安全域名系统进行故障处理的方法。
根据本发明的再一方面，提供了一种计算机可读介质，其中存储了上述的计算机程序。
本发明的有益效果包括：
本发明实施例提供的安全域名系统，在正常状态下，第一节点能够对客户端发起的DNS请求提供域名解析服务，而当第一节点出现DNS解析故障时，系统中作为代理节点的第二节点便向第三节点请求应答DNS请求，由第三节点调用授权信息数据库中相应的授权信息，对DNS请求进行应答。本发明实施例提供的安全域名系统中，授权信息数据库中存储了指定区域内的所有DNS请求及对应的授权信息，这样 第三节点能够有足够的信息资源对DNS请求进行应答。进一步，安全域名系统中的第二节点，其作为第一节点的代理节点，当第一节点出现DNS解析故障时，向第三节点请求应答DNS请求，从而使得第三节点能够不直接对外提供域名解析服务，而是当第一节点出现DNS解析故障时，对第二节点转发的DNS请求进行应答，从而保证了第三节点在提供域名解析服务时的响应能力和速度，提高域名解析的安全性和稳定性。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了现有技术中DNS的一个域名解析流程；
图2示出了根据本发明一个实施例的安全域名系统的结构示意图；
图3示出了根据本发明另一个实施例的安全域名系统的结构示意图；
图4示出了根据本发明一个实施例的基于安全域名系统进行故障处理的方法的流程图；
图5示出了根据本发明另一个实施例的基于安全域名系统进行故障处理的方法的流程图；
图6示意性地示出了用于执行根据本发明的基于安全域名系统进行故障处理的方法的计算设备的框图；以及
图7示意性地示出了用于保持或者携带实现根据本发明的基于安全域名系统进行故障处理的方法的程序代码的存储单元。
具体实施方式
下面结合附图和具体的实施方式对本发明作进一步的描述。
为解决上述技术问题，本发明实施例提供了一种安全域名系统，用于在提供域名解析服务的节点出现DNS解析故障时能够进行故障类的容灾处理。图2示出了根据本发明一个实施例的安全域名系统的结构示意图。参见图2，该安全域名系统200至少可以包括：
第一节点210，适于对客户端发起的DNS请求提供域名解析服务；
作为第一节点210的代理节点的第二节点220，与第一节点210相耦合，适于 当第一节点出现DNS解析故障时，向第三节点230请求应答DNS请求；
授权信息数据库240，与第三节点230相耦合，适于存储指定区域的所有DNS请求及对应的授权信息；
第三节点230，适于接收来自第二节点220的DNS请求，调用授权信息数据库240中相应的授权信息，对DNS请求进行应答。
本发明实施例提供的安全域名系统，在正常状态下，第一节点能够对客户端发起的DNS请求提供域名解析服务，而当第一节点出现DNS解析故障时，系统中作为代理节点的第二节点便向第三节点请求应答DNS请求，由第三节点调用授权信息数据库中相应的授权信息，对DNS请求进行应答。本发明实施例提供的安全域名系统中，授权信息数据库中存储了指定区域内的所有DNS请求及对应的授权信息，这样第三节点能够有足够的信息资源对DNS请求进行应答。进一步，安全域名系统中的第二节点，其作为第一节点的代理节点，当第一节点出现DNS解析故障时，向第三节点请求应答DNS请求，从而使得第三节点能够不直接对外提供域名解析服务，而是当第一节点出现DNS解析故障时，对第二节点转发的DNS请求进行应答，从而保证了第三节点在提供域名解析服务时的响应能力和速度，提高域名解析的安全性和稳定性。
需要说明的是，本发明实施例提及的各节点可以是单台服务器，或者是多台服务器组成的服务器集群，或者是多个服务器集群组成的集群组。
上文提及的第一节点210，可以对客户端发起的DNS请求提供域名解析服务，因而第一节点210可以是图1中所示的本地DNS服务器、根域服务器(即，根节点)、顶级域服务器(即，顶级域节点)或者其他授权服务器(即，其他授权节点)，本发明在此并不限制。
目前全球仅有13台根域服务器，分布是：主根域服务器(A)美国1个，设置在弗吉尼亚州，辅根域服务器(B至M)美国9个，瑞典、荷兰、日本各1个。由上述数据可知，根域服务器(即，根节点)数量较少，且主要设置在部分区域，那么其他区域在域名分析的过程中缺乏主动性和风险控制功能。域名系统是互联网的基础服务，而根域服务器更是整个域名系统的基础，控制了域名解析的根域服务器，也就控制了相应的所有域名和IP地址。若存在根域服务器的国家突然屏蔽某一地区的域名，那么这些域名所指向的网站就会从互联网上中消失。
当第一节点210出现DNS解析故障时，第二节点220向第三节点230请求应答DNS请求，由第三节点230调用授权信息数据库240提供域名解析。在本发明实施例中，由于DNS(域名系统)的层次关系和分布式结构，层次空间中每一级节点都存储着下一级的相关节点的授权信息记录。本地DNS服务器在逐层解析的过程中，会访问到域名空间所有层次的节点，因此可以将保存这些节点信息的授权记录备份下来，根据记录的相互关系，组成一个备份的域名层次空间，即授权信息数据库240。 此外，以中国为例，因为根节点和国际域名的授权服务器都在国外，所以可以在中国骨干网出口进行抓包，将DNS解析记录进行提取分析，存储对应的授权信息记录。
进一步地，授权信息数据库240采用分布式的方式进行存储，即，授权信息数据库240对应域名空间的每一级，并且数据信息是实时更新，因此，授权信息数据库240可以是一个互联网域名层次的镜像。由于授权信息数据库240拥有全部的授权信息记录，因此可以在根节点甚至是任何一级的域名节点服务器出现故障时，都可以替代这一级的服务器进行域名解析服务。
在本发明一实施例中，为了加快解析速度，某些常用的、访问量比较大的DNS解析记录，或者某些重要域名的DNS解析记录，可以单独存储在授权信息数据库240的指定位置，以便第三节点230到授权信息数据库240中查询时能够进行快速回复，实现紧急应答。即，在授权信息数据库240中，授权信息可以包括存储访问量超过访问阈值的DNS解析记录，和/或，重要域名的DNS解析记录。
在本发明的另一实施例中，第三节点230可以采用分布式部署，通过BGP(Border Gateway Protocol，边界网关协议，用来连接Internet上独立系统的路由选择协议)方式应答DNS请求。可选地，BGP方式可以为Anycast(任播)模式。
当第一节点210为根节点或国际域名的授权节点时，为保证第二节点220能够及时获知第一节点210出现解析故障，则第二节点220可以在骨干网对指定区域的临界区域出口处进行DNS数据报文的监听，以确定第一节点210是否出现DNS解析故障。具体的，以中国为例，可以在中国对境外的出口处监听DNS数据报文，对DNS解析记录的正确性进行监控，一旦发现第一节点210和其他不可控的域名解析异常情况，在出口处可以将对应的请求包传送到第二节点220进行应答，防止数据继续到国外服务器而导致被篡改。
根域名解析的结果一般是不会轻易修改，如果当前返回的解析结果与历史记录中预存的结果不匹配，则证明解析出现篡改，需要告警或采取人工干预。另外，如果当某个顶级域的授权无法正常工作或者返回的都为“ServFail”也直接可以判断为解析结果错误。DNS的解析结果不正确的一种处理方法为：解析结果出现篡改后，根据告警信息进行判断，对界面操作点击，系统自动批量切换至第二节点220，由第二节点220转发至第三节点230进行DNS解析。
以上告警信息可以结合预先采集的非法DNS IP和合法的DNS IP地址白名单列表地址确定，例如预先收集的恶意DNS IP地址列表可以是由安全厂商预先收集的一组非法DNS IP地址，该预先收集的恶意DNS IP地址列表可以为客户端数据库中预先收集的恶意DNS IP地址列表，或者也可以为从网站上下载至客户端数据库中的恶意DNS IP地址列表。该预先设置的合法的DNS IP地址白名单列表可以预先存储在客户端数据库中，也可以从网站的服务器(如云安全服务器)上下载。
在具体实现时，主要的安全等级包括“危险”、“警告”和“安全”，其中， 安全等级为“危险”的表示对用户的威胁最大，为“警告”的次之，为“安全”的最弱。界面上提示也可以据此进行。
进一步地，上文提及的第三节点230，仅对来自第二节点220的DNS请求进行应答，从而能够保证第三节点230在提供域名解析服务时的响应能力和速度。在本发明的另一实施例中，第三节点230的数据链路独立于第一节点210的数据链路，例如，可以将第一节点210和第三节点230放置到不同的机房，并保证链路数据一致。
在本发明的又一实施例中，可以由第二节点220设置访问权限控制，屏蔽DNS的攻击数据，从而进一步提高DNS解析的安全性及稳定性，并提高防御DNS攻击能力。即，由第二节点220对DNS请求中的异常请求进行过滤，进而向第三节点230请求应答过滤后的DNS请求。由于每个网络数据包都具备一个特征码，且每个特征码是独一无二的，因此，可以根据特征码判断网络数据包的DNS请求的属性，识破伪装成正常数据包的DNS攻击操作。现根据如下步骤判断所述网络数据包中是否携带有DNS攻击行为：
步骤A、计算网络数据包的特征码；
步骤B、判断特征码是否是DNS攻击行为的特征码，若是，执行步骤C，若否，执行步骤D；
步骤C、确定网络数据包中携带有DNS攻击行为；
步骤D、确定网络数据包中未携带有DNS攻击行为。
其中，可以预先存储已知DNS攻击行为的特征码，当需要校验时，将步骤A中计算出的特征码与预先存储的特征码进行匹配，若匹配成功，则是DNS攻击行为，反之则不是。
这里的特征码可以根据IP或域名等域名信息确定，例如，计算指定时间内接收的来自同一IP的网络数据包数得到特征码，和/或计算指定时间内接收的来自同一域名的网络数据包数。若1秒内从同一IP或同一域名接收的网络数据包数远远大于应该接收的包数，就证明该IP地址或域名已被变成攻击源。这也是IP限速策略、域名限速策略的基本原理。被证明变为攻击源的IP地址或域名，之后再接收到来自这一源头的网络数据包，可以直接舍弃或过滤掉，避免被其攻击，提高系统安全性能及处理效率。
在本发明的再一实施例中，如图3所示，上文图2展示的安全域名系统200还可以包括：
递归服务器250，与第一节点210和第二节点220相耦合，适于接收客户端发起的DNS请求，并向第一节点和/或第二节点请求应答DNS请求。
若第一节点210能够提供正常的域名解析服务，则第二节点220拒绝应答DNS请求。进一步地，当第一节点210能够提供正常的域名解析服务、第二节点220拒 绝应答DNS请求时，递归服务器250向第一节点210请求应答DNS请求。
在本发明的又一实施例中，第二节点220还适于：当第一节点210出现DNS解析故障时，查询本节点是否缓存了DNS请求对应的授权信息，若本节点未缓存DNS请求对应的授权信息，则向第三节点230请求应答DNS请求。反之，若本节点缓存了DNS请求对应的授权信息，则直接利用本节点缓存的DNS请求对应的授权信息，对DNS请求进行应答。
基于同一发明构思，本发明实施例还提供了一种应用上述任意可选实施例或其组合所提供的安全域名系统进行故障处理的方法。图4示出了根据本发明一个实施例的基于安全域名系统进行故障处理的方法的流程图。参见图4，该方法至少可以包括步骤S402至步骤S404：
步骤S402，当第一节点出现DNS解析故障时，启动作为第一节点的代理节点的第二节点，由第二节点向第三节点请求应答DNS请求，其中，第一节点对客户端发起的DNS请求提供域名解析服务；
步骤S404，利用第三节点调用授权信息数据库中相应的授权信息，对DNS请求进行应答，其中，授权信息数据库中存储了指定区域的所有DNS请求及对应的授权信息。
本发明实施例中，在正常状态下，第一节点能够对客户端发起的DNS请求提供域名解析服务，而当第一节点出现DNS解析故障时，作为第一节点的代理节点的第二节点便向第三节点请求应答DNS请求，利用第三节点调用授权信息数据库中相应的授权信息，对DNS请求进行应答。由于授权信息数据库中存储了指定区域内的所有DNS请求及对应的授权信息，这样第三节点能够有足够的信息资源对DNS请求进行应答。进一步，本发明实施例中的第二节点，其作为第一节点的代理节点，当第一节点出现DNS解析故障时，向第三节点请求应答DNS请求，从而使得第三节点能够不直接对外提供域名解析服务，而是当第一节点出现DNS解析故障时，对第二节点转发的DNS请求进行应答，从而保证了第三节点在提供域名解析服务时的响应能力和速度，提高域名解析的安全性和稳定性。
需要说明的是，本发明实施例提及的各节点可以是单台服务器，或者是多台服务器组成的服务器集群，或者是多个服务器集群组成的集群组。
步骤S402中提及的第一节点，可以对客户端发起的DNS请求提供域名解析服务，因而第一节点可以是图1中所示的本地DNS服务器、根域服务器(即，根节点)、顶级域服务器(即，顶级域节点)或者其他授权服务器(即，其他授权节点)，本发明在此并不限制。
当第一节点出现DNS解析故障时，第二节点向第三节点请求应答DNS请求，由第三节点调用授权信息数据库提供域名解析。在本发明实施例中，由于DNS(域名系统)的层次关系和分布式结构，层次空间中每一级节点都存储着下一级的相关 节点的授权信息记录。本地DNS服务器在逐层解析的过程中，会访问到域名空间所有层次的节点，因此可以将保存这些节点信息的授权记录备份下来，根据记录的相互关系，组成一个备份的域名层次空间，即授权信息数据库。此外，以中国为例，因为根节点和国际域名的授权服务器都在国外，所以可以在中国骨干网出口进行抓包，将DNS解析记录进行提取分析，存储对应的授权信息记录。
进一步地，授权信息数据库采用分布式的方式进行存储，即，授权信息数据库对应域名空间的每一级，并且数据信息是实时更新，因此，授权信息数据库可以是一个互联网域名层次的镜像。由于授权信息数据库拥有全部的授权信息记录，因此可以在根节点甚至是任何一级的域名节点服务器出现故障时，都可以替代这一级的服务器进行域名解析服务。
在本发明一实施例中，为了加快解析速度，某些常用的、访问量比较大的DNS解析记录，或者某些重要域名的DNS解析记录，可以单独存储在授权信息数据库的指定位置，以便第三节点到授权信息数据库中查询时能够进行快速回复，实现紧急应答。即，在授权信息数据库中，授权信息可以包括存储访问量超过访问阈值的DNS解析记录，和/或，重要域名的DNS解析记录。
在本发明的另一实施例中，第三节点可以采用分布式部署，通过BGP(Border Gateway Protocol，边界网关协议，用来连接Internet上独立系统的路由选择协议)方式应答DNS请求。可选地，BGP方式可以为Anycast(任播)模式。
当第一节点为根节点或国际域名的授权节点时，为保证第二节点能够及时获知第一节点出现解析故障，则第二节点可以在骨干网对指定区域的临界区域出口处进行DNS数据报文的监听，以确定第一节点是否出现DNS解析故障。具体的，以中国为例，可以在中国对境外的出口处监听DNS数据报文，对DNS解析记录的正确性进行监控，一旦发现第一节点和其他不可控的域名解析异常情况，在出口处可以将对应的请求包传送到第二节点进行应答，防止数据继续到国外服务器而导致被篡改。
进一步地，上文提及的第三节点，仅对来自第二节点的DNS请求进行应答，从而能够保证第三节点在提供域名解析服务时的响应能力和速度。在本发明的另一实施例中，第三节点的数据链路独立于第一节点的数据链路，例如，可以将第一节点和第三节点放置到不同的机房，并保证链路数据一致。
在本发明的又一实施例中，可以由第二节点设置访问权限控制，屏蔽DNS的攻击数据，从而进一步提高DNS解析的安全性及稳定性，并提高防御DNS攻击能力。即，由第二节点对DNS请求中的异常请求进行过滤，进而向第三节点请求应答过滤后的DNS请求。这里关于DNS的攻击数据的判断可参见前文介绍，此处不再赘述。
在本发明的再一实施例中，由递归服务器接收客户端发起的DNS请求，并向第一节点和/或第二节点请求应答DNS请求。若第一节点能够提供正常的域名解析服 务，则第二节点拒绝应答DNS请求。
进一步地，若递归服务器向第二节点请求应答DNS请求，而第二节点拒绝应答DNS请求(由于第一节点能够提供正常的域名解析服务，因而第二节点拒绝应答DNS请求)，则递归服务器根据DNS协议重新发起二次查询，向第一节点请求应答DNS请求。
在本发明的又一实施例中，当第一节点出现DNS解析故障时，第二节点查询本节点是否缓存了DNS请求对应的授权信息，若本节点未缓存DNS请求对应的授权信息，则向第三节点请求应答DNS请求。反之，若本节点缓存了DNS请求对应的授权信息，则直接利用本节点缓存的DNS请求对应的授权信息，对DNS请求进行应答。
以上介绍了图4所示实施例的各个环节的多种实现方式，下面通过具体实施例进一步介绍基于安全域名系统进行故障处理的方法的实现过程。
图5示出了根据本发明另一个实施例的基于安全域名系统进行故障处理的方法的流程图。在该实施例中，假设第一节点为授权服务器(或权威服务器)，对客户端发起的DNS请求提供域名解析服务；第二节点为超级防护节点(即，NS-IP-safe)，为第一节点的代理节点，第一节点和第二节点的IP均对外公开；第三节点为隐藏节点(即，DNS-IP-backup)，仅对来自第二节点的DNS请求进行应答。第一节点和第三节点位于不同的机房，并保证链路数据一致。参见图5，该方法至少可以包括步骤S502至步骤S512。
步骤S502，由递归服务器接收客户端发起的DNS请求，并向第一节点请求应答DNS请求。
步骤S504，判断第一节点是否出现DNS解析故障，若是，则继续执行步骤S506；若否，则继续执行步骤S508。
步骤S506，启动作为第一节点的代理节点的第二节点，继续执行步骤S510。
步骤S508，由第一节点应答DNS请求。
步骤S510，由第二节点应答DNS请求，对DNS请求中的异常请求进行过滤，进而向第三节点请求应答过滤后的DNS请求。
该步骤中，由第二节点设置访问权限控制，屏蔽DNS的攻击数据，从而进一步提高DNS解析的安全性及稳定性，并提高防御DNS攻击能力。这里关于DNS的攻击数据的判断可参见前文介绍，此处不再赘述。
步骤S512，利用第三节点调用授权信息数据库中相应的授权信息，对DNS请求进行应答。
该步骤中，授权信息数据库中存储了指定区域的所有DNS请求及对应的授权信息，具体的生成授权信息数据库的方案可参见前文介绍，此处不再赘述。
在本发明的另一实施例中，在步骤S502中，若递归服务器向第二节点请求应答 DNS请求，而步骤S504中判断第一节点能够提供正常的域名解析服务，第二节点拒绝应答DNS请求，则递归服务器按DNS协议重新发起二次查询，向第一节点请求应答DNS请求。
根据上述任意一个可选实施例或多个可选实施例的组合，本发明实施例能够达到如下有益效果：
本发明实施例提供的安全域名系统，在正常状态下，第一节点能够对客户端发起的DNS请求提供域名解析服务，而当第一节点出现DNS解析故障时，系统中作为代理节点的第二节点便向第三节点请求应答DNS请求，由第三节点调用授权信息数据库中相应的授权信息，对DNS请求进行应答。本发明实施例提供的安全域名系统中，授权信息数据库中存储了指定区域内的所有DNS请求及对应的授权信息，这样第三节点能够有足够的信息资源对DNS请求进行应答。进一步，安全域名系统中的第二节点，其作为第一节点的代理节点，当第一节点出现DNS解析故障时，向第三节点请求应答DNS请求，从而使得第三节点能够不直接对外提供域名解析服务，而是当第一节点出现DNS解析故障时，对第二节点转发的DNS请求进行应答，从而保证了第三节点在提供域名解析服务时的响应能力和速度，提高域名解析的安全性和稳定性。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施 例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的安全域名系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
例如，图6示出了可以实现基于安全域名系统进行故障处理的方法的计算设备。该计算设备传统上包括处理器610和以存储器620形式的计算机程序产品或者计算机可读介质。存储器620可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器620具有用于执行上述方法中的任何方法步骤的程序代码631的存储空间630。例如，用于程序代码的存储空间630可以包括分别用于实现上面的方法中的各种步骤的各个程序代码631。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为如参考图7所述的便携式或者固定存储单元。该存储单元可以具有与图6的计算设备中的存储器620类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括计算机可读代码631’，即可以由例如诸如610之类的处理器读取的代码，这些代码当由计算设备运行时，导致该计算设备执行上面所描述的方法中的各个步骤。
本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本发明的至少一个实施例中。此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (28)

  1. 一种安全域名系统，包括：
    第一节点，适于对客户端发起的DNS请求提供域名解析服务；
    作为所述第一节点的代理节点的第二节点，适于当所述第一节点出现DNS解析故障时，向第三节点请求应答所述DNS请求；
    授权信息数据库，适于存储指定区域的所有DNS请求及对应的授权信息；
    第三节点，适于接收来自所述第二节点的DNS请求，调用所述授权信息数据库中相应的授权信息，对所述DNS请求进行应答。
  2. 根据权利要求1所述的系统，其中，所述第三节点仅对来自所述第二节点的DNS请求进行应答。
  3. 根据权利要求1或2所述的系统，其中，所述第三节点的数据链路独立于所述第一节点的数据链路。
  4. 根据权利要求1-3任一项所述的系统，其中，所述第二节点还适于：
    对所述DNS请求中的异常请求进行过滤；
    向第三节点请求应答过滤后的所述DNS请求。
  5. 根据权利要求1-4任一项所述的系统，其中，还包括：
    递归服务器，适于接收所述客户端发起的DNS请求，并向所述第一节点和/或所述第二节点请求应答所述DNS请求。
  6. 根据权利要求1-5任一项所述的系统，其中，所述第二节点还适于：
    若所述第一节点能够提供正常的域名解析服务，则拒绝应答所述DNS请求。
  7. 根据权利要求6所述的系统，其中，所述递归服务器还适于：
    当所述第一节点能够提供正常的域名解析服务、所述第二节点拒绝应答所述DNS请求时，向所述第一节点请求应答所述DNS请求。
  8. 根据权利要求1-7任一项所述的系统，其中，所述第二节点还适于：
    当所述第一节点出现DNS解析故障时，查询本节点是否缓存了所述DNS请求对应的授权信息；
    若否，则向所述第三节点请求应答所述DNS请求。
  9. 根据权利要求8所述的系统，其中，所述第二节点还适于：
    若本节点缓存了所述DNS请求对应的授权信息，则利用本节点缓存的所述DNS请求对应的授权信息，对所述DNS请求进行应答。
  10. 根据权利要求1-9任一项所述的系统，其中，所述授权信息包括访问量超过访问阈值的DNS解析记录，和/或，重要域名的DNS解析记录。
  11. 根据权利要求1-10任一项所述的系统，其中，所述授权信息数据库还适于：
    根据所述授权信息的相互关系，组成域名层次空间。
  12. 根据权利要求11所述的系统，其中，所述授权信息数据库为互联网域名层次的镜像。
  13. 根据权利要求1-12任一项所述的系统，其中，所述第二节点还适于：
    在骨干网对所述指定区域的临界区域出口处进行DNS数据报文的监听，以确定所述第一节点是否出现DNS解析故障。
  14. 一种基于安全域名系统进行故障处理的方法，包括：
    当第一节点出现DNS解析故障时，启动作为所述第一节点的代理节点的第二节点，由所述第二节点向第三节点请求应答所述DNS请求，其中，所述第一节点对客户端发起的DNS请求提供域名解析服务；
    利用所述第三节点调用授权信息数据库中相应的授权信息，对所述DNS请求进行应答，其中，所述授权信息数据库中存储了指定区域的所有DNS请求及对应的授权信息。
  15. 根据权利要求14所述的方法，其中，所述第三节点仅对来自所述第二节点的DNS请求进行应答。
  16. 根据权利要求14或15所述的方法，其中，所述第三节点的数据链路独立于所述第一节点的数据链路。
  17. 根据权利要求14-16任一项所述的方法，其中，由所述第二节点向第三节点请求应答所述DNS请求，包括：
    由所述第二节点对所述DNS请求中的异常请求进行过滤，并向第三节点请求应答过滤后的所述DNS请求。
  18. 根据权利要求14-17任一项所述的方法，其中，还包括：
    由递归服务器接收所述客户端发起的DNS请求，并向所述第一节点和/或所述第二节点请求应答所述DNS请求。
  19. 根据权利要求14-18任一项所述的方法，其中，还包括：
    若所述第一节点能够提供正常的域名解析服务，则不启动所述第二节点。
  20. 根据权利要求19所述的方法，其中，还包括：
    当所述递归服务器向所述第二节点请求应答所述DNS请求，所述第一节点能够提供正常的域名解析服务，所述第二节点拒绝应答所述DNS请求时，所述递归服务器向所述第一节点请求应答所述DNS请求。
  21. 根据权利要求14-20任一项所述的方法，其中，在启动第二节点之后，还包括：
    由所述第二节点查询本节点是否缓存了所述DNS请求对应的授权信息；
    若否，则向所述第三节点请求应答所述DNS请求。
  22. 根据权利要求21所述的方法，其中，还包括：
    若本节点缓存了所述DNS请求对应的授权信息，则利用本节点缓存的所述DNS 请求对应的授权信息，对所述DNS请求进行应答。
  23. 根据权利要求14-22任一项所述的方法，其中，所述授权信息包括访问量超过访问阈值的DNS解析记录，和/或，重要域名的DNS解析记录。
  24. 根据权利要求14-23任一项所述的方法，其中，所述授权信息数据库根据所述授权信息的相互关系，组成域名层次空间。
  25. 根据权利要求24所述的方法，其中，所述授权信息数据库为互联网域名层次的镜像。
  26. 根据权利要求14-25任一项所述的方法，其中，还包括：
    在骨干网对所述指定区域的临界区域出口处进行DNS数据报文的监听，以确定所述第一节点是否出现DNS解析故障。
  27. 一种计算机程序，包括计算机可读代码，当所述计算机可读代码在计算设备上运行时，导致所述计算设备执行根据权利要求14至26中任一项所述的基于安全域名系统进行故障处理的方法。
  28. 一种计算机可读介质，其中存储了如权利要求27所述的计算机程序。
PCT/CN2016/102424 2015-10-19 2016-10-18 一种安全域名系统及其故障处理方法 WO2017067443A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510679965.2 2015-10-19
CN201510679965.2A CN105245633A (zh) 2015-10-19 2015-10-19 一种安全域名系统及其故障处理方法

Publications (1)

Publication Number Publication Date
WO2017067443A1 true WO2017067443A1 (zh) 2017-04-27

Family

ID=55043130

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/102424 WO2017067443A1 (zh) 2015-10-19 2016-10-18 一种安全域名系统及其故障处理方法

Country Status (2)

Country Link
CN (1) CN105245633A (zh)
WO (1) WO2017067443A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113067781A (zh) * 2020-01-02 2021-07-02 阿里巴巴集团控股有限公司 一种数据处理方法及其装置
CN115150358A (zh) * 2021-03-31 2022-10-04 贵州白山云科技股份有限公司 域名获取的方法、电子装置以及系统

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105245633A (zh) * 2015-10-19 2016-01-13 北京奇虎科技有限公司 一种安全域名系统及其故障处理方法
CN106973122A (zh) * 2016-01-14 2017-07-21 中国移动通信集团浙江有限公司 一种基于云存储的域名系统及其应急解决方法
CN105721632A (zh) * 2016-04-12 2016-06-29 上海斐讯数据通信技术有限公司 一种基于dns机制的无线接入方法及无线接入设备
CN108366138B (zh) * 2018-05-28 2021-10-26 北京奇虎科技有限公司 域名操作方法、系统及电子设备
CN110944027B (zh) * 2018-09-21 2023-04-07 阿里巴巴集团控股有限公司 访问处理方法、装置、设备以及系统
CN109510778A (zh) * 2019-01-03 2019-03-22 Oppo广东移动通信有限公司 流量调度的方法、装置、系统、设备及存储介质
CN110247999B (zh) * 2019-07-11 2022-05-06 广东美的制冷设备有限公司 域名解析方法、域名解析装置、家电设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100332680A1 (en) * 2009-06-24 2010-12-30 Broadcom Corporation Fault tolerance approaches for dns server failures
CN103118117A (zh) * 2013-02-04 2013-05-22 河南有线电视网络集团有限公司 一种负载均衡和冗余保护方法及装置
CN103957285A (zh) * 2014-04-18 2014-07-30 上海聚流软件科技有限公司 提供根域名解析服务的方法和系统
CN103957286A (zh) * 2014-04-18 2014-07-30 上海聚流软件科技有限公司 Dns安全系统及其故障处理方法
CN103957284A (zh) * 2014-04-04 2014-07-30 上海聚流软件科技有限公司 Dns行为的处理方法、装置及系统
CN105245633A (zh) * 2015-10-19 2016-01-13 北京奇虎科技有限公司 一种安全域名系统及其故障处理方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102137174B (zh) * 2010-12-29 2013-10-09 华为技术有限公司 域名系统缓存的方法、授权域名服务器、缓存域名服务器
CN103929507B (zh) * 2014-04-28 2017-10-10 广东睿江云计算股份有限公司 一种实现可离线化dns服务的方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100332680A1 (en) * 2009-06-24 2010-12-30 Broadcom Corporation Fault tolerance approaches for dns server failures
CN103118117A (zh) * 2013-02-04 2013-05-22 河南有线电视网络集团有限公司 一种负载均衡和冗余保护方法及装置
CN103957284A (zh) * 2014-04-04 2014-07-30 上海聚流软件科技有限公司 Dns行为的处理方法、装置及系统
CN103957285A (zh) * 2014-04-18 2014-07-30 上海聚流软件科技有限公司 提供根域名解析服务的方法和系统
CN103957286A (zh) * 2014-04-18 2014-07-30 上海聚流软件科技有限公司 Dns安全系统及其故障处理方法
CN105245633A (zh) * 2015-10-19 2016-01-13 北京奇虎科技有限公司 一种安全域名系统及其故障处理方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113067781A (zh) * 2020-01-02 2021-07-02 阿里巴巴集团控股有限公司 一种数据处理方法及其装置
CN115150358A (zh) * 2021-03-31 2022-10-04 贵州白山云科技股份有限公司 域名获取的方法、电子装置以及系统
CN115150358B (zh) * 2021-03-31 2024-02-13 贵州白山云科技股份有限公司 域名获取的方法、电子装置以及系统

Also Published As

Publication number Publication date
CN105245633A (zh) 2016-01-13

Similar Documents

Publication Publication Date Title
WO2017067443A1 (zh) 一种安全域名系统及其故障处理方法
WO2015158193A1 (zh) 提供根域名解析服务的方法和系统
WO2015158194A1 (zh) Dns安全系统及其故障处理方法
CN109474575B (zh) 一种dns隧道的检测方法及装置
US9300623B1 (en) Domain name system cache integrity check
CN103634786B (zh) 一种无线网络的安全检测和修复的方法与系统
US9830458B2 (en) Discovery and classification of enterprise assets via host characteristics
WO2017041666A1 (zh) 一种针对访问请求的处理方法和装置
EP3264720A1 (en) Using dns communications to filter domain names
CN110324295B (zh) 一种域名系统泛洪攻击的防御方法和装置
US20130007882A1 (en) Methods of detecting and removing bidirectional network traffic malware
US9350754B2 (en) Mitigating a cyber-security attack by changing a network address of a system under attack
US9264440B1 (en) Parallel detection of updates to a domain name system record system using a common filter
EP3306900B1 (en) Dns routing for improved network security
CN105025025A (zh) 一种基于云平台的域名主动检测方法和系统
CN107682470B (zh) 一种检测nat地址池中公网ip可用性的方法及装置
CN110572406B (zh) 一种失陷主机确定方法、系统及相关装置
CN108270778B (zh) 一种dns域名异常访问检测方法及装置
CN108156270B (zh) 域名请求处理方法和装置
CN113301012A (zh) 一种网络威胁的检测方法、装置、电子设备及存储介质
TW201002008A (en) Method and system for preventing from communication by hackers
JP2017534110A (ja) ドメイン名システムのリソース枯渇攻撃を識別する装置及び方法
CN105407186A (zh) 获取子域名的方法和装置
EP3332533B1 (en) Parallel detection of updates to a domain name system record system using a common filter
CN110401644A (zh) 一种攻击防护方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16856874

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16856874

Country of ref document: EP

Kind code of ref document: A1