WO2021108993A1

WO2021108993A1 - Systems and methods for load control of domain name system server

Info

Publication number: WO2021108993A1
Application number: PCT/CN2019/122731
Authority: WO
Inventors: Yanqi ZHAO; Weiwei Li; Jian Yang
Original assignee: Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date: 2019-12-03
Filing date: 2019-12-03
Publication date: 2021-06-10
Also published as: CN114731338A; CN114731338B

Abstract

Systems and methods for load control of a Domain Name System (DNS) server. A system may include a communication interface configured to receive a DNS query from a user device. The DNS query may include at least one DNS packet. The system may also include at least one processor coupled to the communication interface. The at least one processor is configured to extract information indicative of a source IP address from the DNS packet and assign a predetermined control strategy to the DNS packet based on the source IP address. Moreover, the at least one processor is further configured to mark an unused field of the DNS packet based on the assigned predetermined control strategy and transmit the marked DNS packet to the DNS server.

Description

SYSTEMS AND METHODS FOR LOAD CONTROL OF A DOMAIN NAME SYSTEM SERVER

TECHNICAL FIELD

The present disclosure relates to systems and methods for load control of a Domain Name System (DNS) server, and more particularly to, systems and methods for controlling the IPv6 query load of a DNS server.

BACKGROUND

Domain names are widely used to identify resources in a unique way such that the names are recognized by different hosts, networks, protocol families, internets, and administrative organizations. Domain Name System (DNS) helps users and network devices discover other devices, by translating human-readable domain names into IP addresses, a process known as domain name “resolution. ” Users can use domain names to access resources associated with the domain name by sending a DNS query. A DNS query is essentially a request to look up the host IP address stored in a DNS server that is corresponding to the particular domain name. This is analogous to looking up a phone number in a phone book using the recipient's name. To fulfill the request, a DNS query with an appropriate type must be passed to the DNS server for resolution.

Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are commonly used DNS query types. Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP) . It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 uses 32-bit addresses that limit the address space to 2 ³². IPv6 is a new version of the internet Protocol (IP) . A primary motivation for IPv6 is to offer more IP addresses as the previous version, IPv4 offers a limited address space which is almost exhausted. Even though IPv4 and IPv6 are both widely used, the two protocols are not interoperable, meaning IPv4 hosts/servers cannot communicate with IPv6 hosts/servers at the protocol level. In general, as existing infrastructures have limited capability for processing IPv6 type DNS queries, it is important to control the IPv6 query load to DNS servers.

To control the load of resolving IPv6 queries by the DNS servers, existing solutions include updating the resolver at the user end to control the IPv6 query load, and establishing dedicated IPv6 infrastructures including routers, switches and servers etc. to provide IPv6 DNS service (e.g., using ipv6. baidu. com) . However, both solutions suffer from high costs. For example, updating the resolver result in a huge volume of software updates and the interruption of services caused by the update. Dedicated Ipv6 infrastructure requires maintaining the extra domain names (e.g., both a regular domain name and an IPv6 domain name need to be maintained for baidu. com) and establishing the new infrastructures.

Embodiments of the disclosure address the above problems by systems and methods for controlling the load of IPv6 queries of a DNS server to make the DNS server and more reliable and efficient.

SUMMARY

Embodiments of the disclosure provide a system for performing load control of a Domain Name System (DNS) server. An exemplary system may include a communication interface configured to receive a DNS query from a user device. The DNS query may include at least one DNS packet. The system may also include at least one processor coupled to the communication interface. The at least one processor is configured to extract information indicative of a source IP address from the DNS packet and assign a predetermined control strategy to the DNS packet based on the source IP address. Moreover, the at least one processor is further configured to mark an unused field of the DNS packet based on the assigned predetermined control strategy and transmit the marked DNS packet to the DNS server.

Embodiments of the disclosure also provide a method for load control of a DNS server. An exemplary method may include receiving a DNS query from a user device, wherein the DNS query comprising at least one DNS packet. The method may further include extracting information indicative of a source IP address from the DNS packet and assigning a predetermined control strategy to the DNS packet based on the source IP address. The method may also include marking an unused field of the DNS packet based on the assigned predetermined control strategy and transmitting the marked DNS packet to the DNS server.

Embodiments of the disclosure further provide a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method for load control of a DNS server. The method may include receiving a DNS query from a user device, wherein the DNS query comprising at least one DNS packet. The method may further include extracting information indicative of a source IP address from the DNS packet and assigning a predetermined control strategy to the DNS packet based on the source IP address. The method may also include marking an unused field of the DNS packet based on the assigned predetermined control strategy and transmitting the marked DNS packet to the DNS server.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a schematic diagram of an exemplary communication system equipped with a load control system for performing load control of a DNS server, according to embodiments of the disclosure.

FIG. 2 illustrates a block diagram of an exemplary load control system for performing load control of a DNS server, according to embodiments of the disclosure.

FIG. 3 illustrates a flowchart of an exemplary method for load control of a DNS server, according to embodiments of the disclosure.

FIG. 4 illustrates a flowchart of an exemplary method for determining an accessibility of a requested domain name, according to embodiments of the disclosure.

FIG. 5 illustrates an exemplary method for assigning predetermined control strategies, according to embodiments of the disclosure.

FIG. 6 illustrates an exemplary DNS packet with Extension Mechanisms for DNS, according to embodiments of the disclosure.

DETAILED DESCRIPTION

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

FIG. 1 illustrates a schematic diagram of an exemplary communication system 100 equipped with a load control system 160 for performing load control of a DNS server, according to embodiments of the disclosure. As shown in FIG. 1, a user device 110 may request access of a service support node 130 (e.g., DNS servers 170) through a network 120 to retrieve information.

In some embodiments, user device 110 may include any suitable device that can interact with a user, e.g., a smart phone, a tablet, a wearable device, a computer, or the like. In some embodiments, user device 110 may be a standalone device or integrated inside another device, e.g., a vehicle, a mobile phone, a wearable device, a camera, etc.

In some embodiments, network 120 may be the Internet or any other packet switched network (PSN) that groups and sends data in the form of small packets between a source and destination node such as a HTTPDNS 140 and a localDNS 150. For example, network 120 may be implemented on local networks such as Wireless Local Area Network (WLAN) , a Wide Area Network (WAN) , a cellular network, a satellite communication network, or the like.

Service support node 130 may be a host device associated with a particular domain name. User device 110 receives the domain name, such as a URL, input by the user. In order to access service support node 130 at the correct host address, user device 110 has to first transmit a DNS query to a DNS resolution system 105 to have the domain name translated into the host IP address. In some embodiments, user device 110 may include an operating system (OS) and a resolver as part of the OS. The resolver may be responsible for initiating and sequencing the DNS queries that ultimately lead to a full resolution (translation) of the resource sought (e.g., translation of a domain name into an IP address) . In some embodiments, the resolver may be a local DNS cache or a single stub resolver.

In some embodiments, DNS resolution system 105 may be implemented with parallel DNS resolution routes, including an http DNS route through HTTPDNS 140 and a local DNS route through localDNS 150. The https DNS route may be the main route with the local DNS route as a backup. Therefore, the DNS query sent by user device 110 may first either be received by HTTPDNS 140 or localDNS 150. Under normal situations, about 90%of the DNS queries sent from user device 110 would go through HTTPDNS 140, and about 10%of the DNS queries may be handled by localDNS 150. HTTPDNS 140 may partially resolve the IP address of the requested domain name of the DNS query and send the DNS query to a root-level DNS server if it cannot resolve it. LocalDNS 150 on the other hand, may oftentimes lack the capability to fully resolve the DNS queries, and pass a vast majority of DNS queries on to DNS server 170 for resolution. When breakdown happens to HTTPDNS 140, all DNS queries may go through localDNS 150 instead, and thus DNS server 170 may become overloaded. As a result, DNS resolution may fail or slow down and user experience may be impaired.

In order to reduce the pressure on DNS server 170, the present disclosure provides a load control system 160 in DNS resolution system 105as an extra layer to pre-process the DNS queries before the DNS queries reach DNS server 170. In some embodiments, load control system 160 may locate between HTTPDNS 140/localDNS 150 and DNS server 170. Load control system 160 may pre-process a DNS query and assign one of predetermined control strategies if the DNS query is an IPv6 query. DNS server 170 may then resolve/process the pre-processed IPv6 query based on the assigned predetermined control strategy. Consequently, the processing load of DNS server 170 may be significantly reduced. Without load control system 160, DNS server 170 may easily become overloaded because of the excessive IPv6 queries it has to resolve.

In some embodiments, HTTPDNS 140 may be a DNS over HTTP (DoH) server that is configured to send DNS queries and get DNS responses over HTTP using https Uniformed Resource Identifier (URI) . Each DNS query and its response may be mapped into an HTTP exchange. A DoH server (e.g., HTTPDNS 140) may establish default media formatting types for requests/queries and responses but uses normal HTTP content negotiation mechanisms. In addition to this media type negotiation, DoH aligns DNS queries with HTTP features such as caching, redirection, proxying, authentication, and compression. All those features make the DoH queries more reliable and efficient comparing to traditional DNS over User Datagram Protocol (UDP) queries. In some embodiments, HTTPDNS 140 may not be able to fully resolve the resource sought by the DNS query, and it may direct the DNS query to the right server (e.g., DNS server 170) .

In some embodiments, localDNS 150 may be a local DNS server provided by local network operator (e.g., the provider and operator for network 120) . For example, localDNS 150 may be a local DNS server provided by AT&T ^TM, T-Mobile ^TM, or China Mobile ^TM. In another example, localDNS 150 may be a local DNS server provided by the school if network 120 is a campus network. In some embodiments, user device 110 may choose a local DNS server to send the DNS query by manually setting up the IP address of the local DNS server being used. In some embodiments, localDNS 150 may cache some IP addresses. If the requested domain name matches one of the IP addresses cached in localDNS 150, user device 110 may directly receive revolved IP address from localDNS 150. In most cases, however, the requested domain name does not match any of the IP address cached in localDNS 150, and accordingly, the DNS query may be transmitted to DNS server 170 for further processing.

When HTTPDNS 140 is down, all DNS queries would be directed to localDNS 150 instead. Because of the limited processing capability (e.g., limited IP address that can be cached in the local DNS server) of HTTPDNS 140, without proper load control mechanism such as setting up load control system 160 before DNS server 170, DNS server 170 may experience an excessive volume of DNS queries. As DNS server 170 may normally have limited resource to fully resolve IPv6 queries, IPv6 query load needs to be controlled to prevent DNS server 170 from breaking down because of the excessive IPv6 query load. This disclosure provides load control system 160 before DNS server 170 to control the IPv6 query load.

In some embodiments, load control system 160 may be implemented as a physical apparatus, a cloud software, an application on HTTPDNS 140, localDNS 150 and/or DNS server 170, or any other suitable system. Load control system 160 may be a general-purpose server or a proprietary device specially designed for load control. It is contemplated that, load control system 160 can be a stand-alone system (e.g., a server) or an integrated component of a stand-alone server (e.g., a part of localDNS 150 and/or DNS server 170) .

In some embodiments, DNS queries transmitted from localDNS 150 may be pre-processed by load control system 160 (e.g., filtering DNS query based on the DNS query type, determining requested domain name’s accessibility, assigning predetermined control strategy and marking the DNS query based on the assigned predetermined control strategy) , which will be disclosed in detail below. Because load control system 160 may control the load of IPv6 queries to be fully resolved by DNS server 170, setting up load control system 160 before DNS server 170 would prevent DNS server 170 from overload, particularly when HTTPDNS 140 is down.

In some embodiments, load control system 160 may transmit the pre-processed DNS queries to DNS server 170 for further processing. In some embodiments, DNS server 170 may be an authoritative server that stores a part of the domain space which includes the requested domain name. In some embodiments, DNS server 170 may process the DNS queries based on the pre-processed result of load control system 160.

FIG. 2 illustrates a block diagram of an exemplary load control system 160 for performing load control of a DNS server, according to embodiments of the disclosure. Consistent with the present disclosure, load control system 160 may receive a DNS query 201 from localDNS 150. Load control system 160 may be configured to pre-process DNS query 201 based on the control method disclosed in detail below and transmit a pre-processed DNS query 203 to DNS server 170 to control the load of DNS server 170. Although FIG. 2 shows load control system 160 as a stand-alone system, it is contemplated that, in some embodiments, load control system 160 may be a distributed system that is partially implemented by HTTPDNS 140/local DNS 150, and partially implemented by DNS server 170. For example, in some embodiments, DNS query filtering may be implemented by HTTPDNS 140/local DNS 150 and the remaining functions may be implemented by DNS server 170.

In some embodiments, as shown in FIG. 2, load control system 160 may include a communication interface 202 and a processor 204. In some embodiments, load control system 160 may also include a memory 206, and a storage 208. In some embodiments, load control system 160 may have different modules in a single device, such as an integrated circuit (IC) chip (implemented as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA) ) , or separate devices with dedicated functions. In some embodiments, one or more components of load control system 160 may be located in a cloud computing environment or may be alternatively in a single location or distributed locations. Components of load control system 160 may be in an integrated device or distributed at different locations but communicate with each other through a network (not shown) .

Communication interface 202 may receive data (e.g., DNS query 201) from localDNS 150 and transmit data (e.g., pre-processed DNS query 203) to DNS server 170 via communication cables, a Wireless Local Area Network (WLAN) , a Wide Area Network (WAN) , wireless networks such as radio waves, a cellular network, satellite communication links, and/or a local or short-range wireless network (e.g., Bluetooth ^TM) , or other communication methods. In some embodiments, communication interface 202 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection. As another example, communication interface 202 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented by communication interface 202. In such an implementation, communication interface 202 can send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information via a network.

Consistent with some embodiments, communication interface 202 may further provide the received data to storage 208 for storage or to processor 204 for processing. Communication interface 202 may also receive DNS queries processed by processor 204, and provide the pre-processed DNS queries (e.g., pre-processed DNS query 203) to DNS server 170.

Processor 204 may include any appropriate type of general-purpose or special-purpose microprocessor, digital signal processor, or microcontroller. Processor 204 may be configured as a separate processor module dedicated to control load of a DNS server. Alternatively, processor 204 may be configured as a shared processor module for performing other functions unrelated to load control (e.g., processor 204 may be a shared processor module on localDNS 150 and/or a share processor module on DNS server 170) .

As shown in FIG. 2, processor 204 may include multiple modules, such as an information extracting unit 210, a DNS query type determination unit 212, a domain name accessibility determination unit 214, a control strategy determination unit 216 and a DNS packet marking unit 218, and the like. These modules (and any corresponding sub-modules or sub-units) can be hardware units (e.g., portions of an integrated circuit) of processor 204 designed for use with other components or software units implemented by processor 204 through executing at least part of a program. The program may be stored on a computer-readable medium, and when executed by processor 204, it may perform one or more functions. Although FIG. 2 shows units 210-218 all within one processor 204, it is contemplated that these units may be distributed among multiple processors located near or remotely with each other.

After receiving DNS query 201 from localDNS 150, information extracting unit 210 may be configured to unpack DNS query 201 and extract basic information encoded in DNS query 201. In some embodiments, the basic information may include the type of DNS query 201 (e.g., whether the DNS query is an IPv4 query or an IPv6 query) , the requested domain name and the source IP address of DNS query 201. For example, information extracting unit 210 may extract family type (e.g., A represents an IPv4 query, AAAA represents an IPv6 query) of DNS query 201. The type of DNS query 201 may later be used to filter the DNS query for later processes such as determining requested domain name accessibility, determining the predetermined control strategy and marking the DNS packet.

In some embodiments, the requested domain name may be part of the input provided by the user. For example, “www. example. com” may be a domain name included in DNS query 201. In some embodiments, the source IP address may be the IP address of the endpoint (e.g., IP address of user device 110) . The source IP address may be used in later steps (described in detail below) for determining predetermined control strategies assigned to DNS query 201. In some embodiments, the type of DNS query, the requested domain name and the source IP address of DNS query 201 may be stored in memory 206 and/or storage 208 as reference of DNS query 201.

After extracting basic information of DNS query 201, DNS query type determination unit 212 may determine the type of DNS query 201 and filter DNS query 201 accordingly. For example, DNS query 201 with a family type A may represent an IPv4 query, DNS query 201 with a family type AAAA may represent an IPv6 query. In some embodiments, DNS query type determination unit 212 may filter the IPv6 query and pass the IPv4 query to DNS server 170 for full resolution through communication interface 202. IPv6 query may be further processed within load control system 160 before being transmitted to DNS server 170. For example, DNS query type determination unit 212 may perform filtering according to Table 1:

Table 1

After filtering DNS query 201 based on DNS query type, domain name accessibility determination unit 214 may determine an accessibility of the requested domain name based on a predetermined black and white list. In some embodiments, the predetermined black and white list may include records of domain names. Each record may include several fields, such as a key, a value of key, and an accessibility value of the domain name. For example, a record of a domain name may be shown in Table 2:

Key	value	Accessibility value
www. example. com	XXX	B/W

Table 2

In some embodiments, the key may be domain name. In some embodiments, the record may assign a value to the key for indexing purpose. For example, the value of the key (i.e., the domain name) in a record may be the hash value of the key. A hash is a function that converts one value to another and may be used for domain name indexing. It is contemplated that other suitable indexing method may also be used for keeping record of domain names on the predetermined black and white list.

In some embodiment, accessibility value may represent the accessibility of the domain name based on the group of the endpoint (e.g., user device 110) and/or actions requested by the endpoint. In a simplified example, accessibility value may be either “black” or “white. ” A “white” accessibility value indicates the domain name is accessible to all endpoints with all kinds of actions. A “black” accessibility value indicates there is some limitation on the accessibility of the domain name. In some embodiments, if the requested domain name in DNS query 201 is listed as a record on the predetermined black and white list and the accessibility value associated with the domain name is white, DNS query 201 may be transmitted to DNS server 170 for full resolution. Otherwise, DNS query 201 may stay in load control system 160 for further processing.

It is contemplated that the accessibility value is not limited to black and white. The accessibility value can be other binary values, such as “0” and “1. ” It could also take more than two values so that different accessibility limitations (e.g., strategies with more comprehensive rules on accessibility of domain names based on source IP address of the endpoint and/or the action requested) may be applied to the domain names. For example, different colors (e.g., more than 2 colors) , or other indicators may be used.

In some embodiments as disclosed above, on the predetermined black and white list, a domain name may be indexed by the hash value of the domain name. When determining the accessibility of the requested domain of DNS query 201, domain name accessibility determination unit 214 may further be configured to hash the requested domain name and compare the hash value of the requested domain name to the hash value listed on the predetermined black and white list. For example, domain name accessibility determination unit 214 may look up the hash value of the requested domain name on the predetermined black and white list to see if the hash value of the requested domain name matches the hash value index of a domain name record. If the hash value of the requested domain name matches one of the hash values listed, and domain name corresponding to the hash value listed is accessible without restrictions (e.g., the accessibility value listed is white in the simplified example) , DNS query 201 may be transmitted to DNS server 170 for full resolution through communication interface 202. Otherwise, if the matched domain name is not listed as accessible without restrictions (e.g., the accessibility value listed is black in the simplified example) , or the requested domain name is not listed on the predetermined black and white list, DNS query 201 will stay in load control system 160 for further processing.

After determining the requested domain name accessibility, control strategy determination unit 216 may determine and assign a predetermined control strategy to DNS query 201 based on the source IP address of DNS query 201. For example, as illustrated in FIG. 5, source IP address may be grouped into different groups and be assigned different predetermined control strategies. In a simplified example, source IP addresses may be grouped according to whether the user is a private network user (e.g., source IP address group 1) or a public network user (e.g., source IP address group 2) . For example, DNS queries originated from a private network may be fully resolved by DNS server 170. On the other hand, DNS queries originated from a public network user may be denied access to all IPv6 domain names and thus the DNS query sent form the user would not be fully resolved by DNS server 170 when received by DNS server 170. Control strategy determination unit 216 may determine and assign the control strategy to DNS query 201 accordingly. DNS server 170 may resolve DNS query 201 based on the assigned predetermined control strategy. This may save the computing power of DNS server 170.

It is contemplated that the source IP addresses may also be grouped based on other methods/rules and may be assigned different predetermined control strategies according to different requirements. For example, source IP address group may be grouped into n different groups, and each group may correspond to a predetermined control strategy (e.g., one of predetermined control strategies from predetermined control strategy 1 to predetermined control strategy n) as illustrated in FIG. 5. It is contemplated that the grouping and the corresponding predetermined control strategies disclosed herein are exemplary and explanatory only and are not restrictive.

After assigning predetermined control strategy to DNS query 201, DNS packet marking unit 218 may mark an unused part of DNS query 201 according to the assigned predetermined control strategy. For example, the unused part of DNS query 201 may be marked to indicate the predetermined control strategy assigned to DNS query 201. In some embodiments, as illustrated in FIG. 6, DNS packet marking unit 218 may mark the EDNS Client Subnet (ECS) field of the DNS packet of DNS query 201 to indicate the predetermined control strategy assigned to DNS query 201. As illustrated in FIG. 6, DNS packet 600 may include a traditional DNS query field 602, and an Extension Mechanisms for DNS (EDNS) field 604 that includes an Option Code (OPT) Resource Record field 606 and an ECS field 608. In some embodiments, the ECS field in DNS queries defines a mechanism for recursive resolvers (e.g., Google Public DNS) to send partial client IP address information to DNS servers. The ECS field may be used to give accurate geo-located responses when responding to name lookups coming through public DNS resolvers. When DNS server 170 has no such a function/need, it does not reply to ECS queries encoded in DNS query 201. Thus, ECS field 608 of DNS query 201 becomes unused (i.e., information encoded is not considered by DNS server 170) . In some embodiments, different predetermined control strategies may be indexed differently. DNS packet marking unit 218 may encode the index of the assigned predetermined control strategy into ECS field 608 (i.e., mark the ECS field with the index of the assigned predetermined control strategy) without interfering with the existing information encoded in DNS packet of DNS query 201. It is contemplated that other unused parts of the DNS packet may also be used for encoding the index of the assigned predetermined control strategy. For example, if no query option is available at DNS server 170, OPT Resource Record field 606 may also be used for encoding the index of the assigned predetermined control strategy.

In some embodiments, DNS query 201 may be pre-processed by load control system 160 as disclosed above. After the pre-processing, pre-processed DNS query 203 may be an original IPv4 query, an original IPv6 query requesting a domain name listed on the predetermined black and white list as accessible, or an IPv6 query marked/encoded with the index of the assigned predetermined control strategy.

In some embodiments, pre-processed DNS query 203 may be transmitted from communication interface 202 to DNS server 170. As for DNS query 201 requesting IPv6 domain name not listed on the predetermined black and white list, or requesting IPv6 domain name listed as black, DNS server 170 may extract information indicative of the assigned predetermined control strategy (e.g., resolve the information encoded in the ECS field) before fully resolving DNS query 201. In this way, the IPv6 query load on DNS server 170 may be controlled.

In some embodiments, load control system 160 may further include memory 206 and storage 208. Memory 206 and storage 208 may include any appropriate type of mass storage provided to store any type of information that processor 204 may need to operate. Memory 206 and storage 208 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium including, but not limited to, a ROM, a flash memory, a dynamic RAM, and a static RAM. Memory 206 and/or storage 208 may be configured to store one or more computer programs that may be executed by processor 204 to perform load control herein. For example, memory 206 and/or storage 208 may be configured to store program (s) that may be executed by processor 204 to filter DNS query based on the DNS query type, to determine requested domain name’s accessibility, to assign predetermined control strategy and/or to mark the DNS query based on the assigned predetermined control strategy.

Memory 206 and/or storage 208 may be further configured to store information and data used by processor 204. For instance, memory 206 and/or storage 208 may be configured to store the various types of data (e.g., predetermined black and white list and predetermined control strategies, etc. ) . Memory 206 and/or storage 208 may also store intermediate data such as query type, hash value of the requested domain name, source IP address results, etc. The various types of data may be stored permanently, removed periodically, or disregarded immediately after each frame of data is processed.

FIG. 3 illustrates a flowchart of an exemplary method 300 for load control of a DNS server, according to embodiments of the disclosure. In some embodiments, method 300 may be implemented by load control system 160. However, method 300 is not limited to that exemplary embodiment and may be implemented jointly by HTTPDNS 140, localDNS 150, and/or DNS server 170 instead. Method 300 may include steps S302-S318 as described below. It is to be appreciated that some of the steps may be optional to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 3.

In step S302, load control system 160 may receive a DNS query) from HTTPDNS 140 or localDNS 150. In some embodiments, the DNS query may be sent by user device 110 upon an input by the user to access service support node 130.

In step S304, load control system 160 may extract basic information encoded in the DNS pocket of the DNS query. In some embodiments, the basic information may include the type of the DNS query (e.g., an IPv4 query or an IPv6 query) , the requested domain name and the source IP address of the DNS query. In some embodiments, load control system 160 may extract family type of the DNS query (e.g., where A represents an IPv4 query, AAAA represents an IPv6 query) . The type of the DNS query may later be used to filter the DNS query for further processing.

In some embodiments, the requested domain name may be provided by the user. For example, “www. example. com” may be a domain name requested by a DNS query. In some embodiments, the source IP address may be the IP address of the endpoint (e.g., IP address of user device 110) . The source IP address may be used in later steps (described in detail blow) for determining control strategies assigned to the DNS query.

In step S306, load control system 160 may determine if the type of the requested domain name is AAAA and filter the DNS query based on the DNS query being the AAAA type. For example, if the type of the requested domain name is AAAA (S306: Yes) , load control system 160 may retain the DNS query for further pre-processing, e.g., provided in steps S310-316, before transmitting it to DNS server 170. Otherwise (S306: No) , load control system 160 may determine that the DNS query is not an IPv6 query (e.g., an IPv4 query) and transmit the DNS query to DNS server 170 in S308.

In step S310, load control system 160 may determine an accessibility of the requested domain name based on a predetermined black and white list. In some embodiments, the predetermined black and white list may include records of domain names. For example, a record of a domain name on the black and white list may include fields such as a key, a value of the key, and an accessibility value of the domain name.

In some embodiment, accessibility value may represent the accessibility of the domain name and may take a “black” or “white” value. In some embodiments, if the requested domain name of the DNS query is listed as a record on the predetermined black and white list and the accessibility value of which is white, load control system 160 may determine that the requested domain name is accessible (S310: Yes) . Accordingly, method 300 proceeds to step S308 where DNS query 201 may be transmitted to DNS server 170. Otherwise (e.g., the domain name has an accessibility value of black or is not listed on the predetermined black and white list) , load control system 160 may determine that the requested domain name is not accessible (S310: Yes) . The DNS query may stay in load control system 160 for further processing, e.g., through step S312-S316.

Step S310 of method 300 may be implemented by method 400, illustrated by FIG. 4. In some embodiments, a domain name on the predetermined black and white list may be indexed by its hash value. When determining the accessibility of the requested domain of the DNS query, in S402 of method 400, load control system 160 may hash the requested domain name extracted from the DNS query. Load control system 160 may compare the hash value of the requested domain name to the hash value listed on the predetermined black and white list (step S404) and determine if the requested domain name is listed on the predetermined black and white list (step S406) . For example, load control system 160 may look up the hash value of the requested domain name on the predetermined black and white list and determine if the hash value of the requested domain name matches one of the hash value indices of domain name records. If the requested domain name is not listed on the predetermined black and white list (S406: No) , method 400 proceeds to S312 of method 300, where the DNS query will stay in load control system 160 for further processing. If the requested domain name is listed, load control system 160 may further determine if the domain name with the matched hash value on the black and white list has a white accessibility value. If the corresponding accessibility value listed is white (S410: Yes) , method 400 proceeds to step S308 of method 300, where the DNS query may be transmitted to DNS server 170. Otherwise, if the accessibility value listed is black (S410: Yes) ) , method 400 proceeds to S312.

Returning to method 300, in step S312, load control system 160 may determine and assign a predetermined control strategy to the DNS query based on the source IP address of the DNS query. For example, as illustrated in FIG. 5, source IP address may be grouped into different groups and be assigned different predetermined control strategies. In a simplified example, source IP addresses may be grouped based on whether the source IP address indicates a private network user (e.g., source IP address group 1) or a public network user (e.g., source IP address group 2) . DNS queries originated from a private network may be assigned a control strategy where all the IPv6 DNS query would be fully resolved by DNS server 170. On the other hand, DNS queries originated from a public network may be assigned a predetermined control strategy where access to all IPv6 domain names are denied. Accordingly, resolution of the queries by DNS server 170 are performed according to the assigned predetermined control strategy.

In S314, load control system 160 may mark an unused part of the DNS query to indicate the assigned predetermined control strategy. In some embodiments, as illustrated in FIG. 6, load control system 160 may mark the ECS field of the DNS packet of the DNS query. As illustrated in FIG. 6, DNS packet 600 of a DNS query may include a traditional DNS query field 602, an EDNS field 604 that includes OPT Resource Record field 606 and ECS field 608. In step S316, the pre-processed DNS query is transmitted to DNS server 170 for resolution. In some embodiments, the pre-processed DNS query may be an original IPv4 query, an original IPv6 query requesting domain name listed on the black and white list as accessible (e.g., a query provided by S308) , or an IPv6 query marked/encoded with the index of the assigned predetermined control strategy (e.g., a query provide by S316) .

In step S318, DNS server 170 may process the pre-processed DNS query transmitted from load control system160. In some embodiments, DNS server 170 may fully resolve the DNS query provided by S308, such as an original IPv4 query or an original IPv6 query requesting a domain name listed on the black and white list as accessible. For an IPv6 query, DNS server 170 may first extract the information in the marked field of the query (e.g., the ECS field of the DNS packet indicative of the assigned predetermined control strategy) and resolve the DNS query based on the extracted predetermined control strategy.

Another aspect of the disclosure is directed to a non-transitory computer-readable medium storing instructions which, when executed, cause one or more processors to perform the methods, as discussed above. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage devices. For example, the computer-readable medium may be the storage device or the memory module having the computer instructions stored thereon, as disclosed. In some embodiments, the computer-readable medium may be a disc or a flash drive having the computer instructions stored thereon.

It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed system and related methods. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed system and related methods.

It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.

Claims

A system for performing load control of a Domain Name System (DNS) server, comprising:

a communication interface configured to receive a DNS query from a user device, wherein the DNS query comprising at least one DNS packet; and

at least one processor coupled to the communication interface and configured to:

extract information indicative of a source IP address from the DNS packet;

assign a predetermined control strategy to the DNS packet based on the source IP address;

mark an unused field of the DNS packet based on the assigned predetermined control strategy; and

transmit the marked DNS packet to the DNS server.
The system of claim 1, wherein the at least one processor is further configured to:

extract information indicative of at least a requested domain name from the DNS packet; and

determine an accessibility of the requested domain name based on a predetermined black and white list.
The system of claim 2, wherein the predetermined black and white list comprises at least one domain name record, and wherein the at least one domain name record comprises at least a key, an accessibility value associated with the key and a hash value of the domain name.
The system of claim 3, wherein to determine the accessibility of the requested domain name, the at least one processor is further configured to:

determine a current hash value of the requested domain name; and

compare the current hash value of the requested domain name to the hash value on the black and white list.
The system of claim 1, wherein the unused field of the DNS packet is an EDNS Client Subnet (ECS) field.
The system of claim 1, wherein the predetermined control strategy specifies at least one restriction on at least one predetermined group of source IP addresses.
The system of claim 1, wherein the marked DNS packet is further processed by the DNS server based on the marked field.
The system of claim 1, wherein the DNS query is either an IPv6 query or an IPv4 query.
The system of claim 8, wherein the DNS query is transmitted over HTTPs, and wherein the at least one processor is further configured to filter the DNS query based on the DNS query being the IPv6 query.
A computer-implemented method for load control of a Domain Name System (DNS) server, comprising:

receiving a DNS query from a user device, wherein the DNS query comprising at least one DNS packet;

extracting information indicative of a source IP address from the DNS packet;

assigning a predetermined control strategy to the DNS packet based on the source IP address;

marking an unused field of the DNS packet based on the assigned predetermined control strategy; and

transmitting the marked DNS packet to the DNS server.
The computer-implemented method of claim 10, further comprising:

extracting information indicative of at least a requested domain name from the DNS packet; and

determining an accessibility of the requested domain name based on a predetermined black and white list.
The computer-implemented method of claim 11, wherein the predetermined black and white list comprises at least one domain name record, and wherein the at least one domain name record comprises at least a key, an accessibility value associated with the key and a hash value of the domain name.
The computer-implemented method of claim 12, wherein to determine the accessibility of the requested domain name, the method further comprises:

determining a current hash value of the requested domain name; and

comparing the current hash value of the requested domain name to the hash value on the black and white list.
The computer-implemented method of claim 10, wherein the unused field of the DNS packet is an EDNS Client Subnet (ECS) field.
The computer-implemented method of claim 10, wherein the predetermined control strategy specifies at least one restriction on at least one predetermined group of source IP addresses.
The computer-implemented method of claim 10, wherein the marked DNS packet is further processed by the DNS server based on the marked field.
The computer-implemented method of claim 10, wherein the DNS query is either an IPv6 query or an IPv4 query.
The method of claim 17 further comprising filtering the DNS query based on the DNS query being the IPv6 query.
A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method for load control of a Domain Name System (DNS) server, the method comprising:

receiving a DNS query from a user device, wherein the DNS query comprising at least one DNS packet;

extracting information indicative of a source IP address from the DNS packet;

assigning a predetermined control strategy to the DNS packet based on the source IP address;

marking an unused field of the DNS packet based on the assigned predetermined control strategy; and

transmitting the marked DNS packet to the DNS server.
The non-transitory computer-readable medium of claim 19, wherein the method further comprises:

extracting information indicative of at least a requested domain name from the DNS packet; and

determining an accessibility of the requested domain name based on a predetermined black and white list.