Domain Name System (DNS) server push methods, electronic devices and computer program products

Abstract

This application provides a DNS server push method, electronic device, and computer program product. The method includes: intercepting a DNS response message sent by a first DNS server to a terminal; in response to the failure to determine the address of the first DNS server based on the DNS response message, determining the address of a second DNS server corresponding to the terminal's URL based on a pre-set URL policy list, the URL policy list including the correspondence between URLs and DNS server addresses; and sending a DNS response message to the terminal, the DNS response message carrying the address of the second DNS server. This method can at least solve the problems in related technologies where statically configured DNS schemes cannot flexibly adapt to the needs of multiple sites and multiple campuses, and the low efficiency of retrying after DNS request failure. It optimizes the processing flow after DNS request failure, improves the success rate and efficiency of domain name resolution, and reduces the processing pressure on network devices and DNS servers.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a Domain Name System (DNS) server push method, electronic device, and computer program product. Background Technology

[0002] A Broadband Remote Access Server (BRAS) is statically configured with multiple (or fixed) DNS server addresses. When a user accesses the network via Ethernet-based Point-to-Point Protocol over Ethernet (PPPoE / IPoE), the BRAS distributes these pre-configured DNS (Domain Name System) addresses (such as primary and secondary DNS) to the user terminal, ensuring that the user's device uses the specified DNS server for domain name resolution. This configuration method is commonly used in enterprise networks or carrier scenarios to achieve centralized management of DNS services (such as binding internal domain name resolution, forcing the use of secure DNS or load-balanced Anycast DNS), ensuring resolution stability and security, while avoiding the uncontrollable risks that may arise from dynamically obtaining DNS. In existing fixed-line converged service scenarios, statically configured DNS solutions cannot flexibly adapt to the access needs of multiple sites and multiple campuses, and the retry efficiency after DNS request failure is low. Summary of the Invention

[0003] This application provides a DNS server push method, electronic device, and computer program product to at least solve the problems in the related art where static DNS configuration schemes cannot flexibly adapt to the needs of multiple sites and multiple campuses, and where retrying after a DNS request fails is inefficient.

[0004] According to one embodiment of this application, a Domain Name System (DNS) server push method is provided, applied to an access gateway, including:

[0005] Intercept DNS response messages sent to the terminal by the first DNS server;

[0006] In response to the failure to determine the address of the first DNS server based on the DNS response message, the address of the second DNS server corresponding to the URL of the terminal is determined according to a pre-set Uniform Resource Locator (URL) policy list, wherein the URL policy list includes the correspondence between URLs and DNS server addresses.

[0007] The DNS response message is sent to the terminal, wherein the DNS response message carries the address of the second DNS server.

[0008] According to another embodiment of this application, a Domain Name System (DNS) server push method is also provided, applied to a terminal, including:

[0009] The access gateway receives a DNS response message, wherein the DNS response message carries the address of a second DNS server. The address of the second DNS server is the DNS server address corresponding to the URL determined by the access gateway according to a pre-set Uniform Resource Locator (URL) policy list after intercepting the DNS response message sent by the first DNS server and responding to the failure to determine the address of the first DNS server. The URL policy list includes the correspondence between URLs and DNS server addresses.

[0010] The access gateway sends a DNS request message to the second DNS server, wherein the DNS request message carries the address of the second DNS server.

[0011] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0012] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0013] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0014] Through the above embodiments of this application, the access gateway intercepts DNS response messages. If the DNS server request corresponding to the DNS response message fails, the DNS server address corresponding to the terminal's URL is re-determined and pushed to the terminal based on the DNS response message. This optimizes the processing flow after a DNS request failure, improves the success rate and efficiency of domain name resolution, and reduces the processing pressure on network devices and DNS servers. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the hardware structure of the mobile terminal used in the embodiments of the method of this application;

[0016] Figure 2 This is a flowchart of the Domain Name System (DNS) server push method according to an embodiment of this application. Figure 1 ;

[0017] Figure 3 This is a flowchart of the Domain Name System (DNS) server push method according to an embodiment of this application. Figure 2 ;

[0018] Figure 4 This is a schematic diagram illustrating domain name access according to an embodiment of this application;

[0019] Figure 5 This is a flowchart illustrating DNS server push and domain name access according to an embodiment of this application;

[0020] Figure 6 This is a schematic diagram of DNS message filling according to an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0023] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a schematic diagram of the hardware structure of the mobile terminal used in the embodiments of the method of this application. For example... Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0024] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the Domain Name System (DNS) server push method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the aforementioned method. The memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0025] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0026] This embodiment provides a method for pushing Domain Name System (DNS) servers running on the aforementioned mobile terminal or network architecture. Figure 2 This is a flowchart of the Domain Name System (DNS) server push method according to an embodiment of this application. Figure 1 ,like Figure 2 As shown, this process, applied to an access gateway, includes the following steps:

[0027] Step S202: Intercept the DNS response message sent by the first DNS server to the terminal;

[0028] Step S204: In response to the failure to determine the address of the first DNS server, the address of the second DNS server corresponding to the terminal URL is determined according to the pre-set Uniform Resource Locator (URL) policy list.

[0029] Step S206: Send a DNS response message to the terminal, wherein the DNS response message carries the address of the second DNS server.

[0030] Through the above steps S202 to S206, the access gateway intercepts DNS response messages. If the DNS server request corresponding to the DNS response message fails, the DNS server address corresponding to the terminal's URL is re-determined and pushed to the terminal based on the DNS response message. This optimizes the handling process after a DNS request failure, improves the success rate and efficiency of domain name resolution, and reduces the processing pressure on network devices and DNS servers.

[0031] DNS is one of the core infrastructures of the Internet, responsible for resolving human-readable domain names (such as www.example.com) into corresponding IP addresses (such as 192.0.2.1), thus enabling users to access network services through easy-to-remember names. Based on a distributed database architecture, it completes resolution requests through hierarchical collaboration between root servers, top-level domain servers, and authoritative name servers, and utilizes local caching to accelerate response times. DNS not only supports efficient location of global network resources but also extends its functionality to include load balancing (via Anycast technology) and security protection, making it a key technology for ensuring stable Internet operation and secure access. In this context, the DNS server push method aims to address the issue when a terminal attempts to access a URL. If the initial DNS request fails (i.e., no valid resolution result is obtained from the first DNS server), the access gateway intervenes and intelligently selects a more suitable second DNS server address based on a pre-defined URL policy list, pushing it to the terminal. Through the intelligent selection by the access gateway, the terminal can quickly switch to the best DNS server, reducing resolution latency and improving access success rate.

[0032] By enhancing the access gateway functionality, dynamic optimization of DNS resolution was achieved, reducing access failure rates caused by DNS configuration errors or server malfunctions, while also lowering network load and enhancing user experience. Specifically, by intelligently selecting a secondary DNS server, unnecessary retries after initial request failures are avoided, reducing the number of recursive queries during DNS resolution, directly lowering the average DNS resolution latency, and improving network resource utilization efficiency.

[0033] In one embodiment, after step S202, the method further includes: determining whether the request for the address of the first DNS server failed based on the DNS response message.

[0034] During a DNS request, after the access gateway intercepts the response message sent back by the first DNS server, it needs to further analyze the response message to determine whether the request was successful. If the response message indicates that the request failed, the access gateway initiates the DNS server push process. This step ensures that the push action is only performed when it is truly necessary to replace the DNS server, avoiding unnecessary resource consumption. By analyzing the received DNS response message, the access gateway can accurately identify DNS request failures, thereby triggering the intelligent DNS server push mechanism. This precise failure detection mechanism avoids the terminal blindly retrying after a DNS request failure, saving network bandwidth and processing resources. At the same time, it ensures the necessity and effectiveness of DNS server push, improving overall network performance and end-user satisfaction.

[0035] Furthermore, determining whether a request to the first DNS server's address failed based on the DNS response message can include: checking the rcode value in the FLAG field of the DNS response message. Specifically, it can be determined whether the rcode value in the FLAG field is 0. If the result is no, the request to the first DNS server's address failed; if the result is yes, the request to the first DNS server's address succeeded. In the DNS protocol, the FLAG field of the response message contains an important rcode value used to indicate the request status. An rcode value of 0 usually indicates a successful request, while other non-zero values ​​may represent various error codes. For example, a value of 1 indicates a format error, meaning the server cannot understand the requested message; a value of 2 indicates a server failure, meaning the server cannot process the request due to a problem. By checking the rcode value, the access gateway can quickly determine whether the first DNS server successfully processed the request. For example, when the rcode value is 1, it means that the first DNS server rejected the request. This may be due to server configuration errors or permission issues. In this case, the access gateway will determine that the request failed and initiate the subsequent DNS server push process.

[0036] Using rcode values ​​for failure detection is an efficient and standard method that adheres to the design principles of the DNS protocol, ensuring that the access gateway can accurately identify the status of DNS requests. In this way, the access gateway can respond promptly to DNS request failure events and quickly take remedial measures, avoiding long waits and ineffective retries, thereby significantly improving the efficiency of DNS resolution and the internet experience for end users.

[0037] In one embodiment, prior to step S206, the method further includes adding a first field and a second field to the resource record area of ​​the DNS response message, wherein the first field is used to carry a DNS server update indication and the second field is used to carry the address of a second DNS server.

[0038] To notify the terminal of DNS server updates, the access gateway adds two fields to the resource record area of ​​the DNS response message. The first field serves as a DNS server update indicator, informing the terminal that the DNS server configuration has changed; the second field carries the new DNS server address, i.e., the address information of the second DNS server. For example, when the access gateway detects that the first DNS server is not functioning properly, it adds these two fields to the DNS response message sent to the terminal, guiding the terminal to update its DNS configuration to point to the better second DNS server. By adding specific indicator fields and DNS server addresses to the DNS response message, the access gateway can effectively convey DNS server update information to the terminal, ensuring that the terminal can adjust its DNS settings in a timely manner and avoiding network access problems caused by DNS configuration lag. This not only improves the flexibility and adaptability of DNS resolution but also enhances the network's self-healing capabilities. Even if the DNS server fails or requires maintenance, it ensures that the terminal's network access is unaffected, maintaining high availability of network services and continuity of user experience.

[0039] Furthermore, adding a first field and a second field to the resource record area of ​​the DNS response message may include: the resource record area includes the answer zone, the authoritative zone, and the supplementary zone, and adding a first field and a second field to the answer zone, the authoritative zone, or the supplementary zone of the resource record area of ​​the DNS response message.

[0040] The resource record area of ​​a DNS response message is divided into three parts: the response area, the authoritative area, and the additional information area. Each area has its specific function. The access gateway can insert a first field (DNS server update indication) and a second field (address of the second DNS server) into one of these areas. For example, if a terminal's DNS request is to obtain authoritative information for a specific domain name, the access gateway might choose to add these fields to the authoritative area so that the terminal can immediately recognize the DNS server update requirement and obtain the new DNS server address upon receiving the DNS response. Inserting the DNS server update indication and new address information into different areas of the DNS response message allows for flexible communication of DNS update information according to different scenarios. This method not only ensures the effectiveness of information transmission but also adheres to the DNS protocol specifications, avoiding significant modifications to the existing network architecture. In practical applications, regardless of whether the terminal's DNS request is for domain name resolution, authoritative information confirmation, or other purposes, the access gateway can insert update information at appropriate locations to ensure that the terminal can correctly understand and respond to changes in the DNS server, thereby improving the stability and efficiency of network access.

[0041] This application embodiment also provides a method for pushing Domain Name System (DNS) servers. Figure 3 This is a flowchart of the Domain Name System (DNS) server push method according to an embodiment of this application. Figure 2 ,like Figure 3 As shown, when applied to a terminal, the process includes the following steps:

[0042] Step S302: Receive a DNS response message sent by the access gateway. The DNS response message carries the address of the second DNS server. The address of the second DNS server is the DNS server address corresponding to the URL determined by the access gateway according to the pre-set Uniform Resource Locator (URL) policy list after intercepting the DNS response message sent by the first DNS server and responding to the failure to determine the address of the first DNS server.

[0043] Step S304: Send a DNS request message to the second DNS server through the access gateway, wherein the DNS request message carries the address of the second DNS server.

[0044] Through the steps S302 to S304 above, the terminal receives the DNS response message, obtains the new DNS server address corresponding to the URL re-determined by the access gateway from the DNS response message, optimizes the handling process after DNS request failure, improves the success rate and efficiency of domain name resolution, and reduces the processing pressure on network devices and DNS servers.

[0045] When a terminal receives a DNS response message, it will find that it contains the address of a second DNS server pushed by the access gateway. This means that, for some reason, the first DNS server that the terminal originally tried to contact failed to respond to its request. In this case, the terminal will re-initiate the DNS request based on the new DNS server address carried in the DNS response message, directly querying the required domain name information from the second DNS server. For example, when a user tries to access an educational resource website, if the initial DNS request fails due to the first DNS server being overloaded, the terminal will re-initiate the request based on the address of the second DNS server pushed by the access gateway, thus avoiding long wait times and multiple retries, and improving access speed.

[0046] The terminal-side DNS server push mechanism avoids access delays and failures caused by DNS server failures or misconfigurations by directly utilizing new DNS server addresses pushed by the access gateway. This method simplifies the terminal's DNS resolution process and improves response speed, especially in complex network environments and where DNS server load is uneven, significantly enhancing the end-user's network access experience. Simultaneously, it promotes the rational allocation of network resources, reduces invalid DNS requests, thereby lowering the risk of network congestion and enhancing the overall stability and security of the network.

[0047] Preferably, before step S304 above, the method further includes: obtaining a DNS server update indication from a newly added first field in the resource record area of ​​the DNS response message; and in response to obtaining the DNS server update indication, obtaining the address of a second DNS server from a newly added second field in the resource record area of ​​the DNS response message.

[0048] Upon receiving a DNS response message, the terminal first checks the newly added first field in the resource record area to obtain a DNS server update indication. Once an update indication is detected, the terminal reads the address of the new second DNS server from the second field and then uses this address to re-initiate the DNS request. For example, when a user attempts to access an online course platform, if the first DNS request fails, the terminal will read the update indication from the DNS response message, obtain the new DNS server address, and then directly send a request to this new DNS server, hoping to obtain a faster resolution response. This terminal-side response mechanism to DNS server update indications ensures that the terminal can promptly recognize changes in the DNS server and take action, avoiding network access obstacles caused by outdated DNS configurations.

[0049] In this embodiment of the application, the resource record area may include an answer area, an authorization area, and an additional area, and the first field and the second field are both located in the answer area, authorization area, or additional area of ​​the resource record area.

[0050] The resource record area of ​​a DNS response message is a crucial part for carrying DNS server response information. It is divided into the answer zone, authoritative zone, and supplementary zone. When pushing DNS server update instructions and new addresses, the access gateway chooses to insert the first and second fields in one of these three zones. For example, if a terminal's DNS request is to obtain the resolution result for a specific domain name, the access gateway might choose to insert these fields in the answer zone so that the terminal can directly find the update instruction and the new DNS server address in the resolution result. Placing the DNS server update instruction and new address information in different parts of the resource record area ensures accurate communication of information based on the purpose and context of different DNS requests.

[0051] In this embodiment, accurate DNS node addresses that can provide domain name resolution services are pushed to the terminal. By identifying the FLAG field in the DNS response message (mainly different rcode values, representing success, failure, or other statuses of the response message), the access gateway can pre-determine whether the user request has failed; further, based on URL-based policy management, the DNS addresses that can be determined to provide resolution services are accurately pushed, and the terminal's DNS address is updated.

[0052] The access gateway uses URL-related ACLs (which can be statically configured, dynamically issued, or dynamically obtained from DNS servers) to configure different DNS servers. When a user's DNS request fails, different ACLs are matched based on the URL accessed. The response message pushes the DNS node that can resolve the corresponding domain name to update the terminal's DNS service address, thereby enabling fixed-line users to access multiple sites and multiple campuses. This solves the problem of static DNS not being able to respond completely and avoids the inefficiency of multiple requests and recursive requests during retries.

[0053] As fixed-line services continue to grow, user access demands are expanding. However, traditional dedicated DNS services within campus / enterprise networks often do not communicate with public DNS servers. During the process of querying root name servers, they cannot find the internal IP address, thus affecting user access. Existing technologies also present significant problems in terms of efficiency and cost.

[0054] Figure 4 This is a schematic diagram of domain name access according to an embodiment of this application, such as... Figure 4As shown, Company A has an internal access domain name www.qiye.a.com, corresponding to the IP address 10.0.0.1, and the corresponding domain name resolution server is DNS a; on the Internet, it has an access domain name www.hulianwang.com, corresponding to the IP address 20.0.0.1, and the corresponding domain name resolution servers are DNS1 and DNS2.

[0055] Campus B has an internal access domain name www.xiaoyuan.b.com, a corresponding IP address of 30.0.0.1, and a DNS server of DNS b.

[0056] Because accessing the campus network requires DNS a and DNS b resolution, users in this scenario will always fail to access the network. In one embodiment of a related technology, the access gateway provides a DNS proxy service, requesting domain name resolution services from all DNS servers for DNS requests initiated by the terminal. For example, the user's DNS request will be sent simultaneously to all DNS servers (1, 2, a, b), and the server that can resolve the request will return the correct domain name resolution result. However, this solution amplifies DNS traffic in the network and increases the processing pressure on the DNS servers.

[0057] In another embodiment of a related technology, the access gateway provides a URL resolution service to terminate the user's DNS request. It then maps the corresponding DNS service address using its local URL resolution capabilities and re-initiates DNS resolution, sending the request precisely to a DNS server that can provide domain name resolution services. However, this approach processes URL resolution for each user's DNS request, increasing the processing load on the access gateway and reducing DNS service efficiency.

[0058] To address the aforementioned issues, this application proposes a novel DNS server push and domain name access method. Figure 5 This is a flowchart of DNS server push and domain name access according to an embodiment of this application, such as... Figure 5 As shown, it includes:

[0059] S501: The terminal is assigned a default DNS upon going online, which is DNS1.

[0060] S502, when a terminal accesses a webpage, it initiates a DNS request to DNS1 through the access gateway;

[0061] S503, DNS1 cannot resolve the domain name, and a DNS response is returned;

[0062] S504, the access gateway intercepts the response message returned by DNS1, finds the correct DNS to be DNSa, and fills in the resolution response message to update the DNS service address;

[0063] S505, the terminal initiates a secondary DNS request to DNSa through the access gateway;

[0064] S506, DNSa resolves the corresponding domain name IP address and returns it to the terminal through the access gateway.

[0065] The terminal is assigned a default DNS upon going online and makes a request based on DNS1. Since the user is actually accessing the domain name of enterprise A, DNS1 returns a failure. The access gateway detects the resolution failure through the FLAG flag in the response message and intervenes in the failure return process. Based on the ACL policy behavior of the URL, it identifies the DNS service address requested by the user to access enterprise A as DNSa. The access gateway adds the new DNS server address DNSa to the response message and pushes it. The terminal updates its local DNS address to DNSa and initiates a second request. DNSa can resolve the domain name and returns the resolved domain name.

[0066] BRAS / BNG and other access gateways intercept failed DNS request return messages from users, and based on a URL-based strategy, push the correct DNS node to update the terminal's DNS address, thus meeting the needs of secondary requests and improving efficiency and success rate. Specific functionalities and implementation requirements are as follows:

[0067] 1. Intercept DNS messages that fail to resolve terminal requests. In this embodiment, the access gateway filters user messages, parses DNS response messages, and determines the value of the rcode bit in the Flag field. When the value is equal to 1, 2, 3, 4, or 5, it means that the DNS server cannot resolve the domain name request. At this time, the process proceeds to step 2 to determine the URL policy and accurately identify the DNS address that can provide the service.

[0068] 2. URL-based policies accurately anchor DNS service addresses. In this embodiment, the access gateway establishes a URL-based policy list locally on the device through static configuration, network management system distribution, or dynamic DNS acquisition. After intercepting the DNS failure response message in step 1, the URL of the domain name request in the message is further parsed, and the local policy is matched to complete the lookup of the DNS service address, which is then pushed to the user.

[0069] 3. Populate the new DNS service address in the DNS message and push it to the user along with the DNS response message. Figure 6 This is a schematic diagram of DNS message filling according to an embodiment of this application, as shown below. Figure 6 As shown, new fields are added after the resource record areas (including the answer zone, authoritative zone, and supplementary zone) in the DNS response message to fill in the gaps. For example, after the resource data, an additional 32 / 128 bits of address space is added to carry the updated DNS service address.

[0070] 4. The terminal device receives the DNS response message and updates the DNS service address. In this embodiment, an additional field is added after the resource record area (including the answer zone, authoritative zone, and supplementary zone) of the DNS response message for filling. For example, after the resource data, an 8-bit replace flag space is added to carry instructions on how to replace the DNS service address. When the terminal device receives a flag with a specific indication bit, it performs a specific update action. The values ​​of the replace field are designed as follows:

[0071] 0x00 indicates no update and is used in response messages for successful resolution; in this case, the DNS IP address is 0x00.

[0072] 0x01 indicates a scenario where an update is needed, but the access gateway cannot update it; in this case, the DNS IP address is 0x00.

[0073] 0x02 indicates that it has been updated, and the DNS IP address entered in this case is the address used for the update;

[0074] FxFF represents an error and is used in all abnormal scenarios, in which case the DNS IP address is 0x00.

[0075] The remaining values ​​are reserved for future use in other functional scenarios.

[0076] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to 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 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 device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0077] This embodiment also provides a Domain Name System (DNS) server push device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated. The device includes:

[0078] The interception module is used to intercept DNS response messages sent to the terminal by the first DNS server;

[0079] The determination module is used to determine the address of the second DNS server corresponding to the terminal URL based on a pre-set list of Uniform Resource Locators (URL) policies in response to the failure to determine the address of the first DNS server.

[0080] The first sending module is used to send a DNS response message to the terminal, wherein the DNS response message carries the address of the second DNS server.

[0081] This embodiment also provides a Domain Name System (DNS) server push device, which includes:

[0082] The receiving module is used to receive DNS response messages sent by the access gateway. The DNS response messages carry the address of the second DNS server. The address of the second DNS server is the DNS server address corresponding to the URL determined by the access gateway according to the pre-set Uniform Resource Locator (URL) policy list after intercepting the DNS response messages sent by the first DNS server and responding to the failure to determine the address of the first DNS server.

[0083] The second sending module is used to send a DNS request message to the second DNS server through the access gateway, wherein the DNS request message carries the address of the second DNS server.

[0084] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0085] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0086] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0087] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0088] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0089] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0090] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0091] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A domain name system (DNS) server push method, the method comprising: The application is applied to an access gateway, and comprises: intercepting a DNS response message sent by a first DNS server to a terminal; in response to determining that an address of the first DNS server fails to be requested according to the DNS response message, determining an address of a second DNS server corresponding to a uniform resource locator (URL) of the terminal according to a pre-set URL strategy list, wherein the URL strategy list comprises a corresponding relationship between a URL and a DNS server address; adding a first field and a second field in a resource record area of the DNS response message, wherein the first field is used to carry a DNS server update indication, and the second field is used to carry the address of the second DNS server; sending the DNS response message to the terminal, wherein the address of the second DNS server is carried in the DNS response message.

2. The method of claim 1, wherein, After intercepting the DNS response message sent by the first DNS server to the terminal, the method further comprises: determining whether the address of the first DNS server fails to be requested according to the DNS response message.

3. The method of claim 2, wherein, Determining whether the address of the first DNS server fails to be requested according to the DNS response message comprises: determining whether the address of the first DNS server fails to be requested according to a return code (rcode) value in a flag (FLAG) field of the DNS response message.

4. The method of claim 1, wherein, Adding the first field and the second field in the resource record area of the DNS response message comprises: the resource record area comprises an answer area, an authority area and an additional area, and the first field and the second field are added in the answer area, the authority area or the additional area of the resource record area of the DNS response message.

5. A domain name system (DNS) server push method, the method comprising: The application is applied to a terminal, and comprises: receiving a DNS response message sent by an access gateway, wherein the address of a second DNS server is carried in the DNS response message, the address of the second DNS server is a DNS server address corresponding to a uniform resource locator (URL) determined by the access gateway according to a pre-set URL strategy list in response to determining that an address of a first DNS server fails to be requested after intercepting a DNS response message sent by the first DNS server, the URL strategy list comprises a corresponding relationship between a URL and a DNS server address, and a first field and a second field are added in a resource record area of the DNS response message, wherein the first field is used to carry a DNS server update indication, and the second field is used to carry the address of the second DNS server; sending a DNS request message to the second DNS server through the access gateway, wherein the address of the second DNS server is carried in the DNS request message.

6. The method of claim 5, wherein, Before sending the DNS request message to the second DNS server through the access gateway, the method further comprises: obtaining a DNS server update indication from the first field added in the resource record area of the DNS response message; in response to obtaining the DNS server update indication, obtaining the address of the second DNS server from the second field added in the resource record area of the DNS response message.

7. The method of claim 6, wherein, the resource record area comprises an answer area, an authority area and an additional area, and the first field and the second field are located in the answer area, the authority area or the additional area of the resource record area.

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, the processor, when executing the computer program, realizes the steps of the method in any one of claims 1 to 4, 5 to 7.

9. A computer program product, characterised in that, a computer program, which, when executed by a processor, realizes the steps of the method in any one of claims 1 to 4, 5 to 7.

Images