Systems and methods for generating a DNS query to improve resistance against a DNS attack

Abstract

The present solution provides systems and methods for generating dns queries that are more resistant to being compromised by attackers. To generate the transaction identifier, the dns resolver uses a cryptographic hash function. The inputs to the hash function may include a predetermined random number, the destination IP address of the name server to be queried, and the domain name to be queried. Because of the inclusion of the name server's IP address in the formula, queries for the same domain name to different name servers may have different transaction identifiers, preventing an attacker from observing a query and predicting the identifiers for other queries. Additional entropy may be provided for generating transaction identifiers by including the port number of the name server and/or a portion of the domain name as inputs to the hash function. If it is determined that the responding server may preserve capitalization in its responses, the upper and lower case characters may be salted within the domain name to provide additional entropy in generating transaction identifiers.

Description

FIELD OF THE INVENTION

The present application generally relates to data communication networks. In particular, the present application relates to systems and methods for generating a Domain Name System [“DNS”] query to improve resistance against a DNS attack.

BACKGROUND OF THE INVENTION

The Domain Name System [“DNS”] allows human meaningful names to be associated with the numerical internet protocol [“IP”] addresses of clients, servers, or other resources on the internet. For example, the domain name www.example.com may be associated with 208.77.188.166. Domain names are mapped and indexed by name servers. Each name server is authoritative or responsible for indexing clients, servers, or other resources within its zone of authority. When a user requests a resource by domain name, a DNS resolver identifies the request. If the IP address for the requested resource is not available in its cache, the resolver initiates a query to a name server. The DNS resolver's query includes a transaction identifier. The name server's reply may also include the transaction identifier to identify the response as having come from the name server queried by the DNS resolver. If a malicious attacker can respond to a DNS resolver's request before the real name server can, the malicious attacker can direct the user to a different client, server, or resource than was intended. This opens possibilities of identity or data theft or other malicious activities.

BRIEF SUMMARY OF THE INVENTION

The present solution provides systems and methods for generating DNS queries that are more resistant to being compromised by attackers. To generate the transaction identifier, the DNS resolver uses a cryptographic hash function. The inputs to the hash function may include a predetermined random number, the destination IP address of the name server to be queried, and the domain name to be queried. Because of the inclusion of the name server's IP address in the formula, queries for the same domain name to different name servers may have different transaction identifiers, preventing an attacker from observing a query and predicting the identifiers for other queries. Additional entropy may be provided for generating transaction identifiers by including the port number of the name server and/or a portion of the domain name as inputs to the hash function. If it is determined that the responding server may preserve capitalization in its responses, the upper and lower case characters may be salted within the domain name to provide additional entropy in generating transaction identifiers.

In one aspect, the present invention features a method for generating a DNS query to improve resistance against a DNS attack. The method includes a DNS resolver receiving a request to resolve a domain name. The method also includes the DNS resolver identifying the domain name and an IP address of a DNS server. The method further includes generating a transaction identifier for a DNS query by applying a one-way hash function to an input of a predetermined random number, the IP address of the DNS server and the domain name. The method also includes the DNS resolver transmitting a DNS query for the domain name to the DNS server, the DNS query identified by the generated transaction identifier.

In some embodiments, the method includes the DNS resolver identifying the IP port number of the DNS server. In further embodiments, the method includes generating the transaction identifier for the DNS query by applying the one-way hash function to the input of a predetermined random number, the IP address and the port of the DNS server, and the domain name. In yet further embodiments, the domain name input to the one-way hash function may comprise a portion of the domain name to be resolved.

In one embodiment, the method includes changing the predetermined random number input to the one-way hash function at a predetermined frequency. In another embodiment, the method includes changing the predetermined random number in response to an event. In other embodiments, the method includes generating the same transaction identifier for DNS queries to resolve the same domain name transmitted to the same DNS server. In still other embodiments, the method includes encoding one or more fields of the DNS request and using the encoded one or more fields as input to the one-way hash function to generate the transaction identifier. In other embodiments, the method includes encoding the domain name by capitalizing one or more characters of the domain name and generating the transaction identifier by using the encoded domain name as the input of the domain name to the one-way hash function. In still other embodiments, the method further comprises encoding the domain name input to the one-way hash function by using a punycode or a RACE encoding scheme.

In another embodiment, the method further comprises the DNS resolver determining that the DNS server rewrites or normalizes responses. In response to the determination, the DNS resolver may not encode a portion of the DNS query. In other embodiments, the method further comprises the DNS resolver determining that the destination is not rewriting responses. In response to the determination, the DNS resolver may encode a portion of the DNS query and include the encoded portion in the transaction identifier. In yet other embodiments, the method further includes the DNS resolver communicating the input of the IP address of the destination and the domain name to a transaction identifier generator.

In another aspect, the present invention features a system for generating a DNS query to improve resistance against a DNS attack. The system includes a DNS resolver and a transaction identifier generator. The DNS resolver receives a request to resolve a domain name and identifies the domain name and an IP address of a destination of the request. The transaction identifier generator that generates a transaction identifier by applying a one-way hash function to an input of a predetermined random number, the IP address of the destination and the domain name. The DNS resolver forms the DNS query using the generated transaction identifier and transmits the DNS query for the domain name to the destination.

In one embodiment, the DNS resolver identifies a port of the destination of the request. In further embodiments, the transaction identifier generator may generate the transaction identifier by applying the one-way hash function to the input of the predetermined random number, the internet protocol address and the port of the destination and the domain name. In still further embodiments, the domain name input to the one-way hash function may comprise a portion of the domain name to be resolved.

In another embodiment, the transaction identifier generator changes the predetermined random number at a predetermined frequency. In yet another embodiment, the transaction identifier generator changes the predetermined random number in response to an event. In still another embodiment, the transaction identifier generator generates the same transaction identifier for inputs identifying the same domain name and the same destination.

In other embodiments, the DNS resolver encodes one or more fields of the DNS request and communicates the encoded one or more fields as input to the transaction identifier generator to generate the transaction identifier. In another embodiment, the DNS resolver encodes the domain name by capitalizing one or more characters of the domain name and communicates the encoded domain name as the input of the domain name to the transaction identifier generator. In still another embodiment, the DNS resolver encodes the domain name by using a punycode or a RACE encoding scheme. In other embodiments, the DNS resolver may determine that the destination rewrites or normalizes responses, and in response to the determination the DNS resolver may not encode a portion of the DNS query. In yet other embodiments, the DNS resolver may determine that the destination does not rewrite responses, and in response to the determination the DNS resolver may encode a portion of the DNS query and communicate the encoded portion as input to the transaction identifier generator to generate the transaction identifier. In still other embodiments, the DNS resolver may reside on a client, a server, or an intermediary.

The details of various embodiments of the invention are set forth in the accompanying drawings and the description below.

BRIEF DESCRIPTION OF THE FIGURES

The foregoing and other objects, aspects, features, and advantages of the invention will become more apparent and better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1A is a block diagram of an embodiment of a network environment for a client to access a server via an appliance;

FIG. 1B is a block diagram of another embodiment of an environment for delivering a computing environment from a server to a client via;

FIGS. 1C and 1D are block diagrams of embodiments of a computing device;

FIG. 2 is a block diagram of an embodiment of a domain name resolver; and

FIG. 3 is a flow diagram of an embodiment of steps of a method for generating a DNS query with improved resistance against a DNS attack.

The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements.

DETAILED DESCRIPTION OF THE INVENTION

For purposes of reading the description of the various embodiments below, the following descriptions of the sections of the specification and their respective contents may be helpful:

Section A describes a network environment and computing environment which may be useful for practicing embodiments described herein;

Section B describes embodiments of systems and methods for responding to DNS name resolution requests, transmitting requests to name servers, receiving responses from name servers, and transmitting responses to DNS name resolution requests; and

Section C describes embodiments of systems for and methods of generating DNS queries with improved resistance to DNS attacks.

A. Network and Computing Environment

Prior to discussing the specifics of embodiments of the systems and methods of an appliance and/or client, it may be helpful to discuss the network and computing environments in which such embodiments may be deployed. Referring now to FIG. 1A, an embodiment of a network environment is depicted. In brief overview, the network environment comprises one or more clients 102a-102n (also generally referred to as local machine(s) 102, or client(s) 102) in communication with one or more servers 106a-106n (also generally referred to as server(s) 106, or remote machine(s) 106) via one or more networks 104, 104′ (generally referred to as network 104). In some embodiments, a client 102 communicates with a server 106 via an appliance 105.

Although FIG. 1A shows a network 104 and a network 104′ between the clients 102 and the servers 106, the clients 102 and the servers 106 may be on the same network 104. The networks 104 and 104′ can be the same type of network or different types of networks. The network 104 and/or the network 104′ can be a local-area network (LAN), such as a company Intranet, a metropolitan area network (MAN), or a wide area network (WAN), such as the Internet or the World Wide Web. In one embodiment, network 104′ may be a private network and network 104 may be a public network. In some embodiments, network 104 may be a private network and network 104′ a public network. In another embodiment, networks 104 and 104′ may both be private networks. In some embodiments, clients 102 may be located at a branch office of a corporate enterprise communicating via a WAN connection over the network 104 to the servers 106 located at a corporate data center.

The network 104 and/or 104′ be any type and/or form of network and may include any of the following: a point to point network, a broadcast network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an ATM (Asynchronous Transfer Mode) network, a SONET (Synchronous Optical Network) network, a SDH (Synchronous Digital Hierarchy) network, a wireless network and a wireline network. In some embodiments, the network 104 may comprise a wireless link, such as an infrared channel or satellite band. The topology of the network 104 and/or 104′ may be a bus, star, or ring network topology. The network 104 and/or 104′ and network topology may be of any such network or network topology as known to those ordinarily skilled in the art capable of supporting the operations described herein.

As shown in FIG. 1A, the appliance 105, which also may be referred to as an interface unit 105 or gateway 105, is shown between the networks 104 and 104′. In some embodiments, the appliance 105 may be located on network 104. For example, a branch office of a corporate enterprise may deploy an appliance 105 at the branch office. In other embodiments, the appliance 105 may be located on network 104′. For example, an appliance 105 may be located at a corporate data center. In yet another embodiment, a plurality of appliances 105 may be deployed on network 104. In some embodiments, a plurality of appliances 105 may be deployed on network 104′. In other embodiments, a plurality of appliances 105 may be deployed on both networks 104 and 104′. In other embodiments, the appliance 105 could be a part of any client 102 or server 106 on the same or different network 104, 104′ as the client 102. One or more appliances 105 may be located at any point in the network or network communications path between a client 102 and a server 106.

In some embodiments, the appliance 105 comprises any of the network devices manufactured by Citrix Systems, Inc. of Ft. Lauderdale Fla., such as the Citrix NetScaler™, Citrix WANScaler™, Citrix Repeater™, Citrix Branch Repeater™, or Citrix Branch Repeater™ with Windows Server®. In other embodiments, the appliance 105 includes any of the product embodiments referred to as WebAccelerator and BigIP manufactured by F5 Networks, Inc. of Seattle, Wash. In yet another embodiment, the appliance 105 includes any application acceleration and/or security related appliances and/or software manufactured by Cisco Systems, Inc. of San Jose, Calif., such as the Cisco ACE Application Control Engine Module service software and network modules, and Cisco AVS Series Application Velocity System.

In one embodiment, the system may include multiple, logically-grouped servers 106. In these embodiments, the logical group of servers may be referred to as a server farm 38. In some of these embodiments, the servers 106 may be geographically dispersed. In some cases, a farm 38 may be administered as a single entity. In other embodiments, the server farm 38 comprises a plurality of server farms 38. In one embodiment, the server farm executes one or more applications on behalf of one or more clients 102.

The servers 106 within each farm 38 can be heterogeneous. One or more of the servers 106 can operate according to one type of operating system platform (e.g., WINDOWS NT, manufactured by Microsoft Corp. of Redmond, Wash.), while one or more of the other servers 106 can operate on according to another type of operating system platform (e.g., Unix or Linux). The servers 106 of each farm 38 do not need to be physically proximate to another server 106 in the same farm 38. Thus, the group of servers 106 logically grouped as a farm 38 may be interconnected using a wide-area network (WAN) connection or medium-area network (MAN) connection. For example, a farm 38 may include servers 106 physically located in different continents or different regions of a continent, country, state, city, campus, or room. Data transmission speeds between servers 106 in the farm 38 can be increased if the servers 106 are connected using a local-area network (LAN) connection or some form of direct connection.

Servers 106 may be referred to as a file server, application server, web server, proxy server, or gateway server. In some embodiments, a server 106 may have the capacity to function as either an application server or as a master application server. In one embodiment, a server 106 may include an Active Directory. The clients 102 may also be referred to as client nodes or endpoints. In some embodiments, a client 102 has the capacity to function as both a client node seeking access to applications on a server and as an application server providing access to hosted applications for other clients 102a-102n.

In some embodiments, a client 102 communicates with a server 106. In one embodiment, the client 102 communicates directly with one of the servers 106 in a farm 38. In another embodiment, the client 102 executes a program neighborhood application to communicate with a server 106 in a farm 38. In still another embodiment, the server 106 provides the functionality of a master node. In some embodiments, the client 102 communicates with the server 106 in the farm 38 through a network 104. Over the network 104, the client 102 can, for example, request execution of various applications hosted by the servers 106a-106n in the farm 38 and receive output of the results of the application execution for display. In some embodiments, only the master node provides the functionality required to identify and provide address information associated with a server 106′ hosting a requested application.

In one embodiment, the server 106 provides functionality of a web server. In another embodiment, the server 106a receives requests from the client 102, forwards the requests to a second server 106b and responds to the request by the client 102 with a response to the request from the server 106b. In still another embodiment, the server 106 acquires an enumeration of applications available to the client 102 and address information associated with a server 106 hosting an application identified by the enumeration of applications. In yet another embodiment, the server 106 presents the response to the request to the client 102 using a web interface. In one embodiment, the client 102 communicates directly with the server 106 to access the identified application. In another embodiment, the client 102 receives application output data, such as display data, generated by an execution of the identified application on the server 106.

Referring now to FIG. 1B, a network environment for delivering and/or operating a computing environment on a client 102 is depicted. In some embodiments, a server 106 includes an application delivery system 190 for delivering a computing environment or an application and/or data file to one or more clients 102. In brief overview, a client 102 is in communication with a server 106 via network 104, 104′ and appliance 105. For example, the client 102 may reside in a remote office of a company, e.g., a branch office, and the server 106 may reside at a corporate data center. The client 102 comprises a client agent 120, and a computing environment 15. The computing environment 15 may execute or operate an application that accesses, processes or uses a data file. The computing environment 15, application and/or data file may be delivered via the appliance 105 and/or the server 106.

In some embodiments, the appliance 105 accelerates delivery of a computing environment 15, or any portion thereof, to a client 102. In one embodiment, the appliance 105 accelerates the delivery of the computing environment 15 by the application delivery system 190. For example, the embodiments described herein may be used to accelerate delivery of a streaming application and data file processable by the application from a central corporate data center to a remote user location, such as a branch office of the company. In another embodiment, the appliance 105 accelerates transport layer traffic between a client 102 and a server 106. The appliance 105 may provide acceleration techniques for accelerating any transport layer payload from a server 106 to a client 102, such as: 1) transport layer connection pooling, 2) transport layer connection multiplexing, 3) transport control protocol buffering, 4) compression and 5) caching. In some embodiments, the appliance 105 provides load balancing of servers 106 in responding to requests from clients 102. In other embodiments, the appliance 105 acts as a proxy or access server to provide access to the one or more servers 106. In another embodiment, the appliance 105 provides a secure virtual private network connection from a first network 104 of the client 102 to the second network 104′ of the server 106, such as an SSL VPN connection. In yet other embodiments, the appliance 105 provides application firewall security, control and management of the connection and communications between a client 102 and a server 106.

In some embodiments, the application delivery management system 190 provides application delivery techniques to deliver a computing environment to a desktop of a user, remote or otherwise, based on a plurality of execution methods and based on any authentication and authorization policies applied via a policy engine 195. With these techniques, a remote user may obtain a computing environment and access to server stored applications and data files from any network connected device 100. In one embodiment, the application delivery system 190 may reside or execute on a server 106. In another embodiment, the application delivery system 190 may reside or execute on a plurality of servers 106a-106n. In some embodiments, the application delivery system 190 may execute in a server farm 38. In one embodiment, the server 106 executing the application delivery system 190 may also store or provide the application and data file. In another embodiment, a first set of one or more servers 106 may execute the application delivery system 190, and a different server 106n may store or provide the application and data file. In some embodiments, each of the application delivery system 190, the application, and data file may reside or be located on different servers. In yet another embodiment, any portion of the application delivery system 190 may reside, execute or be stored on or distributed to the appliance 200, or a plurality of appliances.

The client 102 may include a computing environment 15 for executing an application that uses or processes a data file. The client 102 via networks 104, 104′ and appliance 105 may request an application and data file from the server 106. In one embodiment, the appliance 105 may forward a request from the client 102 to the server 106. For example, the client 102 may not have the application and data file stored or accessible locally. In response to the request, the application delivery system 190 and/or server 106 may deliver the application and data file to the client 102. For example, in one embodiment, the server 106 may transmit the application as an application stream to operate in computing environment 15 on client 102.

In some embodiments, the application delivery system 190 comprises any portion of the Citrix Access Suite™ by Citrix Systems, Inc., such as the MetaFrame or Citrix Presentation Server™; any portion of the Citrix Delivery Center™ by Citrix Systems, Inc., such as the XenDesktop™, XenApp™, XenServer™, or NetScaler™; and/or any of the Microsoft® Windows Terminal Services manufactured by the Microsoft Corporation. In one embodiment, the application delivery system 190 may deliver one or more applications to clients 102 or users via a remote-display protocol or otherwise via remote-based or server-based computing. In another embodiment, the application delivery system 190 may deliver one or more applications to clients or users via steaming of the application.

In one embodiment, the application delivery system 190 includes a policy engine 195 for controlling and managing the access to, selection of application execution methods and the delivery of applications. In some embodiments, the policy engine 195 determines the one or more applications a user or client 102 may access. In another embodiment, the policy engine 195 determines how the application should be delivered to the user or client 102, e.g., the method of execution. In some embodiments, the application delivery system 190 provides a plurality of delivery techniques from which to select a method of application execution, such as a server-based computing, streaming or delivering the application locally to the client 120 for local execution.

In one embodiment, a client 102 requests execution of an application program and the application delivery system 190 comprising a server 106 selects a method of executing the application program. In some embodiments, the server 106 receives credentials from the client 102. In another embodiment, the server 106 receives a request for an enumeration of available applications from the client 102. In one embodiment, in response to the request or receipt of credentials, the application delivery system 190 enumerates a plurality of application programs available to the client 102. The application delivery system 190 receives a request to execute an enumerated application. The application delivery system 190 selects one of a predetermined number of methods for executing the enumerated application, for example, responsive to a policy of a policy engine. The application delivery system 190 may select a method of execution of the application enabling the client 102 to receive application-output data generated by execution of the application program on a server 106. The application delivery system 190 may select a method of execution of the application enabling the local machine 10 to execute the application program locally after retrieving a plurality of application files comprising the application. In yet another embodiment, the application delivery system 190 may select a method of execution of the application to stream the application via the network 104 to the client 102.

A client 102 may execute, operate or otherwise provide an application, which can be any type and/or form of software, program, or executable instructions such as any type and/or form of web browser, web-based client, client-server application, a thin-client computing client, an ActiveX control, or a Java applet, or any other type and/or form of executable instructions capable of executing on client 102. In some embodiments, the application may be a server-based or a remote-based application executed on behalf of the client 102 on a server 106. In one embodiments the server 106 may display output to the client 102 using any thin-client or remote-display protocol, such as the Independent Computing Architecture (ICA) protocol manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla. or the Remote Desktop Protocol (RDP) manufactured by the Microsoft Corporation of Redmond, Wash. The application can use any type of protocol and it can be, for example, an HTTP client, an FTP client, an Oscar client, or a Telnet client. In other embodiments, the application comprises any type of software related to VoIP communications, such as a soft IP telephone. In further embodiments, the application comprises any application related to real-time data communications, such as applications for streaming video and/or audio.

In some embodiments, the server 106 or a server farm 38 may be running one or more applications, such as an application providing a thin-client computing or remote display presentation application. In one embodiment, the server 106 or server farm 38 executes as an application, any portion of the Citrix Access Suite™ by Citrix Systems, Inc., such as the MetaFrame or Citrix Presentation Server™; any portion of the Citrix Delivery Center™ by Citrix Systems, Inc., such as the XenDesktop™, XenApp™, XenServer™, or NetScaler™; and/or any of the Microsoft® Windows Terminal Services manufactured by the Microsoft Corporation. In one embodiment, the application is an ICA client, developed by Citrix Systems, Inc. of Fort Lauderdale, Fla. In other embodiments, the application includes a Remote Desktop (RDP) client, developed by Microsoft Corporation of Redmond, Wash. Also, the server 106 may run an application, which for example, may be an application server providing email services such as Microsoft Exchange manufactured by the Microsoft Corporation of Redmond, Wash., a web or Internet server, or a desktop sharing server, or a collaboration server. In some embodiments, any of the applications may comprise any type of hosted service or products, such as GoToMeeting™, GoToWebinar™, GoToMyPC™, or GoToAssist™ provided by Citrix Online Division, Inc. of Santa Barbara, Calif., WebEx™ provided by WebEx, Inc. of Santa Clara, Calif., or Microsoft Office Live Meeting provided by Microsoft Corporation of Redmond, Wash.

The client 102, server 106, and appliance 105 may be deployed as and/or executed on any type and form of computing device, such as a computer, network device or appliance capable of communicating on any type and form of network and performing the operations described herein. FIGS. 1C and 1D depict block diagrams of a computing device 100 useful for practicing an embodiment of the client 102, server 106 or appliance 105. As shown in FIGS. 1C and 1D, each computing device 100 includes a central processing unit 101, and a main memory unit 122. As shown in FIG. 1C, a computing device 100 may include a visual display device 124, a keyboard 126 and/or a pointing device 127, such as a mouse. Each computing device 100 may also include additional optional elements, such as one or more input/output devices 130a-130b (generally referred to using reference numeral 130), and a cache memory 140 in communication with the central processing unit 101.

The central processing unit 101 is any logic circuitry that responds to and processes instructions fetched from the main memory unit 122. In many embodiments, the central processing unit is provided by a microprocessor unit, such as: those manufactured by Intel Corporation of Mountain View, Calif.; those manufactured by Motorola Corporation of Schaumburg, Ill.; those manufactured by Transmeta Corporation of Santa Clara, Calif.; the RS/6000 processor, those manufactured by International Business Machines of White Plains, N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale, Calif. The computing device 100 may be based on any of these processors, or any other processor capable of operating as described herein.

Main memory unit 122 may be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by the microprocessor 101, such as Static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM). The main memory 122 may be based on any of the above described memory chips, or any other available memory chips capable of operating as described herein. In the embodiment shown in FIG. 1C, the processor 101 communicates with main memory 122 via a system bus 150 (described in more detail below). FIG. 1C depicts an embodiment of a computing device 100 in which the processor communicates directly with main memory 122 via a memory port 103. For example, in FIG. 1D the main memory 122 may be DRDRAM.

FIG. 1D depicts an embodiment in which the main processor 101 communicates directly with cache memory 140 via a secondary bus, sometimes referred to as a backside bus. In other embodiments, the main processor 101 communicates with cache memory 140 using the system bus 150. Cache memory 140 typically has a faster response time than main memory 122 and is typically provided by SRAM, BSRAM, or EDRAM. In the embodiment shown in FIG. 1C, the processor 101 communicates with various I/O devices 130 via a local system bus 150. Various busses may be used to connect the central processing unit 101 to any of the I/O devices 130, including a VESA VL bus, an ISA bus, an EISA bus, a MicroChannel Architecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or a NuBus. For embodiments in which the I/O device is a video display 124, the processor 101 may use an Advanced Graphics Port (AGP) to communicate with the display 124. FIG. 1D depicts an embodiment of a computer 100 in which the main processor 101 communicates directly with I/O device 130 via HyperTransport, Rapid I/O, or InfiniBand. FIG. 1D also depicts an embodiment in which local busses and direct communication are mixed: the processor 101 communicates with I/O device 130 using a local interconnect bus while communicating with I/O device 130 directly.

The computing device 100 may support any suitable installation device 116, such as a floppy disk drive for receiving floppy disks such as 3.5-inch, 5.25-inch disks or ZIP disks, a CD-ROM drive, a CD-R/RW drive, a DVD-ROM drive, tape drives of various formats, USB device, hard-drive or any other device suitable for installing software and programs such as any client agent 120, or portion thereof. The computing device 100 may further comprise a storage device 128, such as one or more hard disk drives or redundant arrays of independent disks, for storing an operating system and other related software, and for storing application software programs such as any program related to the client agent 120. Optionally, any of the installation devices 116 could also be used as the storage device 128. Additionally, the operating system and the software can be run from a bootable medium, for example, a bootable CD, such as KNOPPIX®, a bootable CD for GNU/Linux that is available as a GNU/Linux distribution from knoppix.net.

Furthermore, the computing device 100 may include a network interface 118 to interface to a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25), broadband connections (e.g., ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above. The network interface 118 may comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device 100 to any type of network capable of communication and performing the operations described herein.

A wide variety of I/O devices 130a-130n may be present in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, and dye-sublimation printers. The I/O devices 130 may be controlled by an I/O controller 123 as shown in FIG. 1C. The I/O controller may control one or more I/O devices such as a keyboard 126 and a pointing device 127, e.g., a mouse or optical pen. Furthermore, an I/O device may also provide storage 128 and/or an installation medium 116 for the computing device 100. In still other embodiments, the computing device 100 may provide USB connections to receive handheld USB storage devices such as the USB Flash Drive line of devices manufactured by Twintech Industry, Inc. of Los Alamitos, Calif.

In some embodiments, the computing device 100 may comprise or be connected to multiple display devices 124a-124n, which each may be of the same or different type and/or form. As such, any of the I/O devices 130a-130n and/or the I/O controller 123 may comprise any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable or provide for the connection and use of multiple display devices 124a-124n by the computing device 100. For example, the computing device 100 may include any type and/or form of video adapter, video card, driver, and/or library to interface, communicate, connect or otherwise use the display devices 124a-124n. In one embodiment, a video adapter may comprise multiple connectors to interface to multiple display devices 124a-124n. In other embodiments, the computing device 100 may include multiple video adapters, with each video adapter connected to one or more of the display devices 124a-124n. In some embodiments, any portion of the operating system of the computing device 100 may be configured for using multiple displays 124a-124n. In other embodiments, one or more of the display devices 124a-124n may be provided by one or more other computing devices, such as computing devices 100a and 100b connected to the computing device 100, for example, via a network. These embodiments may include any type of software designed and constructed to use another computer's display device as a second display device 124a for the computing device 100. One ordinarily skilled in the art will recognize and appreciate the various ways and embodiments that a computing device 100 may be configured to have multiple display devices 124a-124n.

In further embodiments, an I/O device 130 may be a bridge 170 between the system bus 150 and an external communication bus, such as a USB bus, an Apple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a HIPPI bus, a Super HIPPI bus, a SerialPlus bus, a SCI/LAMP bus, a FibreChannel bus, or a Serial Attached small computer system interface bus.

A computing device 100 of the sort depicted in FIGS. 1C and 1D typically operate under the control of operating systems, which control scheduling of tasks and access to system resources. The computing device 100 can be running any operating system such as any of the versions of the Microsoft® Windows operating systems, the different releases of the Unix and Linux operating systems, any version of the Mac OS® for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described herein. Typical operating systems include: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, WINDOWS XP, WINDOWS VISTA, and WINDOWS 7, all of which are manufactured by Microsoft Corporation of Redmond, Wash.; MacOS, manufactured by Apple Computer of Cupertino, Calif.; OS/2, manufactured by International Business Machines of Armonk, N.Y.; and Linux, a freely-available operating system distributed by Caldera Corp. of Salt Lake City, Utah, or any type and/or form of a Unix operating system, among others.

In other embodiments, the computing device 100 may have different processors, operating systems, and input devices consistent with the device. For example, in one embodiment the computer 100 is a Treo 180, 270, 1060, 600 or 650 smart phone manufactured by Palm, Inc. In this embodiment, the Treo smart phone is operated under the control of the PalmOS operating system and includes a stylus input device as well as a five-way navigator device. In another embodiment, the computer 100 is an iPhone smart phone manufactured by Apple Computers, Inc. In this embodiment, the iPhone is operated under the control of the iPhone OS operating system and includes a multi-touch screen interface. Moreover, the computing device 100 can be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile telephone, any other computer, or other form of computing or telecommunications device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described herein.

B. DNS Resolver Architecture

FIG. 2 describes an embodiment of a DNS resolver 200 residing on a server, client, or intermediary. As shown in FIG. 2, the DNS resolver 200 includes a DNS query identifier 201, a memory cache 202, a transaction identifier generator 203, a DNS query generator 205, a comparator 206 for comparing requests and responses, and a DNS response generator 207. The DNS resolver 200 may also receive input numbers from a random number generator 204. The DNS resolver 200 receives DNS resolution requests 208 from hardware or software on the client, server, or intermediary, or from any hardware or software on another client, server, or intermediary. The DNS resolver 200 transmits DNS query messages 209 to DNS name servers, and in turn DNS receives response messages 210. The DNS response messages 210 can also arrive from different sources than the name servers. The DNS resolver 200 also transmits DNS resolution responses 211 to the hardware or software on the same or different client, server, or intermediary that sent the DNS resolution request 208. The simplified architecture shown is provided for illustration purposes only and is not intended to be limiting.

A DNS resolver 200 comprises any type or form of logic, operations or functions to resolve a domain name. The DNS resolver 200 may comprise any combination of software and hardware. The DNS resolver 200 may comprise a library, service, daemon, process, function, or subroutine. Although the random number generator 204 shown in FIG. 2 is external to the DNS resolver 200, in some embodiments the DNS resolver 200 may also include the random number generator 204. In other embodiments, the random number generator 204 may be on another software or hardware system. The DNS resolver 200 may include functionality for transmitting and receiving data in any format or protocol, such as Internet Protocol. As such, in some embodiments, the DNS resolver 200 may include hardware or communicate with hardware capable of performing this functionality. In other embodiments, the DNS resolver 200 may operate within a virtual machine and may include or communicate with virtual hardware.

The DNS query identifier 201 comprises one or more programs, tasks, services, processes or executable instructions to provide logic, rules, functions, or operations for receiving and handling a DNS resolution request 208. The DNS query identifier 201 checks the resolver cache 202 to determine if a previously-received DNS response message corresponding to the DNS resolution request 208 has been stored in the resolver cache 202. If so, the DNS response generator 207 transmits a DNS resolution response 211 to the requester using the previously-received DNS response message in the resolver cache 202. If the answer is unknown, the DNS query identifier 201 checks that the DNS resolution request 208 is a fully qualified domain name query or unqualified multi-label domain name query. If the DNS query identifier 201 determines that the DNS resolution request 208 is not a fully qualified domain name query or unqualified multi-label query, the DNS query identifier 201 consults the cache 202 for a suffix search list. If a suffix search list does not reside in the cache 202, the DNS query identifier 201 appends a global DNS suffix to the DNS resolution request 208. If a suffix search list does reside in the cache 202, the DNS query identifier 201 appends a primary DNS suffix to the DNS resolution request 208. The DNS query identifier 201 consults the cache 202 to determine the IP address or addresses of a domain name server or servers from which to request an answer. In some embodiments, the DNS query identifier 201 consults the cache 202 to determine the port or ports of the domain name server or servers.

In some embodiments, the domain name requested is an ASCII name. In other embodiments, the domain name requested is part of the international domain name system and is encoded in Row-based ASCII Compatible Encoding (RACE) or punycode. The international domain name may be encoded by the DNS resolver 200 or may be already encoded when received by the DNS query identifier 201. In some embodiments, the DNS query identifier 201 consults the cache 202 to determine if each domain name server to be contacted is compliant with IETF RFC 4343 (Domain Name System Case Insensitivity Clarification). In some embodiments if a domain name server is RFC 4343 compliant, the DNS query identifier 201 may retain mixed capitalization of the domain name as received in the DNS resolution request 208. In other embodiments where a domain name server is RFC 4343 compliant, the DNS query identifier 201 may encode random capitalization in the domain name.

The cache 202 may comprise any type and form of data structure, implemented in any combination of hardware and software. In some embodiments, the cache 202 may comprise a database, a flat file, dictionary, registry, index, lookup table, or any other repository capable of storing DNS resource records in any format. The cache 202 may include any associated logic and control functions for recording and obtaining DNS resource records. Once DNS resource records are stored in the cache 202, the DNS resolver 200 can use the cached copy rather than re-transmitting a DNS query message for the resource, thereby reducing access time and use of network bandwidth. In some embodiments, the cache 202 may include an associated memory element, including RAM, Flash memory, or a portion of a disk drive. In other embodiments, the cache 202 may comprise a data object in main memory unit 122 or cache memory 140, discussed above in connection with FIGS. 1C and 1D, or any combination thereof. In still other embodiments, the cache 202 may comprise any type of integrated circuit, such as a Field Programmable Gate Array (FPGA) or a Programmable Logic Device (PLD). In some embodiments, the cache 202 may have a fixed maximum size. In other embodiments, there may be no such limitation. Furthermore, the cache 202 may include logic or functionality for invalidating or removing cached DNS resource records based on the expiration of a time period or upon receipt of an invalidation command from the DNS resolver 200. The logic or functionality may allow invalidation or removal of single records, groups of records, or all records residing in the cache 202.

The random number generator 204 may comprise any type and form of software or hardware, or any combinations thereof, for generating random or pseudo-random numbers. In some embodiments, the random number generator 204 is within the DNS resolver 200. In other embodiments, the random number generator 204 is in the same client, server, or intermediary as the DNS resolver 200. In still other embodiments, the random number generator 204 is separate from the client, server, or intermediary that includes the DNS resolver 200. In these embodiments, the random number generator 204 may communicates with the DNS resolver over any type and form of network or communications device or protocol. The random number generator 204 generates and transmits random or pseudo-random numbers to the transaction identifier generator 203 in the DNS resolver 200. The random or pseudo-random numbers can be of any length. In some embodiments, the number length is at least as long as the length of the requested domain name. For example, under IETF RFC 1034, the maximum length of a fully qualified domain name is 255 octets, or 2040 bits. In other embodiments, the random or pseudo-random number may be shorter or longer. In some embodiments, the random number generator 204 may generate a new random or pseudo-random number for each new DNS resolution request received by the DNS resolver 200. In other embodiments, the same random or pseudo-random number may be used for multiple transaction identifiers, reducing the need for new random or pseudo-random numbers for each request. In some embodiments, the random number generator 204 may generate a new random or pseudo-random number at a predetermined frequency. Higher frequencies may result in higher computation costs, while lower frequencies may result in less resistance to attack. In other embodiments, the random number generator 204 may generate a new random or pseudo-random number in response to an event. For example, the random number generator 204 may generate a new random number in response to every fifth or tenth DNS resolution request 208 received by the DNS resolver 200. For another example, the random number generator 204 may generate a new random number in response to every invalidation of a DNS response record in the cache 202. In these embodiments, the event that causes the random number generator 204 to generate a new random or pseudo-random number may be any event capable of triggering such functionality within the random number generator 204, such as closing or opening a switch, changing a value in a memory register, executing a function call, or accessing a memory location.

The transaction identifier generator 203 comprises a process, logic, function, service, task, subroutine, or executable instructions for creating or providing a transaction identifier, such as for a DNS query. As defined by IETF RFC 1035, the DNS transaction identifier is a 16-bit field in the header of DNS query message 209. However, in other protocols, the transaction identifier may be of different lengths or formats. In some embodiments, the queried domain name server responds to a DNS query message 209 with a DNS response message 210 including an identical DNS transaction identifier, associating the response with the query. In some embodiments, however, there may be multiple DNS query messages 209 sent by the DNS resolver 200 in response to multiple DNS resolution requests 208 before any DNS response message 210 is received. The transaction identifier allows the DNS resolver 200 to identify which outstanding request is associated with which response. The sent and received transaction identifiers are compared by the response/request comparator 206, and if the received transaction identifier matches no outstanding DNS query message 209, the DNS response message 210 is discarded by the DNS resolver 200. If the received transaction identifier does match an outstanding DNS query message 209, the DNS response message 210 is passed to the DNS response generator 207. To generate a transaction identifier, the transaction identifier generator 203 may perform a cryptographic hashing function using inputs comprising the random or pseudo-random number received from the random number generator 204, the IP address of the domain name server to be queried, and the domain name or a portion of the domain name requested. In some embodiments, the inputs to the transaction identifier generator 203 hash function may include the port number of the domain name server to be queried. In further embodiments, the inputs to the hash function may include the domain name encoded with capitalization. In yet further embodiments, the inputs to the hash function may include the domain name encoded in punycode or RACE. The cryptographic hash function used to create the transaction identifier may be any hash function, with or without collision resistance, such as MD5, SHA-1, SHA-256, or any other known or currently unknown hash function or combination of hash functions. In some embodiments, the output of the cryptographic hash function may be compressed to 16 bits. In other embodiments, the output may be truncated or shortened through any other means to 16 bits. In still other embodiments, the output of the cryptographic hash function may be shortened, truncated, or extended in any means to achieve the length of the transaction identifier required by the protocol format of the DNS query message 209. In further embodiments, the cryptographic hashing function may be collision resistant or collision free.

The DNS query generator 205 comprises a process, logic, function, service, task, subroutine, or executable instructions for creating any type and form of DNS query message 209. The DNS query message 209 may be created in compliance with the standard DNS query message format defined in IETF RFC 1035, or may be created in any other desired format. The DNS query message 209 may include a transaction identifier received from the transaction identifier generator 203. The DNS query message 209 may include a question entry of the domain name queried received from the DNS query identifier 201. The question entry may include a domain name, class, and type, as described in RFC 1035, or may contain more or fewer information as dictated by the query message format. The DNS query message 209 may be transmitted by the DNS resolver 200 to the address or addresses of the domain name server or servers selected by the DNS query identifier 201 from the cache 202. In some embodiments, the DNS query message 209 may be stored in a memory element associated with the response/request comparator 206. In other embodiments, the DNS query message 209 may be stored in a memory element associated with the DNS query generator 205, the cache 202, or any other memory element associated with or accessible by the DNS resolver 200. The stored DNS query message may be marked, flagged or recorded in such a way as to identify the query as an outstanding query. In such embodiments, the DNS resolver 200 may include functionality for invalidating or removing markings or flags or deleting the stored DNS query once it is no longer outstanding. In some embodiments, the DNS query message 209 may be transmitted by the DNS resolver 200 multiple times, such as in response to expiration of a time-to-live period.

The response/request comparator 206 comprises a process, logic, function, service, task, subroutine, or executable instructions for comparing a DNS response message 210 with a DNS query message 209. For example, the response/request comparator 206 may compare a DNS response message 210 received by the DNS resolver 200 with a DNS query message 209 sent by the DNS resolver 200. In some embodiments, the response/request comparator 206 may compare a received DNS response message 210 with a DNS query message marked as an outstanding query as discussed above. The response/request comparator 206 may check if the DNS response message 210 has apparently come from the same IP address and port of the domain name server to whom the DNS query message 209 was sent. Furthermore, in some embodiments, the response/request comparator 206 may check if the DNS response message 210 has the same transaction identifier as the DNS query message 209 that was sent. In these embodiments, if the response/request comparator 206 determines that the DNS response message 210 does not match the DNS query message 209, the comparator 206 disregards the DNS response message 210. In further embodiments, where the domain name server queried is RFC 4343 compliant, the response/request comparator 206 may compare capitalization of the domain name in the transmitted DNS query message 209 and received DNS response message 210. In these embodiments, the response/request comparator 206 may instruct the DNS resolver 200 to disregard the DNS response message 210, responsive to a determination that the capitalization does not match. If the response/request comparator 206 identifies the DNS response message 210 as matching an outstanding DNS query message 209, it may, in some embodiments, pass the DNS response message 210 as a validated response to the DNS response generator 207. The response/request comparator 206 may also invalidate or remove markings or flags or delete memory entries identifying the DNS query message 209 as outstanding, or instruct another process to do so.

The DNS response generator 207 comprises a process, logic, function, service, task, subroutine, or executable instructions for generating and/or sending a DNS resolution response 211. The DNS response generator 207 may receive a validated DNS response message 210 from the response/request comparator 206. In some embodiments, the DNS response generator 207 may inspect the DNS response message 210 to determine if it is fully responsive to the DNS resolution request 208. A fully responsive message contains the final address sought. For example, a request for the address of www.example.com may return a response that the domain name www.example.com is located at 208.77.188.166. A non-fully responsive message to the query for the address of www.example.com may return a response that the domain name server for example.com is located at 208.77.188.1, but be silent on the address of www.example.com. In some embodiments, if the DNS response message 210 is not fully responsive to the DNS resolution request 208, the DNS response generator 207 may record any partial response or additional name server information in the cache 202. Furthermore, the DNS query identifier 201 may create a new iteration of the query using the partial response or additional name server information. In some embodiments, if the DNS response message 210 is fully responsive to the DNS resolution request 208, the DNS response generator 207 may record the response in the cache 202. The DNS response generator 207 may send a DNS resolution response 211 to the originally requesting software or hardware on the same or different client, server, or intermediary.

The DNS resolution request 208 is a data packet or packets comprising a DNS name to be resolved. The DNS resolution request 208 may include a fully qualified domain name or a portion of a domain name; a DNS query type; and a DNS query class. In some embodiments, the DNS resolution request 208 comes from a software or hardware system on the same client, server, or intermediary. In other embodiments, the DNS resolution request 208 comes from a software or hardware system on another client, server, or intermediary.

The DNS query message 209 is a data packet or packets comprising a request to a name server to identify a domain name. The DNS query message 209 may include a transaction identifier and a question entry, as discussed above in connection with the DNS query generator 205. The DNS query message 209 may be transmitted over TCP, UDP, or any other protocol known or currently unknown for allowing communication over a network.

The DNS response message 210 is a data packet or packets comprising a response to a DNS query message 210. The DNS query message 210 may include a transaction identifier. The transaction identifier may be identical, similar, or different from the transaction identifier of an outstanding DNS query message 209. The DNS query message 210 may include a response entry. The response entry may include a domain name, class, or type as described in RFC 1035, or may contain more or fewer information as dictated by the query message format. The response entry may also include additional information, such as the address of an authoritative name server for the domain name requested. The DNS query message 210 may be transmitted over TCP, UDP, or any other type and form of protocol for allowing communication over a network.

The DNS resolution response 211 is a data packet or packets comprising a response to a DNS resolution request 208. The DNS resolution response 211 may include a domain name and IP address corresponding to the domain name requested in the DNS resolution request 208. In some embodiments, the DNS resolution response 211 may include a message that the domain name could not be located.

C. DNS Query Generation

FIG. 3 describes an embodiment of steps for a method of generating a transaction identifier for a DNS query message. In brief overview, at step 300, a request is received to resolve a domain name. At step 301, the request is parsed and the IP address and port of a domain name server with the domain in its zone of authority or a delegated zone is determined. At step 302, the cache is consulted to determine if the domain name server to be queried rewrites or normalizes mixed-capitalization domain names; if the domain name server does not do so, capitalization shifts may be made in the characters of the requested domain name. At step 303, a random or pseudo-random number is generated for a salt input to a cryptographic hashing function. At step 304, a transaction identifier is created as an output of the cryptographic hashing function. At step 305, the DNS query message is created. At step 306, the DNS query message is transmitted to the domain name server to be queried. In some embodiments, this process may be repeated multiple times for the same request to query multiple domain name servers. In further embodiments, this process may be repeated iteratively or recursively where DNS answers fail to fully answer the DNS request, but indicate a more authoritative name server to query.

In further details, at step 300, the DNS resolver may receive a request to resolve a domain name. In some embodiments, this request may come from a web browser or similar application. In other embodiments, this request may come from a kernel service, function, daemon, or other executable code residing in hardware, software, or any combination thereof. In some embodiments, the source of the request may be on the same client, server, or intermediary as the DNS resolver. In other embodiments, the source of the request may be from a different client, server, or intermediary on the same or a different network. The DNS request may be for a full or partial domain name. The DNS request may include a domain class and domain type. In some embodiments, the DNS request may include wildcard characters in the name or class or type, signifying that all records relevant to a domain name or partial domain name or class or type are being requested. If a relevant fully-responsive DNS record resides in the DNS resolver's cache, a response containing the information in the DNS record may be returned to the requestor. In such a case, no further steps of generating a DNS query may need to be taken.

At step 301, the DNS resolver may select a domain name server to query from the index of name servers in the cache. In some embodiments, the DNS resolver may select a preferred name server. In other embodiments, the DNS resolver may select the name server with the narrowest zone of authority containing the requested domain listed in the index of name servers in the cache. In further embodiments, the DNS resolver may select the name server for the root zone. Once a name server to be queried has been selected, the DNS resolver retrieves the name server's IP address and port number from the index of name servers in the cache.

At step 302, the DNS resolver may consult the cache to determine if the domain name server to be queried rewrites or normalizes responses. In some embodiments, the DNS resolver may determine that the name server rewrites responses by the presence and content of additional data fields in the cached resource record. In other embodiments, the DNS resolver may determine that the name server rewrites responses by comparing prior mixed capitalization domain name queries to the name server with responses from the same name server for preservation of capitalization. If the domain name server to be queried does not rewrite or normalize responses, in some embodiments the DNS resolver may shift any or all of the characters of the domain name between upper and lower case.

At step 303, the random number generator generates a random or pseudo-random number. In one embodiment, the random number generator passes the random or pseudo-random number to the transaction identifier generator. In other embodiments, the transaction identifier generator obtains or retrieves the random or pseudo-random number from a memory element associated with the random number generator. In some embodiments, a new random or pseudo-random number is passed to the cryptographic hashing function for each new DNS query. In other embodiments, a random or pseudo-random number may be reused for multiple DNS queries. In further embodiments, the random or pseudo-random number may be updated at a predetermined frequency. In other embodiments, the random or pseudo-random number may be updated in response to an event, as discussed above in connection the random number generator 204 and FIG. 2.

At step 304, the transaction identifier generator performs a cryptographic hashing function on inputs comprising the random or pseudo-random number, the IP address of the domain name server to be queried, and the domain name or a portion of the domain name requested. The cryptographic hashing function may be any hash function or combination of hash functions, including MD5, SHA-1, SHA-256, or any other hash function or functions currently known or unknown. For example, in one embodiment, the transaction identifier generator may append the input bits of the random number, the IP address of the domain name server and the domain name to create a string of bits. In this example embodiment, the transaction identifier generator may use a combination of addition, exclusive-or (XOR), and constant rotations of adjacent bits or groups of bits to convert the string of bits into a cryptographic hash of length specified by the size of the transaction identifier field of the protocol. For instance, the IETF RFC 1035 standard specifies a 16-bit transaction identifier for DNS queries. However, the transaction identifier generator may be configured to output a hash of any length required by the network protocol in use. Although the illustrative example describes appending the input bits to create a string, the transaction identifier generator may use appending, multiplying, adding, subtracting, XORing, or any other method known to those skilled in the art.

At step 305, the DNS query generator creates a DNS query using the requested domain name, domain class and/or domain type received at step 300, and the transaction identifier generated at step 304. As mentioned above at step 300, the DNS request may be for a full or partial domain name, and wildcard characters may be present in the name or class or type, signifying that all records relevant to a domain name or partial domain name or classes or types are being requested. In one embodiment, the DNS query generator may create an RFC 1035 standard DNS query, comprising a header followed by a question. In this embodiment, the header may include the transaction identifier generated at step 304, a query flag, an opcode specifying the type of query, and a recursion flag. The question may include the domain name, the domain type and domain class. In some embodiments, the DNS query generator may also create a message compliant with the relevant protocol, such as TCP or UDP, with the DNS query as a payload. In other embodiments, the DNS query generator may pass the query as a payload to another process or service acting at the application or transport layer.

At step 306, the DNS resolver transmits the DNS query to the domain name server selected at step 301. The domain name server may be on the same network as the DNS resolver or on a different network. In some embodiments, the DNS resolver transmits the DNS query directly. In other embodiments, the DNS resolver passes the DNS query to another process or service responsible for handling network communications, such as a network driver.

In many embodiments, the DNS query generated at step 305 complies with IETF standard DNS protocol. In these embodiments, the domain name server may recognize the generated DNS query as a standard DNS query. In such embodiments, the functionality of DNS name resolution may be performed without alteration to hardware or software on the domain name server, client, or intermediary. In some embodiments, the DNS protocol used or supported by the client and/or server do not need to change to support any of the functionality or operations described herein. Such compliance with DNS protocols, such as with IETF standards, may prevent compatibility issues between the client, server, and intermediary. In other embodiments, the DNS query may be generated to comply with other standards, including Extended DNS (described in RFC 2671) and DNS Security Extensions (described in RFC 2535). In yet other embodiments, the DNS query may be encrypted. In one such embodiment, the encryption protocol may be DNSCurve. In other such embodiments, any other encryption protocol or combinations of protocols may be used. In still other embodiments, the DNS query may be generated in a proprietary format, and may require hardware or software changes to the client, server, or intermediary.

While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the following claims.

Claims

1. A method for generating a domain name Service (dns) query to improve resistance against a dns attack, the method comprising:

a) receiving, by a dns resolver configured on a device, a request to resolve a domain name;

b) identifying, by the dns resolver, the domain name, an internet protocol address of a dns server, and a port of the dns server;

c) generating a transaction identifier for a dns query by applying a one-way hash function to an input of a predetermined random number, the internet protocol address of the dns server, the port of the dns server, and the domain name, the input of the domain name comprising a portion of the domain name to be resolved; and

d) transmitting, by the dns resolver, the dns query for the domain name to the dns server, the dns query identified by the generated transaction identifier.

2. The method of claim 1, wherein step (c) further comprises changing the predetermined random number at a predetermined frequency.

3. The method of claim 1, wherein step (c) further comprises changing the predetermined random number in response to an event.

4. The method of claim 1, wherein step (c) further comprises generating by the one-way hash function the same transaction identifier for dns queries to resolve the same domain name transmitted to the same dns server.

5. The method of claim 1, wherein step (c) further comprises encoding one or more fields of the dns request and using the encoded one or more fields as input to the one-way hash function to generate the transaction identifier.

6. The method of claim 1, wherein step (c) further comprises encoding the domain name by capitalizing one or more characters of the domain name and generating the transaction identifier by using the encoded domain name as the input of the domain name to the one-way hash function.

7. The method of claim 1, wherein step (c) further comprises encoding the domain name by using one of a punycode and a RACE encoding scheme.

8. The method of claim 1, further comprising determining, by the dns resolver, that the dns server is one of rewriting or normalizing responses and in response to the determination not encoding a portion of the dns query.

9. The method of claim 1, further comprising determining, by the dns resolver, that the destination is not rewriting responses and in response to the determination encoding a portion of the dns query and including the encoded portion in the transaction identifier.

10. The method of claim 1, wherein step (c) further comprises communicating by the dns resolver the input of the internet protocol address of the destination and the domain name to a transaction identifier generator.

11. A system for generating a domain name Service (dns) query to improve resistance against a dns attack, the system comprising:

a computing device, comprising a processor executing a dns resolver and a transaction identifier generator,

wherein the dns resolver is configured to receive a request to resolve a domain name and identify the domain name, an internet protocol address of a destination of the request, and a port of the destination of the request;

wherein the transaction identifier generator is configured to generate a transaction identifier by applying a one-way hash function to an input of a predetermined random number, the internet protocol address of the destination, the port of the destination, and the domain name, the input of the domain name comprising a portion of the domain name to be solved; and

wherein the dns resolver is further configured to form the dns query using the generated transaction identifier and transmit the dns query for the domain name to the destination.

12. The system of claim 11, wherein the transaction identifier generator is further configured to change the predetermined random number at a predetermined frequency.

13. The system of claim 11, wherein the transaction identifier generator is further configured to change the predetermined random number in response to an event.

14. The system of claim 11, wherein the transaction identifier generator is further configured to generate the same transaction identifier for inputs identifying the same domain name and the same destination.

15. The system of claim 11, wherein the dns resolver is further configured to encode one or more fields of the dns request and communicate the encoded one or more fields as input to the transaction identifier generator to generate the transaction identifier.

16. The system of claim 11, wherein the dns resolver is further configured to encode the domain name by capitalizing one or more characters of the domain name and communicate the encoded domain name as the input of the domain name to the transaction identifier generator.

17. The system of claim 11, wherein the dns resolver is further configured to encode the domain name by using one of a punycode and a RACE encoding scheme.

18. The system of claim 11, wherein the dns resolver is further configured to determine that the destination is one of rewriting or normalizing responses and in response to the determination does not encode a portion of the dns query.

19. The system of claim 11, wherein the dns resolver is further configured to determine that the destination is not rewriting responses and in response to the determination encodes a portion of the dns query and communicate the encoded portion as input to the transaction identifier generator to generate the transaction identifier.

20. The system of claim 11, wherein the computing device executing the dns resolver is one of a client, a server and an intermediary.