A domain name resolution method, device and equipment

Abstract

The application discloses a domain name resolution method and device, electronic equipment and a storage medium, comprising: a mirror server synchronously acquiring and storing mirror data of an IPv6 root server; a plurality of edge leaf nodes are used as exit hot standby gateways, so that the edge leaf nodes receive access requests of clients to the IPv6 root server; receiving the access request returned by the edge leaf node, and resolving the access request according to the mirror data, and returning the obtained resolution result to the edge leaf node, so that the edge leaf node returns the resolution result to the client. In this way, the deployment of the IPv6 root server mirror on the edge of the new metropolitan area cloud network can be realized, the mirror server can directly serve the edge users, which is equivalent to the function of directly accessing the global IPv6 root server, is simpler and more effective than the traditional non-real-time and step-by-step resolution recursion, and significantly improves the efficiency and response speed of the IPv6 domain name resolution.

Description

Technical Field

[0001] This application belongs to the Internet field, and specifically relates to a domain name resolution method, apparatus, device, and storage medium. Background Technology

[0002] IPv6 (Internet Protocol Version 6) is the next-generation IP protocol designed to replace IPv4, offering a vast amount of network address resources and greater scope for innovation. IPv6 top-level domain name resolution is handled by the IPv6 root servers.

[0003] Traditional IP metropolitan area cloud networks access DNS level by level based on recursive DNS (Domain Name System). For example, a city-level metropolitan area cloud network first accesses the provincial DNS, and then sends a recursive query request to the next higher level through a forwarding server. If the DNS is not resolved, it will hop up to the root server. The request process uses traditional TCP (Transmission Control Protocol) or IP protocol, without using SRv6 (Segment Routing IPv6) and its supporting tunneling technology. The access resolution latency and accuracy depend on the length of the request path, the quality of the network along the way, and the DNS resolution settings at each level, resulting in significant differences between different regions.

[0004] Therefore, the step-by-step recursive access method used in traditional solutions often requires a long time for domain name resolution, and the resolution speed is easily affected by the access path. It cannot meet the high-speed domain name resolution requirements of some Internet businesses, resulting in low domain name resolution efficiency, low accuracy, and inability to meet response latency. Summary of the Invention

[0005] The purpose of this application is to provide a domain name resolution method, apparatus, device, and storage medium that can solve the problems of low efficiency, low accuracy, and inability to meet response latency in current domain name resolution.

[0006] In a first aspect, embodiments of this application provide a domain name resolution method applied to a mirror server, including:

[0007] Synchronously acquire and store mirror data of the IPv6 root server;

[0008] Multiple edge leaf nodes are used as egress hot standby gateways so that the edge leaf nodes can receive client access requests to the IPv6 root server;

[0009] The system receives the access request returned by the edge leaf node, parses the access request according to the mirror data, and returns the parsing result to the edge leaf node so that the edge leaf node returns the parsing result to the client.

[0010] Optionally, the synchronous acquisition and storage of mirror data of the IPv6 root server includes:

[0011] Receive sequence number query requests sent by the IPv6 root server;

[0012] The IPv6 root server returns a first sequence number of its own stored data to the IPv6 root server, so that the IPv6 root server returns mirrored data if the second sequence number of its own stored data is greater than the first sequence number; the mirrored data is the same as the IPv6 root server's own stored data.

[0013] Receive and store the mirror data returned by the IPv6 root server.

[0014] Optionally, after receiving and storing the mirrored data returned by the IPv6 root server, the method further includes:

[0015] At a preset refresh interval, a region update notification is sent to the backup server of the mirror server so that the backup server updates its own stored data according to the mirror data.

[0016] Optionally, the synchronous acquisition and storage of mirror data of the IPv6 root server includes:

[0017] In response to a region update notification sent by the master server of the mirror server, the mirror data of the IPv6 root server is obtained from and stored by the master server.

[0018] Optionally, the step of using multiple edge leaf nodes as an egress hot standby gateway includes:

[0019] The multiple edge leaf nodes are grouped into pairs to obtain multiple hot standby groups;

[0020] Configure the same egress hot standby gateway address for the two edge leaf nodes in each hot standby group, and synchronize the data between the two edge leaf nodes; the two edge leaf nodes include a primary node and a standby node;

[0021] The process of receiving the access request returned by the edge leaf node, parsing the access request based on the mirror data, and returning the parsing result to the edge leaf node includes:

[0022] The primary node is used as the target node. The access request returned by the target node is received, and the access request is parsed according to the mirror data. The parsing result is then returned to the target node.

[0023] In the event of a failure of the primary node, the target node will be switched to the backup node.

[0024] Optionally, the method further includes:

[0025] Obtain monitoring data from the mirror server, including status information, traffic information, and checksum information;

[0026] The monitoring data is subjected to anomaly detection, and an alarm message is sent if the detection result is abnormal.

[0027] Optionally, the step of verifying the monitoring data and sending an alarm message in case of verification anomalies includes:

[0028] Acquire historical anomaly data and train an anomaly detection model based on the historical anomaly data;

[0029] The monitoring data is input into the anomaly detection model for processing, and an alarm message is sent when the output indicates an anomaly.

[0030] Secondly, embodiments of this application provide a domain name resolution device applied to a mirror server, comprising:

[0031] The acquisition module is used to synchronously acquire and store the mirror data of the IPv6 root server;

[0032] The configuration module is used to set up multiple edge leaf nodes as egress hot standby gateways, so that the edge leaf nodes can receive client access requests to the IPv6 root server.

[0033] The processing module is configured to receive the access request returned by the edge leaf node, parse the access request according to the mirror data, and return the parsing result to the edge leaf node so that the edge leaf node returns the parsing result to the client.

[0034] Optionally, the acquisition module is used to:

[0035] Receive sequence number query requests sent by the IPv6 root server;

[0036] The IPv6 root server returns a first sequence number of its own stored data to the IPv6 root server, so that the IPv6 root server returns mirrored data if the second sequence number of its own stored data is greater than the first sequence number; the mirrored data is the same as the IPv6 root server's own stored data.

[0037] Receive and store the mirror data returned by the IPv6 root server.

[0038] Optionally, the acquisition module is used to:

[0039] At a preset refresh interval, a region update notification is sent to the backup server of the mirror server so that the backup server updates its own stored data according to the mirror data.

[0040] Optionally, the acquisition module is used to:

[0041] In response to a region update notification sent by the master server of the mirror server, the mirror data of the IPv6 root server is obtained from and stored by the master server.

[0042] Optionally, the setting module is used to:

[0043] The multiple edge leaf nodes are grouped into pairs to obtain multiple hot standby groups;

[0044] Configure the same egress hot standby gateway address for the two edge leaf nodes in each hot standby group, and synchronize the data between the two edge leaf nodes; the two edge leaf nodes include a primary node and a standby node;

[0045] The process of receiving the access request returned by the edge leaf node, parsing the access request based on the mirror data, and returning the parsing result to the edge leaf node includes:

[0046] The primary node is used as the target node. The access request returned by the target node is received, and the access request is parsed according to the mirror data. The parsing result is then returned to the target node.

[0047] In the event of a failure of the primary node, the target node will be switched to the backup node.

[0048] Optionally, the device further includes a processing module for:

[0049] Obtain monitoring data from the mirror server, including status information, traffic information, and checksum information;

[0050] The monitoring data is subjected to anomaly detection, and an alarm message is sent if the detection result is abnormal.

[0051] Optionally, the processing module is configured to:

[0052] Acquire historical anomaly data and train an anomaly detection model based on the historical anomaly data;

[0053] The monitoring data is input into the anomaly detection model for processing, and an alarm message is sent when the output indicates an anomaly.

[0054] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0055] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0056] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0057] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.

[0058] In the solution provided in this application embodiment, the mirror server synchronously acquires and stores the mirror data of the IPv6 root server; multiple edge leaf nodes are used as egress hot standby gateways so that the edge leaf nodes can receive client access requests to the IPv6 root server; the access requests returned by the edge leaf nodes are received, and the access requests are parsed according to the mirror data, and the parsing results are returned to the edge leaf nodes so that the edge leaf nodes can return the parsing results to the client.

[0059] In this way, by deploying a mirror server, the mirror data of the IPv6 root server is synchronously acquired and stored, enabling the rapid resolution of the IPv6 root server to be pushed down to the edge of the new metropolitan area cloud network. Client access to the mirror server is equivalent to directly connecting to the IPv6 root server. Compared with the traditional recursive access to the IPv6 root server by the client through hierarchical resolution, the method of accessing the mirror server in this application is simple and effective, which can reduce the normal domain name resolution time and the top-level domain name resolution time, thereby compressing the data loading time and improving the efficiency, accuracy and response speed of IPv6 domain name resolution. Attached Figure Description

[0060] Figure 1 This is a flowchart illustrating a domain name resolution method according to an exemplary embodiment;

[0061] Figure 2 This is a logical schematic diagram illustrating a domain name resolution method according to an exemplary embodiment;

[0062] Figure 3 This is a schematic diagram illustrating the resolution path of a domain name resolution method according to an exemplary embodiment;

[0063] Figure 4 This is a block diagram illustrating a domain name resolution apparatus according to an exemplary embodiment;

[0064] Figure 5 A block diagram of a domain name resolution electronic device is shown according to an exemplary embodiment;

[0065] Figure 6 This is a block diagram illustrating an apparatus for domain name resolution according to an exemplary embodiment. Detailed Implementation

[0066] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0067] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0068] The domain name resolution method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0069] Figure 1 This is a flowchart illustrating a domain name resolution method according to an exemplary embodiment, applied to a mirror server, the domain name resolution method including the following steps.

[0070] In step S11, the mirror data of the IPv6 root server is synchronously acquired and stored.

[0071] IPv6 is the next-generation IP protocol designed to replace IPv4, offering a vast amount of network address resources and greater room for innovation. In related technologies, IPv6's top-level domain name resolution service is handled by IPv6 root servers. IP metropolitan area cloud networks utilize recursive DNS for hierarchical access.

[0072] Specifically, the city-level metropolitan area cloud network first accesses the provincial DNS, and then sends a recursive query request to the next higher level through a forwarding server. If the query is not resolved, it hops up to the root server. The request process uses the traditional TCP or IP protocol and does not use SRv6 and its supporting tunneling technology. The access resolution latency and accuracy depend on the length of the request path, the quality of the network along the way, and the DNS resolution settings at each level, which vary greatly across different regions.

[0073] Therefore, the step-by-step recursive access method used in traditional solutions often requires a long time for domain name resolution, and the resolution speed is easily affected by the access path. It cannot meet the high-speed domain name resolution requirements of some Internet businesses, resulting in low domain name resolution efficiency, low accuracy, and inability to meet response latency.

[0074] Based on this, the solution proposed in this application is to deploy an IPv6 root server image on the edge computing module of the new metropolitan area cloud network and set up an update and data management mechanism. This enables the root server to quickly resolve and sink to the edge of the new metropolitan area cloud network, which is equivalent to directly connecting to the IPv6 root server. This can solve the problems of latency and long path response time of traditional IPv6 DNS resolution affected by backbone network and centralized configuration, as well as the problems of low efficiency and low accuracy of domain name resolution for Internet services in IPv6 scenarios. It reduces the normal domain name resolution time and top-level domain name resolution time, thereby reducing the loading time of government and enterprise edge applications and the full loading time of websites. Furthermore, it can be combined with edge computing for application in differentiated government and enterprise fields such as industrial Internet and education IoT, outputting large-scale market value and a highly available edge domain name resolution device with evidence-based protection.

[0075] In this step, the mirror server first needs to synchronously acquire and store the mirror data of the IPv6 root server. The mirror data is a copy of the data stored in the IPv6 root server. Therefore, the mirror data is consistent with the data stored in the IPv6 root server and can support independent access to the mirror data.

[0076] In this application, the mirrored data can be a copy of all the data stored in the IPv6 root server, or a copy of some core files stored in the IPv6 root server.

[0077] The mirror server can request mirror data from the IPv6 root server at certain time intervals. Alternatively, the IPv6 root server can notify the mirror server to synchronize and update its stored mirror data after its own stored data is updated. This application does not specify the specific method.

[0078] In this application, the above process can be implemented by the main root server synchronization update module.

[0079] In one implementation, synchronously acquiring and storing mirror data of the IPv6 root server includes:

[0080] Receive sequence number query requests sent by the IPv6 root server;

[0081] Return the first sequence number of the mirror server's own stored data to the IPv6 root server, so that the IPv6 root server will return the mirror data if the second sequence number of its own stored data is greater than the first sequence number; the mirror data is the same as the IPv6 root server's own stored data.

[0082] Receive and store the mirror data returned by the IPv6 root server.

[0083] In other words, data synchronization between the mirror server and the IPv6 root server can be achieved based on Zone Updates technology. The IPv6 root server actively initiates a sequence number query to the mirror server. If the second sequence number of the data stored on the IPv6 root server is found to be greater than the first sequence number of the data stored on the mirror server, the mirror server is notified to synchronize data with the IPv6 root server. At the same time, the updated data is stored locally on the mirror server.

[0084] This enables the mirror data in the mirror server to be updated, ensuring data consistency between the mirror server and the IPv6 root server, and laying the foundation for the mirror server to provide IPv6 services to clients in the future.

[0085] In this application, the mirror server can be configured in a primary and backup manner. The mirror data is sent from the primary mirror server to the backup mirror server through two protocols: AXFR (Full Zone Update) and / or IXFR (Incremental Zone Update).

[0086] Among them, AXFR means that all mirror data is transmitted during the update, while IXFR means that only the mirror data of the variables is transmitted during the update. The protocol used can be determined according to the current business scenario, and this application does not specify the specific protocol.

[0087] In one implementation, after receiving and storing the mirrored data returned by the IPv6 root server, the method further includes:

[0088] At preset refresh intervals, a region update notification is sent to the backup server of the mirror server so that the backup server can update its own stored data based on the mirror data.

[0089] Specifically, if the mirror server is the primary server in a primary-backup configuration, then when the preset refresh interval expires, the mirror server will proactively notify the backup server of the regional update, so that the backup server can update its own stored data based on the mirror data stored in the mirror server, thereby achieving data synchronization between the primary and backup servers.

[0090] In one implementation, synchronously acquiring and storing mirror data of the IPv6 root server includes:

[0091] In response to the region update notification sent by the master server of the mirror server, the mirror data of the IPv6 root server is obtained from the master server and stored.

[0092] Specifically, if the mirror server is used as the backup server in a primary-backup configuration, then when the preset refresh interval expires, the primary server will proactively notify the mirror server of the regional update so that the mirror server can obtain the mirror data from the primary server and achieve data synchronization between the primary and backup servers.

[0093] In other words, this application backs up the mirror server of the IPv6 root server, and can use the BFD (Bidirectional Forwarding Detection) mechanism for fault detection. If the link of the primary server fails, the backup server will be switched to provide IPv6 services to the client, thereby improving the robustness of the system.

[0094] In this application, the above steps can be implemented by the IPv6 root service mirror module.

[0095] In step S12, multiple edge leaf nodes are used as egress hot standby gateways so that the edge leaf nodes can receive client access requests to the IPv6 root server.

[0096] This application is applied to a new type of metropolitan area cloud network, which requires a new type of metropolitan area edge docking module to connect between the mirror server and the communication module of the new type of metropolitan area cloud network edge POP (Point-of-Presence) to perform data forwarding between the mirror server and the communication module.

[0097] The new metropolitan area edge connection module mainly includes edge Leaf nodes for edge cloud access and DCGW (Data Center Gateway) equipment for edge cloud network egress. Edge Leaf nodes and A-Leaf are Leaf devices with different roles in the new metropolitan area cloud network, and their planned functions differ. Edge Leaf nodes are mainly used to connect to the edge cloud network, while A-Leaf are used to connect to the access network or directly connect to the customer network.

[0098] Therefore, the new metropolitan area edge docking module can use the edge leaf node in the new metropolitan area cloud network edge POP as the cloud network boundary device, and assume the role of ASBR (Autonomous System Border Router). After the client accesses A-Leaf, it transmits and resolves traffic with the edge leaf node through the SRv6EVPN (Ethernet Virtual Private Network) tunnel.

[0099] In one implementation, multiple edge leaf nodes are used as egress hot standby gateways, including:

[0100] Multiple edge leaf nodes are grouped into pairs to obtain multiple hot standby groups;

[0101] Configure the same egress hot standby gateway address for the two edge leaf nodes in each hot standby group, and synchronize the data between the two edge leaf nodes; the two edge leaf nodes include a primary node and a standby node;

[0102] Receive access requests returned by edge leaf nodes, parse the access requests based on the mirror data, and return the parsed results to the edge leaf nodes, including:

[0103] The primary node is used as the target node. The primary node receives the access request returned by the target node, parses the access request according to the mirror data, and returns the parsing result to the target node.

[0104] In the event of a primary node failure, the target node will be switched to a backup node.

[0105] In other words, the network egress hot standby gateway IP of the mirror server can be configured on the edge Leaf node. By configuring the same egress hot standby gateway address for two edge Leaf nodes, the uplink of the network egress device of the mirror root server can be Eth-trunk port aggregation, and the links can be dual-homed to the two edge Leaf nodes, thereby achieving high availability of the IPv6 root mirror server egress network.

[0106] E-trunk cross-device aggregation is configured between two edge Leaf nodes with the same outbound hot standby gateway address, and the interfaces of the gateways on both sides are configured with the same MAC (Media Access Control) address, forming an RBS (Remote Backup Service) hot standby group, and the gateway interface is added to the RBS hot standby group.

[0107] In this way, the two edge Leaf nodes in the RBS hot standby group enable remote backup of ARP (Address Resolution Protocol) services for each other, backing up MAC addresses to the other end and maintaining real-time synchronization of ARP entries between the two edge Leaf nodes. Simultaneously, a BFD mechanism is employed between the two edge Leaf nodes to monitor the relay link status of the downstream mirror server.

[0108] By default, the gateway interface of the primary edge Leaf node exchanges LACP (Link Aggregation Control Protocol) messages with the egress network device of the mirror server. Since the two edge Leaf nodes in the RBS hot standby group have the same MAC address, the RBS hot standby group backs up the MAC address on the access side of each other, and the traffic for IPv6 root server resolution is load-sharing.

[0109] When the link connecting the mirror server to the primary edge leaf node fails, the BFD mechanism will trigger the primary edge leaf node to go down. The gateway interface of the backup edge leaf node will then exchange LACP packets with the egress network device of the mirror server. The gateway interface of the egress network device of the mirror server will remain unchanged. Since the two edge leaves in the RBS hot standby group have the same MAC address, the uplink traffic of the mirror server can be smoothly switched to the backup edge leaf node. At the same time, the backup edge leaf node has the MAC address of the mirror server, which can achieve smooth forwarding of downlink traffic. The unilateral failure switchover is imperceptible.

[0110] In step S13, the access request returned by the edge leaf node is received, and the access request is parsed according to the mirror data. The parsing result is returned to the edge leaf node so that the edge leaf node can return the parsing result to the client.

[0111] In this step, the mirror server can receive access requests returned by the edge leaf nodes, and then parse the access requests according to the mirror data to obtain the parsing results. Since the mirror data is consistent with the data stored by the IPv6 root server, the parsing results obtained by the mirror server for the access requests are consistent with the parsing results obtained by the IPv6 root server for the access requests.

[0112] Furthermore, the resolution results obtained from the mirror server can be returned to the edge leaf node, and then the edge leaf node can return the resolution results to the client. The client can then obtain the resolution results corresponding to the access request without increasing the load on the IPv6 root server.

[0113] In one implementation, the domain name resolution method provided in this application further includes:

[0114] Obtain monitoring data from the mirror server, including status information, traffic information, and checksum information;

[0115] Perform anomaly detection on the monitoring data and send alarm information if the detection results are abnormal.

[0116] In other words, DDoS (Distributed Denial of Service) protocol message monitoring can be designed to prevent DDoS attacks and monitor performance by adding DDoS protocol message monitoring to the mirror server's connection to the new metropolitan area cloud network access point. Alternatively, the traffic and CRC (Cyclic Redundancy Check) status of the new metropolitan area edge connection module and the main root server synchronization update module can be monitored through the Telemetry protocol.

[0117] This allows for timely monitoring of the mirror server's operation, enabling prompt maintenance or repair and reducing IPv6 access anomalies caused by server failures.

[0118] In one implementation, the monitoring data is verified, and an alarm message is sent if an anomaly is detected, including:

[0119] Acquire historical anomaly data and train an anomaly detection model based on the historical anomaly data;

[0120] The monitoring data is input into the anomaly detection model for processing, and an alarm message is sent when the output indicates an anomaly.

[0121] In other words, an anomaly detection model can be trained based on historical anomaly data of the DNS server. This anomaly detection model can be a machine learning model, which can learn the normal behavior patterns and characteristics of abnormal behavior of the DNS server. It can process and analyze new monitoring data in real time, identify any behavior that deviates from the normal pattern, and thus predict possible performance problems or failures of the mirror server.

[0122] In this application, the above process can be implemented by a security monitoring module.

[0123] like Figure 2 The diagram shown is a logical representation of a domain name resolution method, which includes an IPv6 root service mirroring module, a new metropolitan area edge connection module, a main root server synchronization update module, and a security monitoring module.

[0124] The IPv6 root service mirroring module includes a root zone file generation submodule, a root zone file distribution submodule, a root zone resolution submodule, and a root zone file security authentication submodule. Mirroring data is sent from the primary server in the mirroring server to the backup server via both AXFR and IXFR protocols. When the preset refresh interval expires, the primary server proactively notifies the backup server of the mirroring zone update.

[0125] Specifically, the root zone file generation submodule is used to maintain mirror data, including the backup, update and synchronization of mirror data. It can technically ensure the uniqueness, integrity and authority of mirror data, and is logically directly related to the top-level domain registration subsystem and the root zone file security authentication subsystem.

[0126] The root zone file distribution submodule is used to send image data from the primary server to the backup server in the image server. It shows the zone transfer process between the primary and backup image servers. This process varies depending on whether the image data between the primary and backup servers has been copied before, or whether the initial copy of the image data between the primary and backup image servers is being performed.

[0127] The root zone resolution submodule is mainly used to provide DNS resolution and response services for root zone data based on the location of the mirror server in the domain name system, provide a query entry point for Internet applications, and support new domain name technologies such as IPv6, IDN (Interactive Data Network) and DNSSEC (Domain Name System Security Extensions).

[0128] The root zone file security authentication submodule is used for DNSSEC deployment based on the IPv6 root server as the trusted anchor point, providing a trusted domain name resolution system. The domain name system provides a domain name-oriented identity authentication business system and its associated hardware and software systems.

[0129] The primary root server synchronization update module synchronizes data with the IPv6 root server based on regional transfer technology. The IPv6 root server actively initiates a sequence number query. If the second sequence number in the IPv6 root server is greater than the first sequence number in the mirror server, the mirror server synchronizes data with the IPv6 root server to update the data. At the same time, the updated mirror data is stored locally on the mirror server. The IPv6 root server acts as the server, and the mirror server in the system acts as the client.

[0130] The new metropolitan area edge docking module connects the mirror server and the communication module of the new metropolitan area cloud network edge POP, forwarding data between the mirror server and the new metropolitan area cloud network communication module. The edge Leaf nodes in the new metropolitan area cloud network edge POP act as cloud network boundary devices, assuming the ASBR role. After a client accesses the A-Leaf, it transmits and resolves traffic with the cloud network edge Leaf nodes through an SRv6 EVPN tunnel.

[0131] Security monitoring module: Designed to prevent traffic attacks and monitor performance, it adds DDoS protocol message monitoring to the new metropolitan area cloud network access point of the image server to predict possible performance problems or failures.

[0132] like Figure 3 The diagram illustrates the resolution path of a domain name resolution method. The client's DNS is set to the service address of the IPv6 root mirror server. When the client accesses the internet via a CPE (Content Premises Equipment), it first accesses the mirror server for domain name resolution. Due to the spine-leaf architecture and end-to-end SRv6 network infrastructure of the new metropolitan area cloud network, the A-leaf devices and edge leaf devices accessing the service are under the same EVPN. Therefore, introducing this architecture allows for a one-hop to the cloud. IPv6 domain name resolution traffic does not need to leave the new metropolitan area cloud network to reach the mirror server, which is an equivalent mirror of the IPv6 root server, greatly saving domain name resolution time and improving webpage loading speed.

[0133] like Figure 2 Path 1, the IPv6 domain name resolution traffic path is: CPE->A-leaf->edge leaf node->DCGW->mirror server.

[0134] The mirror server returns the domain name resolution results to the client, reducing the recursive path and the resolution error rate. The client then queries its local router for forwarding based on the actual IP address of the webpage. Internet traffic specifically travels from the A-leaf device to the Spine device, and from the Spine device to the core router to access the internet.

[0135] like Figure 2 Path 2, the IPv6 Internet access traffic path is: A-leaf->Spine->CR->Internet.

[0136] In dedicated cloud access scenarios, domain name resolution traffic is consistent with dedicated internet access scenarios, such as... Figure 2 Path 3 accesses the edge cloud's DNS resolution business scenario. Business traffic travels from the A-leaf device to the Spine device, and then to the edge cloud POP's exit leaf device. Based on different business needs, it is forwarded to different cloud business modules, quickly realizing localized domain name resolution for edge computing applications and improving resolution efficiency.

[0137] In other words, when an industrial internet user CPE sets the DNS to the service address of the new metropolitan area edge interface module, it first accesses the root zone resolution submodule of the mirror server to perform domain name resolution. The resolved unicast traffic enters the access network from the CPE and is then sent to the edge pair A-Leaf on the access side of the new metropolitan area cloud network.

[0138] Then, the A-Leaf and edge Leaf nodes connected to the Industrial Internet are in the same SRv6 EVPN. The A-Leaf and edge Leaf nodes are the two ends of the EVPN PE (Provider Edge) devices. Domain name resolution traffic connected to the A-Leaf can reach the edge Leaf node in one hop, which greatly reduces intermediate network latency compared to routing through public IP addresses one by one.

[0139] Furthermore, both edge Leaf nodes can receive the resolved traffic and, based on the local direct connection route, forward the resolved traffic to the interface of the business address gateway of the new metropolitan area edge docking module, and then forward it to the edge cloud DCGW connected to the edge Leaf node.

[0140] The edge cloud DCGW forwards the resolution traffic to the IPv6 root mirror server based on the service VLAN of the mirror server in the new metropolitan area edge docking module. The master server in the mirror server receives the request from the industrial internet IPv6 domain name resolution, performs local resolution, and returns the resolution result.

[0141] If the root zone resolution submodule fails to resolve the data, the primary root server synchronization update module triggers mirrored data transmission directly to the IPv6 root server. Data synchronization with the IPv6 root server is performed using Zone Updates. If the second sequence number of the IPv6 root server is found to be greater than the first sequence number of the primary server, the primary server synchronizes data with the IPv6 root server to achieve the data update.

[0142] The primary server synchronizes and resolves information, top-level domains, etc. to the backup server via AXFR and IXFR protocols.

[0143] The security monitoring module records the traffic IP flow and the hardware performance indicators of the IPv6 root service mirror module, the new metropolitan area edge docking module, and the main root server synchronization update module at that time. The hardware performance indicators include, but are not limited to, data related to CPU (Central Processing Unit), memory, and processes.

[0144] As can be seen from the above, the technical solution provided by the embodiments of this application, by deploying a mirror server, synchronously acquires and stores the mirror data of the IPv6 root server, enabling the rapid resolution of the IPv6 root server to be pushed down to the edge of the new metropolitan area cloud network. Client access to the mirror server is equivalent to directly connecting to the IPv6 root server. Compared with the client's traditional recursive access to the IPv6 root server through hierarchical resolution, the method of accessing the mirror server in this application is simple and effective, which can reduce the normal domain name resolution time and the top-level domain name resolution time, thereby compressing the data loading time and improving the efficiency, accuracy and response speed of IPv6 domain name resolution.

[0145] This solution can improve top-level domain name resolution to 1ms, and is particularly innovative for edge resolution applications in the industrial internet. It improves the resolution speed of random TLD (Top Level Domain) domain names by more than 225%, the success rate of recursive server resolution by 5%, the latency of mainstream web page homepages by 9%, and the average latency of real-time applications by 22%.

[0146] Furthermore, an innovative data synchronization and management mechanism was designed to achieve seamless integration between the mirror server and the IPv6 root server master node. By hiding the synchronization configuration on the main domain name system side, high availability and real-time performance of local data are ensured, providing stable and reliable edge-nearest domain name resolution services.

[0147] Furthermore, to address the deployment requirements of mirror servers on edge cloud nodes, a high-concurrency, high-availability bearing method was developed. An innovative load-balanced dual-homed A_LEAF architecture and BD domain VLAN multiplexing algorithm were designed, achieving efficient domain name resolution capabilities even under high-concurrency scenarios, meeting the stability and reliability requirements of multi-concurrent resolution services within the metropolitan area cloud network. It can be applied to tens of thousands of service accesses at the POD level in new metropolitan area cloud networks. A comparison of the average latency of resolving 10,000 random top-level domain names shows that the IPv6 root is on average 100ms faster than the default root resolution time.

[0148] Meanwhile, an innovative subsystem for root zone file generation, distribution, parsing, and secure authentication was constructed, enabling secure updates and synchronization of root zone files in the new metropolitan area cloud network. A security mechanism was developed based on two factors: network scale and traffic characteristics, ensuring the integrity and authenticity of the root zone files and enhancing the overall system security.

[0149] The domain name resolution method provided in this application can be executed by a domain name resolution device. This application uses the example of a domain name resolution device executing a terminal access method to illustrate the device for the domain name resolution method provided in this application.

[0150] Figure 4This is a block diagram of a domain name resolution apparatus according to an exemplary embodiment, applied to a mirror server, including:

[0151] The acquisition module 201 is used to synchronously acquire and store the mirror data of the IPv6 root server;

[0152] The configuration module 202 is used to set multiple edge leaf nodes as egress hot standby gateways so that the edge leaf nodes can receive client access requests to the IPv6 root server.

[0153] The processing module 203 is used to receive the access request returned by the edge leaf node, parse the access request according to the mirror data, and return the parsing result to the edge leaf node so that the edge leaf node returns the parsing result to the client.

[0154] Optionally, the acquisition module 201 is configured to:

[0155] Receive sequence number query requests sent by the IPv6 root server;

[0156] The IPv6 root server returns a first sequence number of its own stored data to the IPv6 root server, so that the IPv6 root server returns mirrored data if the second sequence number of its own stored data is greater than the first sequence number; the mirrored data is the same as the IPv6 root server's own stored data.

[0157] Receive and store the mirror data returned by the IPv6 root server.

[0158] Optionally, the acquisition module 201 is configured to:

[0159] At a preset refresh interval, a region update notification is sent to the backup server of the mirror server so that the backup server updates its own stored data according to the mirror data.

[0160] Optionally, the acquisition module 201 is configured to:

[0161] In response to a region update notification sent by the master server of the mirror server, the mirror data of the IPv6 root server is obtained from and stored by the master server.

[0162] Optionally, the setting module 202 is used to:

[0163] The multiple edge leaf nodes are grouped into pairs to obtain multiple hot standby groups;

[0164] Configure the same egress hot standby gateway address for the two edge leaf nodes in each hot standby group, and synchronize the data between the two edge leaf nodes; the two edge leaf nodes include a primary node and a standby node;

[0165] The process of receiving the access request returned by the edge leaf node, parsing the access request based on the mirror data, and returning the parsing result to the edge leaf node includes:

[0166] The primary node is used as the target node. The access request returned by the target node is received, and the access request is parsed according to the mirror data. The parsing result is then returned to the target node.

[0167] In the event of a failure of the primary node, the target node will be switched to the backup node.

[0168] Optionally, the device further includes a processing module for:

[0169] Obtain monitoring data from the mirror server, including status information, traffic information, and checksum information;

[0170] The monitoring data is subjected to anomaly detection, and an alarm message is sent if the detection result is abnormal.

[0171] Optionally, the processing module is configured to:

[0172] Acquire historical anomaly data and train an anomaly detection model based on the historical anomaly data;

[0173] The monitoring data is input into the anomaly detection model for processing, and an alarm message is sent when the output indicates an anomaly.

[0174] As can be seen from the above, the technical solution provided by the embodiments of this application, by deploying a mirror server, synchronously acquires and stores the mirror data of the IPv6 root server, enabling the rapid resolution of the IPv6 root server to be pushed down to the edge of the new metropolitan area cloud network. Client access to the mirror server is equivalent to directly connecting to the IPv6 root server. Compared with the client's traditional recursive access to the IPv6 root server through hierarchical resolution, the method of accessing the mirror server in this application is simple and effective, which can reduce the normal domain name resolution time and the top-level domain name resolution time, thereby compressing the data loading time and improving the efficiency, accuracy and response speed of IPv6 domain name resolution.

[0175] The domain name resolution method provided in this application can be executed by a terminal access terminal. This application uses the terminal access terminal executing the terminal access method as an example to illustrate the apparatus of the domain name resolution method provided in this application.

[0176] The domain name resolution device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television set (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0177] The domain name resolution device provided in this application embodiment can achieve... Figures 1 to 3 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0178] Optionally, such as Figure 5 As shown, this application embodiment also provides an electronic device 500, including a processor 501 and a memory 502. The memory 502 stores a program or instructions that can run on the processor 501. When the program or instructions are executed by the processor 501, they implement the various steps of the above-described domain name resolution method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0179] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0180] Figure 6 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0181] The electronic device 1000 includes, but is not limited to, components such as: radio frequency unit 1001, network module 1002, audio output unit 1003, input unit 1004, sensor 1005, display unit 1006, user input unit 1007, interface unit 1008, memory 1009, and processor 1010.

[0182] Those skilled in the art will understand that the electronic device 1000 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 1010 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0183] As can be seen from the above, the technical solution provided by the embodiments of this application, by deploying a mirror server, synchronously acquires and stores the mirror data of the IPv6 root server, enabling the rapid resolution of the IPv6 root server to be pushed down to the edge of the new metropolitan area cloud network. Client access to the mirror server is equivalent to directly connecting to the IPv6 root server. Compared with the client's traditional recursive access to the IPv6 root server through hierarchical resolution, the method of accessing the mirror server in this application is simple and effective, which can reduce the normal domain name resolution time and the top-level domain name resolution time, thereby compressing the data loading time and improving the efficiency, accuracy and response of IPv6 domain name resolution.

[0184] It should be understood that, in this embodiment, the input unit 1004 may include a graphics processing unit (GPU) 10041 and a microphone 10042. The GPU 10041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 1006 may include a display panel 10061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 1007 includes a touch panel 10071 and at least one of other input devices 10072. The touch panel 10071 is also called a touch screen. The touch panel 10071 may include a touch detection device and a touch controller. Other input devices 10072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0185] The memory 1009 can be used to store software programs and various data. The memory 1009 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 1009 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 109 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0186] The processor 1010 may include one or more processing units; optionally, the processor 1010 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor 1010.

[0187] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described domain name resolution method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0188] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0189] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described domain name resolution method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0190] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0191] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the domain name resolution method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0192] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0193] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0194] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A domain name resolution method, characterized in that, Applied to mirror servers, including: Synchronously acquire and store mirror data of the IPv6 root server; The mirrored data is a copy of all data stored in the IPv6 root server, or a copy of some core files stored in the IPv6 root server. Multiple edge leaf nodes are used as egress hot standby gateways so that the edge leaf nodes can receive client access requests to the IPv6 root server; The system receives the access request returned by the edge leaf node, parses the access request according to the mirror data, and returns the parsing result to the edge leaf node so that the edge leaf node returns the parsing result to the client. The method of using multiple edge leaf nodes as egress hot standby gateways includes: The multiple edge leaf nodes are grouped into pairs to obtain multiple hot standby groups; Configure the same egress hot standby gateway address for the two edge leaf nodes in each hot standby group, and synchronize the data between the two edge leaf nodes; the two edge leaf nodes include a primary node and a standby node; The process of receiving the access request returned by the edge leaf node, parsing the access request based on the mirror data, and returning the parsing result to the edge leaf node includes: The primary node is used as the target node. The access request returned by the target node is received, and the access request is parsed according to the mirror data. The parsing result is then returned to the target node. In the event of a failure of the primary node, the target node will be switched to the backup node.

2. The domain name resolution method according to claim 1, characterized in that, The process of synchronously acquiring and storing mirror data of the IPv6 root server includes: Receive sequence number query requests sent by the IPv6 root server; The IPv6 root server returns a first sequence number of its own stored data to the IPv6 root server, so that the IPv6 root server returns mirrored data if the second sequence number of its own stored data is greater than the first sequence number; the mirrored data is the same as the IPv6 root server's own stored data. Receive and store the mirror data returned by the IPv6 root server.

3. The domain name resolution method according to claim 2, characterized in that, After receiving and storing the mirrored data returned by the IPv6 root server, the method further includes: At a preset refresh interval, a region update notification is sent to the backup server of the mirror server so that the backup server updates its own stored data according to the mirror data.

4. The domain name resolution method according to claim 1, characterized in that, The process of synchronously acquiring and storing mirror data of the IPv6 root server includes: The backup server of the mirror server responds to the region update notification sent by the master server of the mirror server, and obtains and stores the mirror data of the IPv6 root server from the master server.

5. The domain name resolution method according to claim 1, characterized in that, The method further includes: Obtain monitoring data from the mirror server, including status information, traffic information, and checksum information; The monitoring data is subjected to anomaly detection, and an alarm message is sent if the detection result is abnormal.

6. The domain name resolution method according to claim 5, characterized in that, The step of performing anomaly detection on the monitoring data and sending alarm information when the detection result is abnormal includes: Acquire historical anomaly data and train an anomaly detection model based on the historical anomaly data; The monitoring data is input into the anomaly detection model for processing, and an alarm message is sent when the output indicates an anomaly.

7. A domain name resolution device, characterized in that, Applied to mirror servers, including: The acquisition module is used to synchronously acquire and store the mirror data of the IPv6 root server; wherein, the mirror data is a copy of all data stored in the IPv6 root server, or a copy of some core files stored in the IPv6 root server. The configuration module is used to set up multiple edge leaf nodes as egress hot standby gateways, so that the edge leaf nodes can receive client access requests to the IPv6 root server. The processing module is configured to receive the access request returned by the edge leaf node, parse the access request according to the mirror data, and return the parsing result to the edge leaf node so that the edge leaf node returns the parsing result to the client; The method of using multiple edge leaf nodes as egress hot standby gateways includes: The multiple edge leaf nodes are grouped into pairs to obtain multiple hot standby groups; Configure the same egress hot standby gateway address for the two edge leaf nodes in each hot standby group, and synchronize the data between the two edge leaf nodes; the two edge leaf nodes include a primary node and a standby node; The process of receiving the access request returned by the edge leaf node, parsing the access request based on the mirror data, and returning the parsing result to the edge leaf node includes: The primary node is used as the target node. The access request returned by the target node is received, and the access request is parsed according to the mirror data. The parsing result is then returned to the target node. In the event of a failure of the primary node, the target node will be switched to the backup node.

8. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the domain name resolution method as described in any one of claims 1 to 6.

9. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the domain name resolution method as described in any one of claims 1 to 6.

Images