Domain Name System (DNS) Security

Abstract

New tools and techniques are provided for implementing Domain Name System (DNS) security improvements. In various embodiments, a computing system may receive a User Datagram Protocol ("UDP")-based DNS request and may send a UDP-based response message that may include an empty payload portion and a header portion that includes a set truncation flag indicating that the request is to be retransmitted as a Transmission Control Protocol ("TCP")-based DNS request. If the TCP-based DNS request is received within a first period of time, the computing system may send a TCP-based response message to a source address that includes an answer to a query (in the TCP-based DNS request) for a destination DNS record associated with a destination device. If no TCP-based DNS request is received from the source address within the first period of time, the computing system may block all UDP-based DNS requests from the source address for at least a second period of time.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 483,628, entitled "Domain Name System (DNS) Security," filed February 7, 2023, which is incorporated herein by reference in its entirety.

[0002] Copyright Statement A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the exact facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights whatsoever.

[0003] The present disclosure relates generally to methods, systems, and apparatus for implementing Domain Name System (DNS) functionality, and more particularly to methods, systems, and apparatus for implementing DNS security improvements by requiring DNS query retries. [Background technology]

[0004] User datagram protocol (UDP)-based Domain Name System ("DNS") requests or packets can easily be disguised and used in malicious network attacks as distributed denial of service ("DDoS") traffic. Indeed, many carefully planned UDP-based DNS attacks can be virtually indistinguishable from regular DNS traffic.

[0005] It is with respect to this general technology environment that aspects of the present disclosure are directed. [Brief explanation of the drawings]

[0006] A further understanding of the nature and advantages of particular embodiments may be realized by reference to the remaining portions of the specification and the drawings, in which like reference numerals are used to refer to like components. In some instances, a sublabel is associated with a reference numeral to indicate one of multiple similar components. When referring to a reference numeral without specifying an existing sublabel, it is intended to refer to all such multiple similar components. To indicate multiple components, the suffixes "a" through "n" may be used, where n indicates any suitable integer and may be the same or different from the suffix "n" of other components in the same or different figures. For example, for component #1 105a-105n, the integer value of n in 105n may be the same or different from the integer value of n in 110n of component #2 110a-110n, etc.

[0007] [Figure 1] FIG. 1 is a schematic diagram illustrating a system for implementing DNS security improvements, according to various embodiments.

[0008] [Figure 2] FIG. 1 is a schematic diagram illustrating non-limiting examples of access permission conditions when implementing DNS security improvements, according to various embodiments.

[0009] [Figure 3] FIG. 1 is a schematic diagram illustrating non-limiting examples of access denial conditions when implementing DNS security improvements, according to various embodiments.

[0010] [Figure 4A] FIG. 1 is a flow diagram illustrating a method for implementing DNS security improvements, according to various embodiments. [Figure 4B] FIG. 1 is a flow diagram illustrating a method for implementing DNS security improvements, according to various embodiments. [Figure 4C] FIG. 1 is a flow diagram illustrating a method for implementing DNS security improvements, according to various embodiments. [Figure 4D]FIG. 1 is a flow diagram illustrating a method for implementing DNS security improvements, according to various embodiments. [Figure 4E] FIG. 1 is a flow diagram illustrating a method for implementing DNS security improvements, according to various embodiments. [Figure 4F] FIG. 1 is a flow diagram illustrating a method for implementing DNS security improvements, according to various embodiments.

[0011] [Figure 5] FIG. 1 is a block diagram illustrating the hardware architecture of an exemplary computer or system, according to various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0012] overview

[0013] Various embodiments provide tools and techniques for implementing Domain Name System (DNS) functionality, and more particularly, methods, systems, and apparatus for implementing DNS security improvements by requiring retries of DNS queries.

[0014] In various embodiments, a computing system may receive a first User Datagram Protocol (“UDP”)-based DNS request, the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or destination entity. In response to receiving the first UDP-based DNS request, the computing system may send a UDP-based response message to the source address. In some examples, the response message may include an empty payload portion and a header portion including a set truncation (“TC”) flag. If a first Transmission Control Protocol (“TCP”)-based DNS request corresponding to the first UDP-based DNS request is received from the source address within a first predetermined period, the computing system may send a TCP-based response message to the source address including an answer to the query for the destination DNS record. If a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within a first predetermined period, the computing system may cause one or more second UDP-based DNS requests from the source address to be blocked. In some cases, the one or more second UDP-based DNS requests may include the first UDP-based DNS request.

[0015] Thus, various embodiments leverage the functionality of the truncation flag as a novel feature to improve DNS security. The truncation flag is traditionally used in UDP responses whose payload size exceeds 512 bytes (thus truncating the payload) to request or indicate that the UDP message (to which the UDP response is responding) be resent as a TCP message, which may result in a corresponding TCP response (not bound by the 512-byte payload limit). For example, a query may be received from a new client's source IP address (or source port), and an empty response with the truncation flag set may be returned. The client's behavior is to retry the query via TCP. This retry indicates that the source IP address (or source port) is temporarily trusted for UDP traffic. Additional UDP attempts are sent to the AI / ML system for evaluation, which may determine whether to ban or block the source IP address (or source port), and for how long. Because IP addresses are temporary, the AI / ML system may provide additional tracking to ensure that client behavior does not deteriorate and / or lift any imposed bans.

[0016] These and other aspects of improving DNS security are described in more detail with respect to the figures.

[0017] The following detailed description presents several exemplary embodiments in further detail to enable those skilled in the art to practice such embodiments. The described examples are provided for illustrative purposes and are not intended to limit the scope of the present invention.

[0018] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the described embodiments. However, it will be apparent to those skilled in the art that other embodiments of the present invention may be practiced without some of these specific details. In other instances, certain structures and devices are shown in block diagram form. While several embodiments are described herein and various features are ascribed to various embodiments, it should be understood that features described with respect to one embodiment may be combined with other embodiments. Similarly, however, no single feature or features of any described embodiment should be considered essential to all embodiments of the present invention, as other embodiments of the present invention may omit such features.

[0019] Unless otherwise indicated, all numbers used herein to express quantities, dimensions, and the like are understood to be modified in all instances by the term "about." In this application, unless otherwise indicated, the use of the singular includes the plural, and the use of the terms "and" and "or" means "and / or" unless otherwise indicated. Furthermore, the use of the term "including" should be considered non-exclusive, as should other forms such as "includes" and "included." Also, terms such as "element" or "component" encompass both elements and components that make up one unit and elements and components that make up more than one unit, unless otherwise indicated.

[0020] In one aspect, a method includes receiving, by a Domain Name System ("DNS") computing system, a first User Datagram Protocol ("UDP")-based DNS request, the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or the destination entity; and transmitting, by the computing system in response to receiving the first UDP-based DNS request, a UDP-based response message to the source address, the UDP-based response message including an empty payload portion and the first UDP-based DNS request has a header portion that includes a set truncation ("TC") flag; if a first Transmission Control Protocol ("TCP")-based DNS request corresponding to the first UDP-based DNS request is received from the source address within a first predetermined period, sending, by the computing system, a TCP-based response message to the source address that includes an answer to the query for the destination DNS record; and if a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within the first predetermined period, causing, by the computing system, UDP-based DNS requests from the source address to be blocked.

[0021] In some embodiments, the computing system may comprise at least one of a DNS resolver, a DNS recursive resolver (“recurser”), a DNS root name server, a top level domain (“TLD”) name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence (“AI”) system, a machine learning (“ML”) system, a virtual machine (“VM”), or software running on the computing system, and / or the like. In some cases, the response message may include an empty payload portion. In some examples, the source address may have at least one of a source port or a source IP address.

[0022] According to some embodiments, sending the TCP-based response message may include one of: sending, by the computing system, the destination DNS record to the source address based on a first UDP-based DNS request, the destination DNS record being obtained from at least one of a cache of the computing system or a lookup of an authoritative name server; or sending, by the computing system, a message to the source address indicating that the destination DNS record was not found.

[0023] In some embodiments, the method may further include, after receiving the first TCP-based DNS request corresponding to the first UDP-based DNS request, updating, by the computing system, one or more rules of at least one access control list (ACL) to allow the source address access to the network.

[0024] According to some embodiments, the method may further include performing at least one of the following steps: after receiving the first TCP-based DNS request corresponding to the first UDP-based DNS request, causing the computing system to process one or more second UDP-based DNS requests received by the computing system from the source address; or causing the computing system to communicate with each of a plurality of DNS resolvers to enable one or more third UDP-based DNS requests received by the plurality of DNS resolvers from the source address to be processed.

[0025] In some embodiments, the method may further include causing the computing system to process one or more fourth UDP-based DNS requests received from the source address within a second predetermined period of time after receiving the first TCP-based DNS request.

[0026] In some examples, the method may further include analyzing, by the computing system, one or more fifth UDP-based DNS requests received from the source address after the second predetermined period using a machine learning model to determine whether to block the one or more fifth UDP-based DNS requests; and performing, by the computing system, one or more DNS tasks based on the analysis.

[0027] In some embodiments, causing the UDP-based DNS request from the source address to be blocked may comprise at least one of: updating, by the computing system, one or more rules of at least one access control list ("ACL") to deny the source address access to the network; dropping, by the computing system, all DNS requests from the source address; or filtering, by the computing system, all DNS requests from the source address; and / or the like. In some cases, causing the first UDP-based DNS request from the source address to be blocked may include causing the computing system to block all DNS requests received from the source address for a third predetermined period of time.

[0028] According to some embodiments, the method may further comprise dropping, by the computing system, any one or more sixth UDP-based DNS requests received from the source address after receiving the first UDP-based DNS request and before receiving the first TCP-based DNS request.

[0029] By way of example only, in some cases, at least one of the query, query type, query source, or mail exchange ("MX") record of the first UDP-based DNS request may be the same as at least one of the query, query type, query source, or MX record of the corresponding first TCP-based DNS request.

[0030] In some embodiments, the method may further comprise determining, by the computing system, whether the first UDP-based DNS request is a legitimate DNS request by performing at least one of: determining, by the computing system, that the first UDP-based DNS request is one of several UDP-based DNS requests that exceed a predetermined number of requests within a fourth predetermined time period and that are received from the source address; or determining, by the computing system, that an ACL already indicates that the source address should be denied access to the network; and / or the like.

[0031] In another aspect, a system may include a Domain Name System ("DNS") computing system. The computing system may include at least one first processor and a first non-transitory computer-readable medium communicatively coupled to the at least one first processor. The first non-transitory computer-readable medium includes a method that, when executed by the at least one first processor, causes the computing system to receive a first User Datagram Protocol ("UDP")-based DNS request, the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or the destination entity; and, in response to receiving the first UDP-based DNS request, causes the computing system to send a UDP-based response message to the source address, the UDP-based response message including: , having an empty payload portion and a header portion including a set truncation ("TC") flag; causing a first Transmission Control Protocol ("TCP")-based DNS request corresponding to the first UDP-based DNS request to be received from the source address within a first predetermined period, causing a TCP-based response message including an answer to the query for the destination DNS record to be sent to the source address; and causing blocking of UDP-based DNS requests from the source address if a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within the first predetermined period.

[0032] In some embodiments, the computing system may comprise at least one of a DNS resolver, a DNS recursive resolver (“recurser”), a DNS root name server, a top level domain (“TLD”) name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence (“AI”) system, a machine learning (“ML”) system, a virtual machine (“VM”), or software running on a computing system, and / or the like. In some examples, the response message may include an empty payload portion. In some examples, the source address may include at least one of a source port or a source IP address.

[0033] According to some embodiments, causing the UDP-based DNS requests from the source address to be blocked may comprise at least one of: updating one or more rules of at least one access control list (“ACL”) to deny the first source address access to the network; dropping all DNS requests from the first source address; or filtering all DNS requests from the first source address; and / or the like.

[0034] In yet another aspect, a method may comprise receiving, by a Domain Name System ("DNS") computing system, a first User Datagram Protocol ("UDP")-based DNS request, the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or the destination entity; sending, by the computing system, a UDP-based response message to the source address in response to receiving the first UDP-based DNS request, the UDP-based response message having an empty payload portion and a header portion including a set truncation ("TC") flag; and causing, by the computing system, one or more second UDP-based DNS requests from the source address to be blocked if a Transmission Control Protocol ("TCP")-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within a first predetermined period, the one or more second UDP-based DNS requests comprising the first UDP-based DNS request.The method may further include causing, if a first TCP-based DNS request corresponding to the first UDP-based DNS request is received from the source address within the first predetermined period of time, the computing system to allow at least the first UDP-based DNS request from the source address to be processed by sending, by the computing system, within a second predetermined period of time after receiving the first TCP-based DNS request, at least a TCP-based response message including an answer to the query for the destination DNS record to the source address; receiving, by the computing system, one or more third UDP-based DNS requests from the source address after the second predetermined period of time; analyzing, by the computing system, the one or more third UDP-based DNS requests using a machine learning model and determining whether to block the one or more third UDP-based DNS requests; and performing, by the computing system, one or more DNS tasks based on the analysis.

[0035] According to some embodiments, the computing system may comprise at least one of a DNS resolver, a DNS recursive resolver ("recurser"), a DNS root name server, a top-level domain ("TLD") name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence ("AI") system, a machine learning ("ML") system, a virtual machine ("VM"), or software running on the computing system, and / or the like.

[0036] In some embodiments, causing the one or more second UDP-based DNS requests from the source address to be blocked may comprise at least one of: updating, by the computing system, one or more rules of at least one access control list ("ACL") to deny the source address access to the network; dropping, by the computing system, all DNS requests from the source address; or filtering, by the computing system, all DNS requests from the source address; and / or the like.

[0037] Various modifications and additions can be made to the discussed embodiments without departing from the scope of the invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the features described above.

[0038] Specific Exemplary Embodiments

[0039]

[0013] Reference will now be made to the embodiments illustrated in the drawings. Figures 1-5 illustrate certain features of methods, systems, and apparatus for implementing Domain Name System ("DNS") functionality, and more particularly, methods, systems, and apparatus for implementing DNS security improvements by requiring DNS query retries, as mentioned above. The methods, systems, and apparatus illustrated in Figures 1-5 illustrate examples of different embodiments, including various components and steps, which may be considered alternatives or may be used in combination with one another in various embodiments. The descriptions of the methods, systems, and apparatus illustrated in Figures 1-5 are provided for illustrative purposes and should not be considered to limit the scope of different embodiments.

[0040] Referring now to the drawings, FIG. 1 is a schematic diagram illustrating a system 100 for implementing DNS security improvements, according to various embodiments.

[0041] In the non-limiting embodiment of FIG. 1, system 100 may include, but is not limited to, at least one of: computing system 105; one or more DNS resolvers 110a-110n (collectively “DNS resolvers 110” or the like); one or more access control lists (“ACLs”) or filters 115a and / or 115b (collectively “ACLs or filters 115” or the like); cache 120; threat intelligence system 125; artificial intelligence (“AI”) / machine learning (“ML”) system 130; authoritative name server or name servers 135; database or DNS database 140; one or more networks 145a-145n (collectively “network 145” or the like); one or more first client devices 150a associated with a first entity 155a; or one or more second client devices 150b associated with a second entity 155b; and / or the like. According to some embodiments, ACL or filter 115a and cache 120 may be integrated into or within each of at least one DNS resolver 110 of one or more DNS resolvers 110a-110n, while ACL or filter 115b may be located within network 145 and external to any of DNS resolvers 110a-110n, possibly as part of a router ACL or filter or as part of a third-party ACL or filter (e.g., as shown in FIG. 2 or FIG. 3, or similar figures). Each ACL or filter 115 indicates which source addresses (e.g., source ports and / or source Internet Protocol (“Internet Protocol”) addresses, or the like) are allowed or denied access to the network (in this case, network 145, or the like) and thus may determine from which source addresses the DNS system returns DNS responses (e.g., destination DNS records, or the like) in response to DNS queries, or the like.As used herein, a destination DNS record may include, but is not limited to, at least one of: one or more destination A records (each including an IPv4 address for the destination domain, or the like); one or more destination AAAA records (each including an IPv6 address for the destination domain, or the like); one or more destination message exchange ("MX") records (each including routing information to a destination mail server, or the like); one or more destination name server ("NS") records (each including authoritative DNS server information for the destination domain); or one or more other DNS records or DNS record types, or the like. In some examples, AI / ML system 130 may be integrated with threat intelligence system 125. Alternatively, AI / ML system 130 may be separate from, but communicatively coupled to, threat intelligence system 125 (not shown). In some embodiments, computing system 105, each DNS resolver among DNS resolvers 110a-110n, threat intelligence system 125, and authoritative name server 135 and corresponding database 140 may be located within network 145 among one or more networks 145a-145n. In some cases, database 140 may be a distributed database spanning several networks among one or more networks 145a-145n.

[0042] In some embodiments, the computing system 105 may include, but is not limited to, a DNS resolver (e.g., DNS resolver 110 among one or more DNS resolvers 110a-110n, or the like), a DNS recursive resolver (a "recurser" that may be configured to query other DNS resolvers 110 or DNS servers for destination DNS records; herein, each DNS resolver 110 represents either a DNS resolver or a DNS recurser, or the like), a DNS root name server, a top-level domain ("TLD") name server, a DNS recursive resolver (e.g., a DNS resolver 110 among one or more DNS resolvers 110a-110n, or the like), a DNS root name server, a DNS recursive resolver (e.g., a DNS resolver 110 among one or more DNS resolvers 110a-110n, or the like), a DNS recursive resolver (e.g., a DNS resolver 110 among other DNS resolvers 110a-110n, or the like), a DNS root name server, a top-level domain ("TLD") name server, a DNS recursive resolver (e.g., a DNS resolver 110 among other DNS resolvers 110a-110n, or the like), ... The authoritative name server 135 may include at least one of a DNS root name server, an authoritative name server, a threat intelligence system (e.g., threat intelligence system 125, or the like), a threat mitigation system (similar to threat intelligence system 125, or the like), a server, an AI system or an ML system (e.g., AI / ML system 130, or the like), a virtual machine ("VM"), or software (e.g., a daemon, script, or other software, or the like) running on computing system 105, and / or the like. In some cases, authoritative name server 135 may include at least one of a DNS root name server, a TLD name server, and / or an authoritative name server, and / or the like.In some examples, one or more client devices 150a or 150b may each include, but are not limited to, one of a desktop computer, a laptop computer, a tablet computer, a smartphone, a mobile phone, a server, a cloud computing system, a distributed computing system, or any suitable device capable of communicating with a DNS resolver (e.g., DNS resolver 110 or 110a-110n, or the like) and / or other computing systems (e.g., computing system 105, or the like) over networks 145a-145n via a web-based portal, a web browser, an application programming interface ("API"), a server, a software application ("app"), or any other suitable communications interface, or the like. In some cases, entity 155a or 155b may include, but is not limited to, an individual, a group of individuals, a company, a group of companies, a (foreign) government actor, a (foreign) government agency, or an alliance of (foreign) government actors, agencies, and / or government entities, or the like.

[0043] According to some embodiments, networks 145a-145n may each include, but are not limited to, one of the following: a local area network (LAN), including, but not limited to, a fiber network, an Ethernet network, a token ring network, and / or the like; a wide-area network (WAN); a wireless wide area network (WWAN); a virtual network such as a virtual private network (VPN); the Internet; an intranet; an extranet; a public switched telephone network (PSTN); an infrared network; a wireless network, including, but not limited to, a network operating under any of the IEEE 802.11 protocol suite, the Bluetooth protocol, and / or any other wireless protocol known in the art; and / or any combination of these and / or other networks. In particular embodiments, networks 145a-145n may include an access network of a service provider (e.g., an Internet service provider (ISP)). In another embodiment, the networks 145a-145n may include a service provider's core network and / or the Internet.

[0044] During operation, at least one of computing system 105, DNS resolver 110a among one or more DNS resolvers 110a-110n, ACL or filter 115a or 115b, threat intelligence system 125, and / or AI / ML system 130 (collectively, “computing system,” or the like) may receive a first User Datagram Protocol (“UDP”)-based DNS request (e.g., UDP request 160, or the like), the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device (not shown), a destination entity (not shown) associated with the destination device, or a destination domain (not shown) associated with the destination device or destination entity within a network (e.g., network 145, or the like). In response to receiving the first UDP-based DNS request, the computing system may send a UDP-based response message (e.g., response message 165, or the like) to the source address. In some cases, the source address may include at least one of, but is not limited to, a source port or a source IP address, and / or the like. In some examples, the response message may include an empty payload portion and a header portion including a set truncation ("TC") flag, and the set TC flag in the response message may instruct the source address to retransmit the first UDP-based DNS request as a Transmission Control Protocol ("TCP")-based DNS request.

[0045] In this manner, the computing system may send an empty UDP response with the TC flag set without performing any other DNS-based tasks until it receives a TCP-based DNS request from the source address. If the source address is associated with the requesting client device (e.g., a source address associated with client device 150b associated with second entity 155b, or the like), the source client device is likely to be a legitimate requester and therefore likely to send a TCP-based DNS request in response to the UDP-based response with the TC flag set. If the source address is not associated with the requesting client device (e.g., a requesting client device 150a associated with first entity 155a attempts to spoof the source address of client device 150b associated with second entity 155b, or the like), for the UDP-based response that reaches second client device 150b associated with the source address, second client device 150b may determine that it did not send the first UDP-based DNS request and therefore does not send a TCP-based DNS request in response. Alternatively, for a UDP-based response reaching the first client device 150a, if the first client device 150a is being used to send large UDP-based DNS requests (e.g., as part of a distributed denial of service ("DDoS") attack, or the like), it is unlikely to respond to the UDP-based response because its resources are likely being devoted to sending a large number of UDP-based DNS requests, and therefore is unlikely to send a TCP-based DNS request in response.

[0046] A first TCP-based DNS request (e.g., TCP request 170, or the like) corresponding to a first UDP-based DNS request (e.g., UDP request 160, or the like) is received within a first predetermined period (e.g., 50, 100, 150, 200, 250, 300, 350, 400, 450, or 500 milliseconds, or 1, 2, 3, 4, 5, 10, 15, 20, 25, 30, 40, 50, or 60 seconds, or 2, 3, 4, 5, 10 , 15, or 20 minutes, or a time period in the range of 1 to 500 milliseconds, 1 to 100 milliseconds, 1 to 50 milliseconds, 1 to 60 seconds, 1 to 30 seconds, 1 to 15 seconds, 1 to 20 minutes, 1 to 10 minutes, or 1 to 5 minutes, or a similar time period), the computing system may send a TCP-based response message to the source address including an answer to the query for the destination DNS record. Herein, in some examples, for a first TCP-based DNS request to correspond to a first UDP-based DNS request, at least one of the query, query type, query source, or mail exchange ("MX") record of the first UDP-based DNS request should be the same as at least one of the query, query type, query source, or MX record of the corresponding first TCP-based DNS request, or vice versa.

[0047] If a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within a first predetermined period of time, the computing system may cause one or more second UDP-based DNS requests from the source address to be blocked. In some cases, the one or more second UDP-based DNS requests may include the first UDP-based DNS request.

[0048] According to some embodiments, sending the TCP-based response message may include the computing system sending the destination DNS record to the source address, possibly by returning the destination DNS record for the destination device in a DNS response (e.g., DNS response 175, or the like) retrieved from at least one of the computing system's cache (e.g., cache 120, or the like) or an authoritative name server lookup (e.g., a lookup of authoritative name server 135 and / or corresponding database 140, or the like). Alternatively, sending the TCP-based response message may include the computing system sending a message to the source address indicating that the destination DNS record was not found.

[0049] In some embodiments, for an "access permission condition," after receiving a first TCP-based DNS request corresponding to the first UDP-based DNS request, the computing system may update one or more rules of at least one ACL (e.g., ACL or filter 115a or 115b, or the like) to allow the source address access to the network (i.e., allow the source address access to the network, thus enabling communication between the source address and the destination device, assuming the destination DNS record can be found, or the like). Alternatively, or additionally, for the "access permission condition," the computing system may perform at least one of: after receiving a first TCP-based DNS request corresponding to the first UDP-based DNS request, causing one or more second UDP-based DNS requests received from the source address to be processed by the computing system; or causing a threat intelligence system (e.g., threat intelligence system 125, or the like) to communicate with each of a plurality of DNS resolvers (e.g., DNS resolvers 110b-110n among one or more DNS resolvers 110a-110n, or the like) to enable one or more third UDP-based DNS requests received from the source address to be processed by the plurality of DNS resolvers. Alternatively, or additionally, for the "access permission condition," the computing system may process one or more fourth UDP-based DNS requests received from the source address within a second predetermined period of time (e.g., 50, 100, 150, 200, 250, 300, 350, 400, 450, or 500 milliseconds, or 1, 2, 3, 4, 5, 10, 15, 20, 25, 30, 40, 50, or 60 seconds, or 2, 3, 4, 5, 10, 15, or 20 minutes, or a period in the range of between 1 and 500 milliseconds, between 1 and 100 milliseconds, between 1 and 50 milliseconds, between 1 and 60 seconds, between 1 and 30 seconds, between 1 and 15 seconds, between 1 and 20 minutes, between 1 and 10 minutes, or between 1 and 5 minutes, or a similar period of time) after receiving the first TCP-based DNS request.As used herein, causing a UDP-based DNS request to be processed may refer to retrieving the destination DNS record in response to the query in the UDP-based DNS request from at least one of a computing system cache or an authoritative name server lookup, and / or sending a message indicating that the destination DNS record was not found, or the like.

[0050] In some embodiments, the computing system may use a machine learning model (e.g., an ML model of AI / ML system 130, or the like) to analyze one or more fifth UDP-based DNS requests received after the second predetermined period from the source address and determine whether to block the one or more fifth UDP-based DNS requests. Based on such analysis, the computing system may perform one or more DNS tasks, including, but not limited to, configuring a DNS client (by configuring static domain name resolution or dynamic domain name resolution, configuring a DNS proxy, configuring DNS spoofing, specifying a source interface for DNS packets, configuring a DNS trusted interface, or setting a differentiated services code point (DSCP) value for outgoing DNS packets, or the like).

[0051] In some embodiments, causing one or more second UDP-based DNS requests from the source address to be blocked (also referred to herein as an “access denied condition”) may include the computing system updating one or more rules of at least one ACL (e.g., ACL or filter 115a or 115b, or the like) to deny the source address access to the network (i.e., denying the source address from accessing the network and therefore from communicating with a destination device, or the like); dropping all DNS requests from the source address; or filtering all DNS requests from the source address; and / or the like. Alternatively, or additionally, causing one or more second UDP-based DNS requests from the source address to be blocked may be determined by the computing system being configured to block the one or more second UDP-based DNS requests from the source address for a third predetermined period of time (e.g., 50, 100, 150, 200, 250, 300, 350, 400, 450, or 500 milliseconds, or 1, 2, 3, 4, 5, 10, 15, 20, 25, 30, 40, 50, or 60 seconds, or 2, 3, 4, 5, 10, 15, 20, 30, 40, 50, 60 minutes, or 2, 3, 4, 5, 6, 12 , 18, or 24 hours, or 2, 3, 4, 5, 6, or 7 days, or for a period in the range of 1-500 milliseconds, 1-100 milliseconds, 1-50 milliseconds, 1-60 seconds, 1-30 seconds, 1-15 seconds, 1-60 minutes, 1-30 minutes, 1-10 minutes, 1-5 minutes, 1-24 hours, 1-18 hours, 1-12 hours, 1-6 hours, or 1-7 days, or a similar period of time.

[0052] According to some embodiments, the computing system may drop any one or more sixth UDP-based DNS requests received from the source address after receiving the first UDP-based DNS request and before receiving the first TCP-based DNS request.

[0053] In some embodiments, the computing system determines whether the first UDP-based DNS request is a legitimate DNS request, in some cases, by determining whether the first UDP-based DNS request is a legitimate DNS request for a fourth predetermined period (e.g., 50, 100, 150, 200, 250, 300, 350, 400, 450, or 500 milliseconds, or 1, 2, 3, 4, 5, 10, 15, 20, 25, 30, 40, 50, or 60 seconds, or 2, 3, 4, 5, 10, 15, or 20 minutes, or between 1 and 500 milliseconds, between 1 and 100 milliseconds, between 1 and 50 milliseconds, between 1 and 60 seconds ... determining that the source address is one of several UDP-based DNS requests that exceed a predetermined number of requests within a period of time (for example, within a range of 30 seconds, between 1 and 15 seconds, between 1 and 20 minutes, between 1 and 10 minutes, or between 1 and 5 minutes, or a similar period) and that have been received from the source address; or determining that an ACL (e.g., ACL or filter 115a or 115b, or the like) has already indicated that the source address should be denied access to the network; and / or the like.

[0054] In another aspect, a computing system may receive a first UDP-based DNS request (e.g., UDP request 160, or the like), where the first UDP-based DNS request includes a source address and a query for a destination DNS record associated with at least one of a destination device (not shown) in a network (e.g., network 145, or the like), a destination entity (not shown) associated with the destination device, or a destination domain (not shown) associated with the destination device or destination entity. In response to receiving the first UDP-based DNS request, the computing system may send a UDP-based response message (e.g., response message 165, or the like) to the source address. In some examples, the UDP-based response message may include, without limitation, an empty payload portion and a header portion including a set TC flag, where the set TC flag in the header portion of the response message instructs the source address to retransmit the first UDP-based DNS request as a TCP-based DNS request. If a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within a first predetermined period (similar to the first predetermined period described above), the computing system may cause one or more second UDP-based DNS requests from the source address to be blocked. In some cases, the one or more second UDP-based DNS requests may include the first UDP-based DNS request.

[0055] If a first TCP-based DNS request (e.g., TCP request 170, or the like) corresponding to a first UDP-based DNS request (e.g., UDP request 160, or the like) is received from a source address within a first predetermined period of time, the computing system may allow at least the first UDP-based DNS request from the source address to be processed, possibly by sending at least a TCP-based response message to the source address that includes an answer to the query for the destination DNS record, within a second predetermined period of time (similar to the second predetermined period described above) after receiving the first TCP-based DNS request. The computing system may then receive one or more third UDP-based DNS requests from the source address after the second predetermined period of time. The computing system may use a machine learning model (e.g., an ML model of the AI / ML system 130, or the like) to analyze the one or more third UDP-based DNS requests and determine whether to block the one or more third UDP-based DNS requests; and may perform one or more DNS tasks (similar to the DNS tasks described above) based on the analysis.

[0056] These and other features of system 100 (and its components) are described in more detail below with respect to FIGS.

[0057] FIG. 2 is a diagram illustrating a non-limiting example 200 of access permission conditions when implementing DNS security improvements, according to various embodiments.

[0058] In some embodiments, DNS resolvers 210a-210n, ACL or filter 215a, ACL or filter 215b or 215c, cache 220, threat intelligence system 225, AI / ML system 230, authoritative name server 235, client device 250, UDP request 260, response 265, TCP request 270, and DNS response 275 of FIG. 2 are managed by one or more DNS resolvers 110 and 110a-110n of system 100 of FIG. n, ACL or filter 115a, ACL or filter 115b, cache 120, threat intelligence system 125, AI / ML system 130, authoritative name server 135, client device 150a or 150b, UDP request 160, response 165, TCP request 170, and DNS response 175, respectively, and the descriptions of these components of system 100 in FIG. 1 are equally applicable to the corresponding components in FIG. 2.

[0059] During operation, DNS resolver 210a may receive UDP request 260 from client device 250. UDP request 260 may include, but is not limited to, a source address (including, but not limited to, at least one of a source port or a source IP address, and / or the like) and a query for a destination DNS record associated with at least one of a destination device (not shown), a destination entity (not shown) associated with the destination device, or a destination domain (not shown) associated with the destination device or destination entity within a network (e.g., network 145 of FIG. 1 , or the like). One, or a combination of two or more of DNS resolver 210a, ACL or filter 215a, router ACL or filter 215b, third-party ACL or filter 215c, threat intelligence system 225, and / or AI / ML system 230 (collectively “computing systems,” or the like) may send a UDP-based response message 265, which is a message with an empty payload portion and a set TC flag. A TC flag set in a UDP-based response message may instruct client device 250 to retransmit UDP request 260 as a TCP-based DNS request. Thus, various embodiments leverage the functionality of the truncation flag as a novel feature to improve DNS security. The truncation flag is traditionally used in UDP responses whose payload size exceeds 512 bytes (and therefore whose payload is truncated) to request or indicate that the UDP message (to which the UDP response is responding) be retransmitted as a TCP message, so that a corresponding TCP response (not bound by the 512-byte payload limit) may be sent.

[0060] If client device 250 sends TCP request 270 corresponding to UDP request 260, and the computing system receives TCP request 270 within a first response window (e.g., the first predetermined period described above with respect to FIG. 1 , or a similar period) and (optionally) determines that the DNS request is legitimate, the computing system may allow UDP requests received from client device 250 and / or other devices associated with the source address, or the like (including UDP request 260 and any other UDP requests received from client device 250 within a second response window (e.g., the second predetermined period described above with respect to FIG. 1 , or a similar period) after receiving TCP request 270) to be processed, thereby granting access to the network (e.g., network 145 of FIG. 1 , or the like). For example, the computing system may process a query for a destination DNS record by first searching a cache (e.g., cache 220, or the like) that is communicatively coupled to (or integrated with) the computing system. If the destination DNS record is contained in the cache, the computing system may send DNS response 275b (including the destination DNS record retrieved from the cache) to client device 250. If it is not contained in the cache, the computing system may send DNS request 280, which relays the query for the destination DNS record to authoritative name server 235. If found by authoritative name server 235 (e.g., from database 140 of FIG. 1 , or the like), authoritative name server 235 may send DNS response 275a (including the found destination DNS record) to the computing system, which may forward DNS response 275a to client device 250 as DNS response 275b. If not found, DNS responses 275a and 275b include a message indicating that the destination DNS record was not found.

[0061] According to some embodiments, the computing system may communicate with each of a plurality of DNS resolvers (e.g., DNS resolvers 210b-210n among one or more DNS resolvers 210a-210n, or the like) to enable one or more other UDP-based DNS requests from at least one of client device 250 or one or more other client devices associated with the source address and / or any of the source address's associated entities (not shown) to be processed, and queries for any other destination DNS records within such other UDP-based DNS requests to be answered by the DNS system.

[0062] These and other features of example 200 (and its components) are described in more detail herein with respect to FIGS.

[0063] FIG. 3 is a diagram illustrating a non-limiting example 300 of access denial conditions when implementing DNS security improvements, according to various embodiments.

[0064] In some embodiments, DNS resolvers 310a-310n, ACL or filter 315a, ACL or filter 315b or 315c, cache 320, threat intelligence system 325, AI / ML system 330, authoritative name server 335, client device 350, UDP request 360, and response 365 of FIG. 3 may be similar, if not identical, to one or more DNS resolvers 110 and 110a-110n, ACL or filter 115a, ACL or filter 115b, cache 120, threat intelligence system 125, AI / ML system 130, authoritative name server 135, client device 150a or 150b, UDP request 160, and response 165, respectively, of system 100 of FIG. 1, and descriptions of these components of system 100 of FIG. 1 are equally applicable to the corresponding components of FIG. 2. Similarly, DNS resolvers 310a-310n, ACLs or filters 315a-315c, cache 320, threat intelligence system 325, AI / ML system 330, authoritative name server 335, client device 350, UDP request 360, and response 365 of FIG. 3 may be similar to, if not identical to, DNS resolvers 210a-210n, ACLs or filters 215a-215c, cache 220, threat intelligence system 225, AI / ML system 230, authoritative name server 235, client device 250, UDP request 260, and response 265, respectively, of example 200 of FIG. 2, and descriptions of these components of example 200 of FIG. 2 are equally applicable to the corresponding components of FIG. 3.

[0065] In operation, if, after sending response message 365 (similar to or similar to sending response message 265 in the non-limiting example of FIG. 2), client device 350 fails to send a TCP request corresponding to UDP request 360 (such as TCP request 270 of FIG. 2, or the like) within the first response window, the computing system may determine that the DNS request is not legitimate and may block subsequent UDP requests from client device 350, the device associated with the source address, and / or the entity with which client device 350 and / or the source address is associated, thereby blocking access to the network (e.g., network 145 of FIG. 1, or the like).

[0066] According to some embodiments, the computing system may communicate with each of the multiple DNS resolvers (e.g., DNS resolvers 310b-310n among one or more DNS resolvers 310a-310n, or the like) to deny access to the network to one or more other UDP-based DNS requests from at least one of client device 350 or one or more other client devices associated with either the source address and / or corresponding entity (not shown).

[0067] These and other features of example 300 (and its components) are described in more detail herein with respect to FIGS.

[0068] 4A-4F (collectively "FIG. 4") are flow diagrams illustrating a method 400 for implementing DNS security improvements, according to various embodiments. Method 400 in FIG. 4A follows the circular marker designated "A" to FIG. 4F and returns to FIG. 4A following the circular marker designated "B." Method 400 in FIG. 4A follows the circular marker designated "C" to FIG. 4C and returns to FIG. 4A following the circular marker designated "D." Method 400 in FIG. 4A follows the circular marker designated "E" to FIG. 4E and returns to FIG. 4A following the circular marker designated "D."

[0069] While the techniques and procedures are illustrated and / or described in a particular order for purposes of explanation, it should be understood that certain procedures may be reordered and / or omitted within the scope of various embodiments. Additionally, while the method 400 shown in Figure 4 may be implemented by or using (and, in some cases, is described below with respect to) each of the systems, examples, or embodiments 100, 200, and 300 (or components thereof) of Figures 1, 2, and 3, such methods may also be implemented using any suitable hardware (or software) implementation. Similarly, while each of the systems, examples, or embodiments 100, 200, and 300 (or components thereof) of Figures 1, 2, and 3 can operate according to the method 400 shown in Figure 4 (e.g., by executing instructions embodied on a computer-readable medium), each of the systems, examples, or embodiments 100, 200, and 300 of Figures 1, 2, and 3 can also operate according to other modes of operation and / or perform other suitable procedures.

[0070] 4A, block 405 of method 400 may include receiving, by a Domain Name System ("DNS") computing system, a first User Datagram Protocol ("UDP")-based DNS request. In some cases, the first UDP-based DNS request may include a source address and a query for a destination DNS record associated with at least one of, but not limited to, a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or destination entity.

[0071] At block 410, method 400 may include transmitting, by the computing system, a UDP-based response message to the source address in response to receiving the first UDP-based DNS request, the UDP-based response message including an empty payload portion and a header portion including a truncation ("TC") flag set. In some examples, the TC flag set in the UDP-based response message may instruct the source address to retransmit the first UDP-based DNS request as a Transmission Control Protocol ("TCP")-based DNS request.

[0072] In some embodiments, the computing system may include at least one of, but is not limited to, a DNS resolver, a DNS recursive resolver ("recurser"), a DNS root name server, a top-level domain ("TLD") name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence ("AI") system, a machine learning ("ML") system, a virtual machine ("VM"), or software running on the computing system, and / or the like. In some cases, the source address may include, but is not limited to, at least one of, a source port or a source IP address, and / or the like.

[0073] In some examples, method 400 may proceed from the process of block 410 to the process of block 415. In other examples, method 400 may proceed to the process of block 485 of Figure 4F by following the circular marker designated "A" and then return to the process of block 415 of Figure 4A as indicated by the circular marker designated "B."

[0074] At block 415, method 400 may include, if a first TCP-based DNS request corresponding to the first UDP-based DNS request is received from the source address within a first predetermined period, sending, by the computing system, a TCP-based response message including an answer to the query for the destination DNS record to the source address. By way of example only, in some cases, for the first TCP-based DNS request to correspond to the first UDP-based DNS request, at least one of the query, query type, query source, or mail exchange (“MX”) record of the first UDP-based DNS request should be the same as at least one of the query, query type, query source, or MX record of the corresponding first TCP-based DNS request, or vice versa.

[0075] In some examples, method 400 may return from the process of block 415 to the process of block 420. In other examples, method 400 may proceed according to the circular marker designated "C" in FIG. 4A to the process of one or more of block 435, block 440, block 445, and / or block 450, or the like, as shown in FIG. 4C, and then return to the process of block 405 in FIG. 4A, as indicated by the circular marker designated "D."

[0076] The method 400 may further include, at block 420, causing the computing system to block one or more second UDP-based DNS requests from the source address if a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within a first predetermined period of time, the one or more second UDP-based DNS requests including the first UDP-based DNS request.

[0077] In some examples, method 400 may return from the process of block 420 to the process of block 405. In other examples, method 400 may proceed to the process of block 475 of Figure 4E according to the circular marker designated "E" and then return to the process of block 405 of Figure 4A as indicated by the circular marker designated "D."

[0078] Referring to the non-limiting example of FIG. 4B, sending the TCP-based response message (block 415) may include one of: sending, by the computing system, a destination DNS record to the source address based on the first UDP-based DNS request and / or the first TCP-based DNS request, the destination DNS record being obtained from at least one of the computing system's cache or a lookup of an authoritative name server (block 425); or sending, by the computing system, a message to the source address indicating that the destination DNS record was not found (block 430).

[0079] Referring to the non-limiting example of FIG. 4C, (in accordance with the circular marker designated “C” in FIG. 4A) method 400 may include at least one of: after receiving a first TCP-based DNS request corresponding to the first UDP-based DNS request, updating, by the computing system, one or more rules of at least one access control list (“ACL”) to allow the source address access to the network (block 435); causing, by the computing system, to process one or more second UDP-based DNS requests received by the computing system from the source address (block 440); causing, by the computing system, a threat intelligence system to communicate with each of a plurality of DNS resolvers to enable one or more third UDP-based DNS requests received by the plurality of DNS resolvers from the source address to be processed (block 445); or causing, by the computing system, to process one or more fourth UDP-based DNS requests received from the source address within a second predetermined period after receiving the first TCP-based DNS request (block 450). As used herein, causing a UDP-based DNS request to be processed may refer to retrieving the destination DNS record in response to the query in the UDP-based DNS request from at least one of a computing system cache or an authoritative name server lookup, and / or sending a message indicating that the destination DNS record was not found, or the like.

[0080] The method 400 may return to the process of block 405 of FIG. 4A by following the circular marker designated "D."

[0081] Referring to the non-limiting example of FIG. 4D , blocking one or more second UDP-based DNS requests from the source address (block 420) may include at least one of: updating, by the computing system, one or more rules of at least one ACL to deny the source address access to the network (block 455); dropping, by the computing system, all DNS requests from the source address (block 460); filtering, by the computing system, all DNS requests from the source address (block 465); or causing, by the computing system, all DNS requests received from the source address to be blocked for a third predetermined period of time (block 470); and / or the like.

[0082] At block 475 of FIG. 4E (following the circular marker designated "E" in FIG. 4A), method 400 may include analyzing, by the computing system, using the machine learning model, one or more fifth UDP-based DNS requests received from the source address after a second predetermined period of time to determine whether to block the one or more fifth UDP-based DNS requests; and performing, by the computing system, one or more DNS tasks based on the analysis (block 480).

[0083] The method 400 may return to the process of block 405 of FIG. 4A by following the circular marker designated "D."

[0084] At block 485 of FIG. 4E (following the circular marker designated "A" in FIG. 4A), method 400 may include dropping, by the computing system, any one or more sixth UDP-based DNS requests received from the source address after receiving the first UDP-based DNS request and before receiving the first TCP-based DNS request.

[0085] The method 400 may return to the process of block 415 of FIG. 4A by following the circular marker designated "B."

[0086] In some embodiments, method 400 may further comprise determining whether the first UDP-based DNS request is a legitimate DNS request (not shown), which may include at least one of: determining, by the computing system, that the first UDP-based DNS request is one of several UDP-based DNS requests that exceed a predetermined number of requests within a fourth predetermined period and that are received from a source address (not shown); or determining, by the computing system, that an ACL already indicates that the source address should be denied access to the network (not shown); and / or the like.

[0087] Exemplary System and Hardware Implementation

[0088] Figure 5 is a block diagram illustrating an exemplary computer or system hardware architecture according to various embodiments. Figure 5 provides a schematic diagram of one embodiment of service provider system hardware computer system 500 capable of performing the methods provided by various other embodiments described herein and / or performing computer or hardware system functionality (i.e., computing system 105, domain name system (“DNS”) resolvers 110, 110a-110n, 210a-210n, and 310a-310n, access control lists (“ACLs”) or filters 115a, 115b, 215a-215c, and 315a-315c, caches 120, 220, and 320, threat intelligence systems 125, 225, and 325, artificial intelligence (“AI”) / machine learning (“ML”) systems 130, 230, and 330, authoritative name servers 135, 235, and 335, etc.), as described above. It should be noted that Figure 5 is intended only to provide a general illustration of the various components, and that one or more (or none) of each component may be utilized, as desired. Figure 5 thus broadly illustrates how individual system elements may be implemented in a relatively decoupled manner or in a relatively more integrated manner.

[0089] Computer or hardware system 500 (which may represent an embodiment of the computer or hardware systems described above with respect to Figures 1-4 (i.e., computing system 105, DNS resolvers 110, 110a-110n, 210a-210n, and 310a-310n, ACLs or filters 115a, 115b, 215a-215c, and 315a-315c, caches 120, 220, and 320, threat intelligence systems 125, 225, and 325, AI / ML systems 130, 230, and 330, authoritative name servers 135, 235, and 335, etc.)) is shown to include hardware elements that can be electrically coupled (or otherwise communicate, as appropriate) via bus 505. The hardware elements may include one or more processors 510, including, but not limited to, one or more general-purpose processors and / or one or more special-purpose processors (such as, but not limited to, microprocessors, digital signal processing chips, graphics acceleration processors, and / or the like); one or more input devices 515, which may include, but are not limited to, a mouse, a keyboard, and / or the like; and one or more output devices 520, which may include, but are not limited to, a display device, a printer, and / or the like.

[0090] The computer or hardware system 500 may further include (and / or communicate with) one or more storage devices 525, which may include, but are not limited to, local and / or network-accessible storage, and / or may include, but are not limited to, disk drives, drive arrays, optical storage devices, solid-state storage devices, such as random access memory ("RAM") and / or read-only memory ("ROM"), which may be programmable, flash-updateable, and / or the like. Such storage devices may be configured to implement any suitable data store, including, but not limited to, various file systems, database structures, and / or the like.

[0091] The computer or hardware system 500 may also include a communications subsystem 530, which may include, but is not limited to, a modem, a network card (wireless or wired), an infrared communications device, a wireless communications device and / or chipset (such as a Bluetooth™ device, an 802.11 device, a Wi-Fi® device, a WiMAX® device, a wireless wide area network (“WWAN”) device, a cellular communications facility, etc.), and / or the like. The communications subsystem 530 may enable data exchange with a network (such as the networks described below, to name a few), with other computers or hardware systems, and / or with any other device described herein. In many embodiments, the computer or hardware system 500 further comprises a working memory 535, which may include a RAM or a ROM device, as described above.

[0092] The computer or hardware system 500 may also include software elements shown as currently located in the working memory 535, including other code such as an operating system 540, device drivers, executable libraries, and / or one or more application programs 545, which may include computer programs provided by various embodiments (including, but not limited to, a hypervisor, a virtual machine ("VM"), or the like), and / or may be designed to implement methods and / or configure systems provided by other embodiments as described herein. By way of example only, one or more procedures described with respect to one or more methods discussed above may be implemented as computer (and / or processor within a computer) executable code and / or instructions; in one aspect, such code and / or instructions may then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations in accordance with the described methods.

[0093] A set of these instructions and / or code may be encoded on and / or stored on a non-transitory computer-readable storage medium, such as storage device 525 described above. In some cases, the storage medium may be incorporated within a computer system, such as system 500. In other embodiments, the storage medium may be separate from the computer system (i.e., a removable medium such as a compact disc) and / or may be provided in an installation package, such that the storage medium can be used to program, configure, and / or adapt a general-purpose computer using the stored instructions / code. These instructions may be in the form of executable code that can be executed by computer or hardware system 500 and / or may be in the form of source and / or installable code that takes the form of executable code when compiled and / or installed on computer or hardware system 500 (e.g., using any of a variety of publicly available compilers, installation programs, compression / decompression utilities, etc.).

[0094] It will be apparent to those skilled in the art that significant variations may be made according to particular requirements. For example, customized hardware (such as programmable logic controllers, field programmable gate arrays, application specific integrated circuits, and / or the like) may also be used, and / or particular elements may be implemented in hardware, software (including portable software such as applets, etc.), or both. Furthermore, connection to other computing devices, such as network input / output devices, may be employed.

[0095] As noted above, in one aspect, some embodiments may employ a computer or hardware system (such as computer or hardware system 500) to perform methods according to various embodiments of the present invention. According to one set of embodiments, some or all of the steps of such methods are performed by computer or hardware system 500 in response to processor 510 executing one or more sequences of one or more instructions contained in working memory 535 (which may be embodied in other code, such as operating system 540 and / or application program 545). Such instructions may be read into working memory 535 from another computer-readable medium, such as one or more of storage devices 525. By way of example only, execution of the sequences of instructions contained in working memory 535 may cause processor 510 to perform one or more steps of the methods described herein.

[0096] As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any medium that participates in providing data that causes a machine to operate in a specific fashion. In embodiments implemented using a computer or hardware system 500, various computer-readable media may be involved in providing instructions / code to the processor 510 for execution and / or may be used to store and / or transmit such instructions / code (e.g., as signals). In many implementations, the computer-readable medium is a non-transitory physical and / or tangible storage medium. In some embodiments, the computer-readable medium may take many forms, including, but not limited to, non-volatile media, volatile media, or the like. Non-volatile media include, for example, optical and / or magnetic disks, such as storage device(s) 525. Volatile media include, but are not limited to, dynamic memory, such as the working memory 535. In some alternative embodiments, computer-readable media may take the form of transmission media, including, but not limited to, coaxial cables, copper wire, and fiber optics, including the wiring that comprises bus 505, and various components of communications subsystem 530 (and / or the media through which communications subsystem 530 provides for communications with other devices). In an alternative set of embodiments, transmission media may also take the form of waves (including, but not limited to, radio waves, sound waves, and / or light waves, such as those generated during radio wave and infrared data communications).

[0097] Common forms of physical and / or tangible computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape or any other magnetic medium, CD-ROMs, any other optical medium, punch cards, paper tape, any other physical medium with a pattern of holes, RAM, PROMs, and EPROMs, FLASH®-EPROMs, any other memory chips or cartridges, carrier waves as described below, or any other medium from which a computer can read instructions and / or code.

[0098] Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to processor 510 for execution. By way of example only, the instructions may initially be carried on a magnetic and / or optical disk of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit the instructions as signals over a transmission medium for receipt and / or execution by computer or hardware system 500. These signals, which may be in the form of electromagnetic, acoustic, optical, and / or the like, are all examples of carrier waves that may encode instructions according to various embodiments of the present invention.

[0099] The communications subsystem 530 (and / or its components) typically receives signals, and the bus 505 may then transmit the signals (and / or the data, instructions, etc. carried by the signals) to the working memory 535, from which the processor 505 retrieves and executes the instructions. The instructions received by the working memory 535 may optionally be stored on a storage device 525 either before or after execution by the processor 510.

[0100] While certain features and aspects have been described with reference to illustrative embodiments, those skilled in the art will recognize that many modifications are possible. For example, the methods and processes described herein may be implemented using hardware components, software components, and / or any combination thereof. Furthermore, while the various methods and processes described herein may be described with reference to particular structural and / or functional components for ease of explanation, the methods provided by various embodiments are not limited to any particular structural and / or functional architecture, but may be implemented in any suitable hardware, firmware, and / or software configuration. Similarly, although particular functionality may be attributed to particular system components, unless the context dictates otherwise, this functionality may be distributed among various other system components according to some embodiments.

[0101] Furthermore, although the steps of the methods and processes described herein are described in a particular order for ease of description, various steps may be reordered, added, and / or omitted according to various embodiments, unless the context dictates otherwise. Furthermore, steps described with respect to one method or process may be incorporated within other described methods or processes; similarly, system components described according to a particular structural architecture and / or with respect to one system may be organized in alternative structural architectures and / or incorporated within other described systems. Thus, while various embodiments are described with or without particular features for ease of description and to illustrate exemplary aspects of those embodiments, various components and / or features described herein with respect to particular embodiments may be substituted, added, and / or subtracted from other described embodiments, unless the context dictates otherwise. Consequently, while several exemplary embodiments have been described above, it should be understood that the invention is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

1. receiving, by a Domain Name System ("DNS") computing system, a first User Datagram Protocol ("UDP")-based DNS request, the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or the destination entity; sending, by the computing system in response to receiving the first UDP-based DNS request, a UDP-based response message to the source address, the UDP-based response message having an empty payload portion and a header portion including a set truncation ("TC") flag; sending, by the computing system, a TCP-based response message to the source address containing an answer to the query for the destination DNS record if a first Transmission Control Protocol ("TCP")-based DNS request corresponding to the first UDP-based DNS request is received from the source address within a first predetermined period of time; and causing, by the computing system, UDP-based DNS requests from the source address to be blocked if a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within the first predetermined period of time. A method for providing

2. 10. The method of claim 1, wherein the computing system comprises at least one of a DNS resolver, a DNS recursive resolver ("recurser"), a DNS root name server, a top-level domain ("TLD") name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence ("AI") system, a machine learning ("ML") system, a virtual machine ("VM"), or software running on the computing system.

3. The method of claim 1 , wherein the source address comprises at least one of a source port or a source IP address.

4. transmitting the TCP-based response message comprises: sending, by the computing system, the destination DNS record to the source address, the destination DNS record being obtained from at least one of the computing system's cache or a lookup of an authoritative name server; or sending, by the computing system, a message to the source address indicating that the destination DNS record was not found. The method of claim 1 , wherein the first and second inputs are selected from the group consisting of:

5. 2. The method of claim 1, further comprising, after receiving the first TCP-based DNS request corresponding to the first UDP-based DNS request, updating, by the computing system, one or more rules of at least one access control list ("ACL") to allow the source address access to the network.

6. after receiving the first TCP-based DNS request corresponding to the first UDP-based DNS request; causing the computing system to process one or more second UDP-based DNS requests received by the computing system from the source address; or 10. The method of claim 1, further comprising: causing, by the computing system, a threat intelligence system to communicate with each of a plurality of DNS resolvers to enable one or more third UDP-based DNS requests received by the plurality of DNS resolvers from the source address to be processed.

7. 2. The method of claim 1, further comprising causing the computing system to process one or more fourth UDP-based DNS requests received from the source address within a second predetermined period of time after receiving the first TCP-based DNS request.

8. analyzing, by the computing system, one or more fifth UDP-based DNS requests received from the source address after the second predetermined period using a machine learning model to determine whether to block the one or more fifth UDP-based DNS requests; and The method of claim 7 , further comprising performing, by the computing system, one or more DNS tasks based on the analysis.

9. causing the UDP-based DNS request from the source address to be blocked, updating, by the computing system, one or more rules of at least one access control list ("ACL") to deny access to the network to the source address; dropping, by said computing system, all DNS requests from said source address; or 2. The method of claim 1, further comprising at least one of: filtering, by the computing system, all DNS requests from the source address.

10. 10. The method of claim 9, wherein causing the first UDP-based DNS request from the source address to be blocked comprises causing the computing system to block all DNS requests received from the source address for a third predetermined period of time.

11. 2. The method of claim 1, further comprising: dropping, by the computing system, any one or more sixth UDP-based DNS requests received from the source address after receiving the first UDP-based DNS request and before receiving the first TCP-based DNS request.

12. 2. The method of claim 1, wherein at least one of a query, a query type, a query source, or a mail exchange ("MX") record of the first UDP-based DNS request is the same as at least one of a query, a query type, a query source, or a MX record of a corresponding first TCP-based DNS request.

13. determining, by the computing system, whether the first UDP-based DNS request is a valid DNS request; determining, by the computing system, that the first UDP-based DNS request is one of a number of UDP-based DNS requests received from the source address that exceed a predetermined number of requests within a fourth predetermined period of time; or 10. The method of claim 1, further comprising determining, by the computing system performing at least one of the steps of: determining that an ACL already indicates that the source address should be denied access to the network.

14. at least one first processor; and a first non-transitory computer-readable medium communicatively coupled to the at least one first processor, the first non-transitory computer-readable medium comprising: receiving a first User Datagram Protocol (“UDP”) based DNS request, the first UDP based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or the destination entity; causing the source address to send a UDP-based response message in response to receiving the first UDP-based DNS request, the UDP-based response message having an empty payload portion and a header portion including a set truncation ("TC") flag; causing a TCP-based response message to be sent to the source address including an answer to the query for the destination DNS record if a first Transmission Control Protocol ("TCP")-based DNS request corresponding to the first UDP-based DNS request is received from the source address within a first predetermined period of time; and Blocking UDP-based DNS requests from the source address if a TCP-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within the first predetermined period of time. a first non-transitory computer-readable medium having stored thereon computer software including a first set of instructions; A system comprising the computing system having:

15. 15. The system of claim 14, wherein the computing system comprises at least one of a DNS resolver, a DNS recursive resolver ("recurser"), a DNS root name server, a top-level domain ("TLD") name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence ("AI") system, a machine learning ("ML") system, a virtual machine ("VM"), or software running on the computing system.

16. 15. The system of claim 14, wherein the source address comprises at least one of a source port or a source IP address.

17. a step of causing the UDP-based DNS request from the source address to be blocked, the step comprising: updating one or more rules in at least one access control list ("ACL") to deny access to the network to the source address; Dropping all DNS requests from said source address; or filtering all DNS requests from said source address; The system of claim 14 , comprising at least one of:

18. receiving, by a Domain Name System ("DNS") computing system, a first User Datagram Protocol ("UDP")-based DNS request, the first UDP-based DNS request including a source address and a query for a destination DNS record associated with at least one of a destination device in a network, a destination entity associated with the destination device, or a destination domain associated with the destination device or the destination entity; sending, by the computing system in response to receiving the first UDP-based DNS request, a UDP-based response message to the source address, the UDP-based response message having an empty payload portion and a header portion including a set truncation ("TC") flag; causing, by the computing system, one or more second UDP-based DNS requests from the source address to be blocked if a first Transmission Control Protocol ("TCP")-based DNS request corresponding to the first UDP-based DNS request is not received from the source address within a first predetermined period of time, the one or more second UDP-based DNS requests comprising the first UDP-based DNS request; causing, if a first TCP-based DNS request corresponding to the first UDP-based DNS request is received from the source address within the first predetermined period of time, the computing system to allow at least the first UDP-based DNS request from the source address to be processed by sending at least a TCP-based response message to the source address within a second predetermined period of time after receiving the first TCP-based DNS request, the TCP-based response message including an answer to the query for the destination DNS record; receiving, by the computing system, one or more third UDP-based DNS requests from the source address after the second predetermined period of time; analyzing, by the computing system, the one or more third UDP-based DNS requests using a machine learning model to determine whether to block the one or more third UDP-based DNS requests; and performing, by the computing system, one or more DNS tasks based on the analysis. A method for providing

19. 20. The method of claim 18, wherein the computing system comprises at least one of a DNS resolver, a DNS recursive resolver ("recurser"), a DNS root name server, a top-level domain ("TLD") name server, an authoritative name server, a threat intelligence system, a threat mitigation system, a server, an artificial intelligence ("AI") system, a machine learning ("ML") system, a virtual machine ("VM"), or software running on the computing system.

20. causing the one or more second UDP-based DNS requests from the source address to be blocked, updating, by the computing system, one or more rules of at least one access control list ("ACL") to deny access to the network to the source address; dropping, by said computing system, all DNS requests from said source address; or 20. The method of claim 18, comprising at least one of filtering, by the computing system, all DNS requests from the source address.

Images