Privacy-protected Domain Name Service (DNS)

Abstract

The described systems and methods allow for performing privacy-preserving DNS interactions. In some embodiments, a client machine engages in a Personal Information Lookup (PIR) interaction with a name server. In response to receiving an encrypted query from the client, the query being formulated according to a domain name, the name server is able to extract records (e.g., IP addresses) from the domain name database without decrypting the respective query. Some embodiments accomplish such information lookup through the use of homomorphic encryption.

Description

[Technical Field]

[0001]

[0001] The present invention relates to systems and methods for protecting the privacy of online communications, and in particular to preventing remote entities from obtaining information about Internet users' browsing habits. [Background technology]

[0002] Browsing the Internet has become an essential component of modern life and work. Following the explosion in Internet access, several commercial and malicious entities are increasingly interested in accessing and analyzing the browsing history and / or patterns of individual Internet users. Such information may then be used to target advertisements and deliver various services to each user. However, the same type of information may also be used to profile and / or target users according to more sensitive aspects of their personality, such as sexual orientation, political and religious views, race, drug use, intelligence, etc. An increasing number of Internet users are concerned about their privacy and how allowing companies and / or nation states to monitor their online behavior may affect their rights and expose them to various types of threats and abuse.

[0003] A common manner in which a user's browsing history is collected is via Domain Name Service (DNS) requests. DNS typically refers to the service that translates domain names into network (e.g., IP) addresses, which enable electronic devices to exchange data over communications networks. Because DNS was originally designed for speed and convenience, as opposed to privacy, DNS providers and Internet service providers have traditionally had virtually unimpeded access to DNS requests issued by clients. In recent years, several efforts have been directed toward providing alternatives to the legacy DNS. Some examples include, among others, a series of protocols known as "DNS over TLS (Transport Layer Security)" and "DNS over HTTPS (Hypertext Transfer Protocol Secure)." Such versions of DNS encrypt individual requests from clients and / or server responses, thereby essentially preventing entities other than the end client and name server from accessing the respective data. For example, such protocols can prevent Internet service providers and / or malicious third parties from snooping on users' DNS requests. However, since data is only encrypted in transit between the client and the name server, such protocols do not prevent DNS providers themselves from collecting browsing data about their users.

[0004]

[0004] Therefore, there is considerable interest in developing more capable and robust privacy-preserving domain name services. Summary of the Invention

[0005] According to one aspect, a method for performing a Domain Name Service (DNS) lookup includes, in response to receiving an indication of the domain name, employing at least one hardware processor of a computer system to determine whether a privacy condition is met according to the domain name. In response to determining whether the privacy condition is met, if "yes," formulating a private query including an encryption of a hash index indicating a location of a record in a domain name database, where the hash index is encrypted according to a homomorphic encryption procedure, and the hash index is determined according to the domain name. In response to formulating the private query, the method further includes transmitting the private query to a name server configured to perform an encrypted lookup into the domain name database according to the private query to generate an encryption of the record, and in response to receiving a private response from the name server including the encryption of the record, decrypting the contents of the private response according to a homomorphic decoding procedure.

[0006] According to another aspect, a computer system includes at least one hardware processor configured to, in response to receiving an indication of a domain name, determine whether a privacy condition is satisfied according to the domain name. The at least one hardware processor is further configured, in response to determining whether the privacy condition is satisfied, if "yes," to formulate a private query including an encryption of a hash index indicating a location of a record in a domain name database, the hash index being encrypted according to a homomorphic encryption procedure, the hash index being determined according to the domain name. The at least one hardware processor is further configured, in response to formulating the private query, to transmit the private query to a name server configured to perform an encrypted lookup in the domain name database according to the private query to generate an encryption of the record, and in response to receiving a private response from the name server including the encryption of the record, to decrypt content of the private response according to a homomorphic decoding procedure.

[0007] According to another aspect, a non-transitory computer-readable medium stores instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to, in response to receiving an indication of a domain name, determine whether a privacy condition is met according to the domain name. The instructions further cause the computer system, in response to determining whether the privacy condition is met, if "yes," to formulate a private query including an encryption of a hash index indicating a location of a record in a domain name database, the hash index being encrypted according to a homomorphic encryption procedure, the hash index being determined according to the domain name. The instructions further cause the computer system, in response to formulating the private query, to transmit the private query to a name server configured to perform an encrypted lookup in the domain name database according to the private query to generate an encryption of the record, and, in response to receiving a private response from the name server including the encryption of the record, to decrypt the contents of the private response according to a homomorphic decoding procedure.

[0008] According to another aspect, a server computer system is configured to engage in Domain Name Service (DNS) transactions with a plurality of clients. The server computer system includes at least one hardware processor configured to receive a private query from one of the plurality of clients, the private query including an encryption of a hash index indicating a location of a record in a domain name database, the hash index being encrypted according to a homomorphic encryption procedure, the hash index being determined according to a domain name. The at least one hardware processor is further configured, in response to receiving the private query, to perform an encrypted lookup in the domain name database according to the private query to generate an encryption of the record, and to transmit a private response including the encryption of the record to the client. [Brief explanation of the drawings]

[0009] The foregoing aspects and advantages of the present invention will become better understood upon reading the following detailed description and by reference to the drawings, in which: [Figure 1]

[0010] 1 illustrates an exemplary privacy-preserving electronic communications system according to some embodiments of the present invention. [Figure 2]

[0011] FIG. 1 illustrates an exemplary Domain Name Service (DNS) server system including multiple communicatively coupled name servers, according to some embodiments of the present invention. [Figure 3]

[0012] FIG. 1 illustrates a typical DNS transaction known in the prior art. [Figure 4]

[0013] FIG. 1 illustrates a DNS query and response as known in the prior art. [Figure 5]

[0014] FIG. 1 illustrates an exemplary fully qualified domain name (FQDN) and several exemplary partially qualified domain names (PQDN) of an Internet domain, according to some embodiments of the present invention. [Figure 6]

[0015] FIG. 2 illustrates an exemplary domain name space according to some embodiments of the present invention. [Figure 7]

[0016] FIG. 1 illustrates a DNS transaction according to some embodiments of the present invention, the transaction including a private query and a private response. [Figure 8]

[0017] FIG. 2 illustrates exemplary contents of a domain name database according to some embodiments of the present invention. [Figure 9]

[0018] 1A-1C illustrate exemplary personal information retrieval (PIR) queries and exemplary PIR responses according to some embodiments of the present invention. [Figure 10]

[0019] FIG. 2 illustrates exemplary components executing on a client system in accordance with some embodiments of the present invention. [Figure 11]

[0020] FIG. 2 illustrates an exemplary sequence of steps performed by a client system DNS resolver according to some embodiments of the present invention. [Figure 12]

[0021] FIG. 2 illustrates exemplary components executing on a DNS server system according to some embodiments of the present invention. [Figure 13]

[0022] FIG. 2 illustrates an exemplary sequence of steps performed by a DNS server database maintenance module according to some embodiments of the present invention. [Figure 14]

[0023] FIG. 2 illustrates an exemplary sequence of steps performed by a DNS server PIR module according to some embodiments of the present invention. [Figure 15]

[0024] FIG. 2 illustrates an exemplary sequence of steps performed by a client DNS resolver to perform a DNS lookup, according to some embodiments of the present invention. [Figure 16]

[0025] FIG. 2 illustrates an exemplary set of domains grouped into clusters, according to some embodiments of the present invention. [Figure 17]

[0026] FIG. 1 illustrates exemplary hardware components of a computing appliance configured to execute some of the methods and algorithms described herein. DETAILED DESCRIPTION OF THE INVENTION

[0010]

[0027] In the following description, it is understood that all enumerated connections between structures can be direct operative connections or indirect operative connections through intermediate structures. A set of elements includes one or more elements. Any enumeration of elements is understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any described method steps do not necessarily have to be performed in the particular order shown. A first element (e.g., data) derived from a second element includes a first element equal to the second element, and a first element generated by processing the second element and optionally other data. Making a decision or determination according to a parameter includes making a decision or determination according to the parameter and optionally other data. Unless otherwise specified, an indicator of a quantity / data can be the quantity / data itself or an indicator different from the quantity / data itself. A computer program is a series of processor instructions that perform a task. The computer programs described in some embodiments of the present invention can be standalone software entities or subentities (e.g., subroutines, libraries) of other computer programs. A network domain consists of a group of interconnected computing devices that form a distinct part of a computer network. An Internet domain is a network domain connected to the public Internet. A domain name is a label / alias that identifies an address of a network / Internet domain. The term "database" is used herein to denote any organized collection of data. Computer-readable media encompass non-transitory media such as magnetic, optical, and semiconductor storage media (e.g., hard drives, optical disks, flash memory, DRAM), as well as communication links such as conductive cables and fiber optic links.According to some embodiments, the present invention provides, inter alia, a computer system including hardware (e.g., one or more processors) programmed to perform the methods described herein, as well as a computer-readable medium encoding instructions for performing the methods described herein.

[0011]

[0028] The following description illustrates embodiments of the present invention by way of example, and not necessarily by way of limitation.

[0029] 1 illustrates a privacy-preserving electronic communications system 10 according to some embodiments of the present invention. A set of exemplary client devices 12a-f communicate with each other and / or with a remote content server computer 16 via communications links to exchange data such as web content, electronic messages, various documents, etc. Client devices 12a-f may include personal computer systems, corporate mainframe computers, mobile computing platforms (e.g., laptop computers, tablets, mobile phones), entertainment devices (e.g., TVs, game consoles), wearable devices (e.g., smart watches, fitness bands), home appliances (e.g., refrigerators, washing machines), and any other electronic device that includes a processor, memory, and a communications interface that enables the respective device to communicate with other devices / computer systems.

[0012]

[0030] In the exemplary configuration of FIG. 1 , client devices 12 a-e are interconnected by a local network 13, such as a local area network (LAN). In one exemplary use case scenario, devices 12 a-e correspond to electronic devices in a home, and local network 13 corresponds to a home network. In another use case scenario, client devices 12 a-e can correspond to computers located in a corporate office or department and interconnected by a corporate LAN. Devices 12 a-e can be further connected to an extended network 15, such as a wide area network (WAN) and / or the Internet. In some embodiments, router 14 controls and / or manages data traffic within local network 13, for example, by assigning network addresses to clients 12 a-e connected to local network 13 and routing individual communications according to such addresses. In some embodiments as shown in FIG. 1 , router 14 is configured as a gateway to local network 13, in the sense that at least a portion of network traffic between client devices 12 a-e and extended network 15 passes through router 14. Other client devices, such as exemplary device 12f in FIG. 1, may not be connected to the local network 13 and may instead connect directly to the extended network 15, for example, via a mobile telephony network or a public WiFi hotspot.

[0013]

[0031] According to some embodiments of the present invention, a domain name service (DNS) server system 20 provides privacy-preserving domain name services to client devices 12a-f. Domain name services, as used herein, are intended to encompass translating domain names into network addresses and / or vice versa, and providing domain registration data (e.g., WHOIS data) and other domain information, including, among other things, indications of whether a particular domain belongs to a particular category / cluster of domains, whether the domain distributes adult content, whether the domain engages in malicious activity (e.g., botnets, internet fraud), etc. DNS server system 20 collectively represents a set of communicatively coupled computers, such as exemplary name servers 20a-d shown in FIG. 2. The functionality of each such name server is described in further detail below. Sending a request to DNS server system 20 encompasses sending the respective request to any of name servers 20a-d.

[0014]

[0032] A typical data exchange between client devices 12a-f and content server 16 involves several steps. The transmission typically requires knowledge of the network address (e.g., Internet Protocol (IP) address) of content server 16. In many cases, this address is unknown to the client device for various reasons. For example, there may be multiple mirror content server machines, and clients can be dynamically directed to the most convenient server according to the current load of each mirror server or according to the client device's current geographic location. However, client devices may know the domain name of server 16. The term "domain name" herein refers to any alias for the required network address. To establish a connection to content server 16, a software entity executing on each client device may therefore issue a request to access the respective domain name instead of the IP address itself. In response, another software entity (e.g., a component of the operating system executing on each client) may intercept the request, attempt to translate the alias / domain name into the actual network address, and then forward the request to the correct network location. Such translation may invoke a DNS provider, such as server system 20 in FIG.

[0015]

[0033] 3-4 illustrate typical messaging according to the DNS protocol known in the art. A client device 12 transmits a DNS query 22 to a DNS server system 20, the query 22 including an indication of an Internet domain 30 (e.g., a domain name as shown in FIG. 3) and an indication of the type of query Q. The query type indicates the type of DNS resource record returned by the DNS server 20. Exemplary queries include "A," which requests an IP address formatted in Internet Protocol Version 4 (IPv4), and "AAAA," which returns an IP address formatted in Internet Protocol Version 6 (IPv6). Other exemplary query / resource record types include "TXT," "PTR," "LOC," etc. In response, the DNS server system 20 can return a DNS response 24 to the requesting client, the response 24 including an encoding of the resource record network corresponding to each domain name / alias. In the example of FIG. 4, the record type is an IP address 40 in 32-bit IPv4 format. In some cases, for example in systems using DNS over HTTPS protocol, the DNS queries 22 and / or DNS responses 24 may be encrypted.

[0016]

[0034] FIG. 5 illustrates exemplary domain names for Internet domains. A domain name may consist of a fully qualified domain name (FQDN) 36 that completely and unambiguously specifies the respective domain through an ordered sequence of tokens / labels 32a-d separated by a delimiter symbol 34 (a dot in the illustrated example). Fragments of an FQDN 36 that include a subset / subsequence of FQDN tokens 32a-d are commonly known as partially qualified domain names (PQDNs). Items 38a-c illustrate various exemplary PQDNs of the FQDN 36. In contrast to the FQDN 36, each PQDN 38a-c specifies the respective domain with some level of ambiguity; i.e., there may be multiple FQDNs with the same distinctive PQDN.

[0017]

[0035] The representation of a domain name as a series of tokens (see FIG. 5) is consistent with a tree-like hierarchical representation of the domain name space as shown in FIG. 6, with each token 32a-d in the FQDN 36 corresponding to a branch in the tree and each instance of a delimiter (e.g., a dot) corresponding to a branch point. The domain name hierarchy has several notable levels, including at least a root level ("."), a top-level domain (TLD) level containing tokens such as com, net, fashion, and tv, and country tokens such as ro and fr, a domain level containing tokens such as wikipedia and facebook, and a subdomain level containing various domain-specific prefix tokens. Assembling an FQDN 36 from individual tokens is therefore equivalent to traversing the tree hierarchy from the terminal leaves to the root, as shown in FIG. 6. For clarity, the token characterizing the domain name at the TLD level (typically the last token in the FQDN 36) will be considered the TLD token herein. Similarly, a token that characterizes a domain name at the domain level (typically the penultimate token of an FQDN 36) will be considered herein as a domain token. Finally, all tokens that precede a domain token in an FQDN 36 will be considered herein as prefix tokens.

[0018]

[0036] Domain name services can be organized so that no single name server can resolve a fully qualified domain name by itself. Instead, the domain name space is divided into multiple authoritative zones, each resolved by a separate name server. Typically, each authoritative zone contains a selected subtree / branch of the domain name hierarchy, as shown by exemplary authoritative zones 37a-c in Figure 6. In the example shown, name servers 20b-cd resolve domain names within authoritative zones 37a-bc, respectively.

[0019]

[0037] In some embodiments, resolving an FQDN into a corresponding IP address proceeds in an iterative manner, with each successive iteration progressing to a successive level in the domain name hierarchy. Each successive iteration may be determined according to a distinct token in the FQDN 36. Each iteration may involve sending a DNS query to a distinct name server and, in response, receiving a DNS response that specifies the IP address of another name server. Servers that resolve the TLD level of a domain name, i.e., a TLD token such as ".org," are considered herein to be root name servers (see, e.g., root name server 20b). Servers that resolve domain names at the domain level, i.e., a domain token in the FQDN 36, are considered herein to be TLD name servers (see, e.g., TLD name server 20c, which resolves between domains in the ".org" top-level domain). Servers that resolve the subdomain level, i.e., prefix tokens of FQDN 36, are considered authoritative servers for the respective domains herein (see, for example, authoritative server 20d, which resolves between subdomains of "wikimedia.org"). In one example according to Figure 6, resolving the domain name "text-lb.codfw.wikimedia.org" involves sending a first DNS query to root name server 20b and receiving, in response, from name server 20b, the IP address of TLD name server 20c responsible for resolving the authoritative zone for the ".org" top-level domain. A next step in the iteration can include sending a second DNS query to TLD name server 20c and receiving, in response, from name server 20c, the IP address of authoritative name server 20d for the "wikimedia.org" domain.A further stage of the iteration may include sending a third DNS query to authoritative name server 20d and, in response, receiving from name server 20d the IP address of a content server identified by the FQDN “text-lb.codfw.wikimedia.org.”

[0020]

[0038] In some embodiments, queries transmitted at every step of the iterative DNS resolution include fully qualified domain names. In an alternative privacy-enhancing embodiment, the DNS queries sent at each iteration may include individual PQDNs (e.g., single tokens) and possibly additional characters such as the wildcard "*," among other things. For example, the PQDNs sent to selected name servers may include their respective FQDNs stripped down to one token more than the authoritative zone of each name server. In the example of FIG. 6, the DNS query sent to root name server 20b may inquire about the PQDN ".org," while the DNS query sent to TLD name server 20c may inquire about the PQDN "*.wikimedia.org."

[0021]

[0039] In some embodiments, such iterative domain resolution is performed by a dedicated resolver name server 20a (FIG. 2), which may further manage a DNS cache containing the results of recent and / or popular DNS lookups. In such a configuration, client devices 12a-f may transmit a single DNS query to resolver name server 20a, each query requesting resolution of a fully qualified domain name. Name server 20a may then perform cache lookups and / or perform any necessary iterative DNS queries on behalf of the client. Once each FQDN is fully resolved, name server 20a may return the IP address associated with each FQDN to the requesting client.

[0022]

[0040] 7 illustrates an exemplary privacy-preserving DNS transaction in accordance with some embodiments of the present invention. The transaction involves a first party (e.g., a client) issuing a request for an item to a second party (e.g., a server), which retrieves the requested item from a data repository / database, the retrieval procedure being performed without revealing the item to the second party. In other words, the server does not know which item is requested, but still retrieves the requested item from the repository. In one exemplary privacy-preserving transaction detailed below, the request issued by the client is encrypted, and the server retrieves the encrypted version of the requested item without decrypting the request. Thus, the client's privacy is preserved.

[0023]

[0041] In some embodiments, a privacy-preserving DNS transaction is performed in accordance with a Privacy Information Lookup Procedure (PIR). The exemplary interaction shown in Figure 7 involves client device 12 (which collectively represents any of client devices 12a-f in Figure 1) transmitting a private query (shown as PIR query 52) to DNS server system 20 and receiving a private response (shown as PIR response 54) from server system 20 in response.

[0024]

[0042] In some embodiments, the PIR procedure uses homomorphic encryption to ensure the privacy of the exchange. Homomorphic encryption is a particular type of encryption that allows certain computations (e.g., addition and / or multiplication) to be performed on encrypted data, and decrypting the results of such computations produces the same output as applying the respective computations to an unencrypted version of the same data. In other words, if Enc(m)=c denotes a homomorphic encryption operation, where m represents a plaintext message and c denotes its corresponding ciphertext, then Dec(c)=m denotes a homomorphic decryption operation that recovers each message from its ciphertext, and Eval(F,{c i ,...,C k})=C is the ciphertext c i Denote a homomorphic evaluation procedure that generates an encrypted ciphertext C by applying a function F to the set of Dec(C)=F(m1,...,m k ), [1] and m i =Dec(c i ), where i=l,...,k. In formal mathematical language, the encryption and decryption procedures of a homomorphic encryption scheme are said to be homomorphic mappings between the plaintext space and the ciphertext space.

[0025]

[0043] Several homomorphic encryption schemes / cryptosystems are known in the art. Schemes that maintain the homomorphic property with respect to any combination of addition and multiplication are commonly known as fully homomorphic. Examples include the Gentry-Sahai-Waters (GSW) scheme, among others. Other schemes / algorithms are homomorphic only with respect to certain types of operations, e.g., only with respect to addition in the case of the Paillier scheme and only with respect to multiplication in the case of the Rivest-Shamir-Adelman (RSA) scheme. Such schemes are known in the art as partially homomorphic. In contrast, ciphers that do not have the homomorphic property described above are considered non-homomorphic herein. Examples of non-homomorphic ciphers include the Advanced Encryption Standard (AES) and other ciphers used in the Transport Layer Security (TLS) family of communication protocols.

[0026]

[0044] In an exemplary PIR procedure using homomorphic encryption, a function F can replace the set of operations equivalent to performing a database lookup. In a simple example, a server holds three elements in a database, i.e., D={a,b,c}. A client wishes to look up a second element (i.e., "b") without leaking that information to the server. The client can indicate the desired element using a lookup index, e.g., a bitmap I containing zeros everywhere except the desired element's position in database D. In the current example, I={0,1,0}. The client can then homomorphically encrypt each bitmap and transmit it to the server. The server can then apply function F to the encrypted bitmap.

[0027] C=F[Enc(I)]=D*[Enc(I)] T , [2] * denotes matrix multiplication and T denotes transposition. The server then sends the resulting encrypted vector C back to the client. The homomorphic property ensures that decrypting C produces the same result as applying the function F to the unencrypted bitmap I.

[0028] Dec(C)=F(I)=D*I T ={a,b,c}*{0,1,0} T =b[3] Therefore, the client retrieves b, while the server sees only the encrypted bitmap and performs all operations without decrypting the information received from the client.

[0029]

[0045] In some embodiments, the DNS server system 20 is communicatively coupled to a domain name database 50 that stores a set of records indexed according to domain name. An index attached to each record can indicate the location of each record within a respective data repository or otherwise enable selective identification / retrieval of each record within / from the database 50. In a simple example where the data is organized in a tabular format, each row can represent an individual record, and the rows are indexed by individual row numbers and / or labels. Each record can include a set of entries that indicate various characteristics of the respective domain. In one embodiment that implements a DNS lookup service, exemplary entries include IP addresses of computers that form part of the respective domain and / or IP addresses of name servers (see, e.g., name servers 20a-d in FIGS. 2 and 6). Other exemplary entries include domain registration data for each domain (e.g., owner identity data, billing data, owner contact data, e.g., address, phone number, email address, domain name expiration date, current domain registrar identifier, etc.). Still other exemplary entries may include an indication of whether the respective domain belongs to a particular category, or an indication of the category to which the respective domain belongs. For example, entries may indicate whether the respective domain is blacklisted / whitelisted, whether the respective domain is known to distribute fraudulent documents and / or unsolicited communications (spam), whether the respective domain is part of a botnet, or whether it is engaged in denial-of-service (DoS) attacks. Another exemplary entry may indicate whether the respective domain is located within a selected geographic area or subnetwork (e.g., geofencing).Yet another exemplary entry may indicate whether each domain is owned by or associated with a selected commercial entity. Other examples will be discussed below.

[0030]

[0046] In some embodiments, an index identifying each record is determined according to the domain name, thus enabling association between various entries of each record and the domain name. Each domain name can be an FQDN or a PQDN. One exemplary index includes a hash calculated according to each domain name. A hash herein refers to the result of applying a hash function. A hash function is a special type of mathematical function that maps data of any size to a numerical value with a predetermined universal upper bound. Because strings can be represented as numbers, a hash function can also map any string to a numerical value, for example, a 256-bit integer. Exemplary hash functions include H(n)=n mod m (n and m are integers), checksum hashes (e.g., cyclic redundancy checks (CRCs)), and cryptographic hash functions such as the message digest hash family (e.g., MD5) and the secure hash family (e.g., SHA-3), among others. An index calculated according to the result of applying a hash function is considered a hash index herein.

[0031]

[0047] In some embodiments, the index identifying records in the domain name database 50 is calculated using multiple hash functions H1, . . . , H k An example of such hashing is shown in Figure 8, where a database 50 includes multiple hash tables 51a-c. Each row in each hash table represents an individual record indexed according to its domain name, and d j(j=1, 2, ...). Each record is represented as e(d j ), which may contain, for example, the IP address of the respective domain. In each hash table 51a-c, an index identifying each record is determined by applying a hash function to the respective domain name. However, each table 51a-c uses a separate hash function to determine its index. In an exemplary cuckoo hashing scheme, records are inserted successively by calculating an index for each record using a first hash function. If the row indicated by the respective index is empty, the current record is inserted into that row. If the respective row is already occupied, another hash index is calculated according to a second hash function, and so on. If all the indexes calculated according to the hash functions point to an already occupied row, one of the existing records is replaced by the current record. The previous occupant of each row is then placed in an alternate location (i.e., at an index calculated using a different hash function), possibly replacing another record. This process continues recursively until all records have found a place in one of the hash tables. However, it is possible for the insertion process to fail, for example, by entering an infinite loop. In this case, the hash table is reconstructed using a new choice of hash function.

[0032]

[0048] 9 illustrates exemplary contents of a PIR query 52 and a PIR response 54 according to some embodiments of the present invention. The PIR query 52 may include ciphertext that includes an encryption of an index that identifies a selected record in the domain name database 50. In the example in FIG. 9, the index includes a hash of the domain name. In an embodiment using cuckoo hashing, for each domain name, the client device 12 generates a hash of the domain name using a separate hash function H j It is possible to send out multiple encrypted hash indexes, each calculated according to: Such encrypted hash indexes can be packaged into individual PIR queries or combined into a single PIR query.

[0033]

[0049] In some embodiments, PIR query 52 further includes an index (denoted herein as h) of the hash function used to calculate the respective hash index. For example, h may include a software version number or some other parameter value that enables DNS server system 20 to determine whether the hash function used by each client matches the hash function used to construct the hash table of domain name database 50. Further details about checking hashing consistency are provided below in connection with FIG. 13.

[0034]

[0050] If database 50 contains records identified by the respective indexes, PIR response 54 may return ciphertext that includes an encryption of at least one entry e of the respective database record. If no such records exist in database 50, some embodiments may respond with an encryption of a predetermined dummy entry (e.g., a predetermined symbol indicating that database 50 does not currently have a record with the requested index).

[0035]

[0051] FIG. 10 illustrates exemplary components executing on client device 12 according to some embodiments of the present invention. Such software may include an operating system (OS) 62, which may be any widely available operating system, such as Microsoft Windows®, MacOS®, Linux®, iOS®, or Android®, among others. OS 62 provides an interface between the hardware of client device 12 and a suite of applications, including, among others, client applications 64 and a domain name resolver 66. Client applications 64 collectively represent any computer program, such as word processing, spreadsheet, image processing, gaming, electronic communications, web browsing, and social media applications, among others. In some embodiments, applications 64 provide computer security services to each client system by, for example, filtering / blocking traffic to / from particular Internet domains, determining whether incoming and / or outgoing electronic communications contain malicious code or unwanted content (spam), etc.

[0036]

[0052] The application 64 may connect to and exchange data with the content server 16, e.g., via a set of HTTP requests. As part of such an exchange, the application 64 may transmit an indication of a domain name d to the domain name resolver 66 and, in response, receive from the resolver 66 a domain name database entry e(d) that characterizes the respective domain. In a simple DNS lookup example, e(d) may include the IP address of the domain d. In another example, e(d) may include a set of registration data regarding the domain d (e.g., the identity of the respective domain's owner). In yet another example, e(d) may include an indication of whether accessing the domain d exposes the respective client to a computer security threat, e.g., whether the domain d is known to distribute malicious documents. In general, e(d) may include any data stored in the domain name database 50 and indexed under the domain d.

[0037]

[0053] In some embodiments, the domain name resolver 66 is configured to engage in privacy-preserving DNS transactions with the DNS server system 20 (see also FIG. 8 ). The resolver 66 can therefore formulate and issue a PIR query 52 according to a domain name received from the application 64. The resolver 66 can further receive the PIR response 54, extract the plaintext data entry e(d), and forward it to the application 64. The domain name resolver 66 can further include a cryptographic engine 68 configured to perform encryption and / or decryption operations. In some embodiments, the engine 68 implements a suite of homomorphic cryptographic algorithms / procedures. The cryptographic engine 68 can be implemented in software, hardware, or a combination thereof.

[0038]

[0054] In alternative embodiments to that shown in FIG. 10, domain name resolver 66 may run partially or wholly on a machine separate from client device 12, for example, on router 14 or another gateway device connecting client device 12 to extended network 15 (see FIG. 1), or on resolver name server 20a (FIG. 2).

[0039]

[0055] FIG. 11 illustrates an exemplary sequence of steps performed by domain name resolver 66 according to some embodiments of the present invention. The illustrated resolver may wait for a triggering event, such as a communication received from application 64 and / or a remote server. If an event is detected, a course of action is determined according to the type of event. If the detected event includes a domain lookup request from application 64 (step 206 returns "yes"), then in step 208, some embodiments may select a name server according to the received lookup request. In some embodiments, different types of domain name services may be provided by different servers. For example, some name servers may be dedicated to returning IP addresses, while other name servers may return database entries related to computer security. Furthermore, if the domain name service includes determining the IP address of a selected domain, some embodiments may employ PIR only when querying the selected name server (see details below).

[0040]

[0056] Next, in step 210, the resolver 66 may formulate at least one PIR query 52 according to each domain name. Step 210 may include, among other things, applying the selected hash function to each domain name and employing the cryptographic engine 68 to encrypt the hashing result, for example, using a homomorphic encryption procedure / algorithm. The engine 68 may use any homomorphic encryption procedure known in the art, for example, an encryption algorithm of a fully homomorphic encryption scheme such as GSW (Gentry-Sahai-Waters). Some such procedures include further data manipulation aimed at reducing the computational load on the client side and / or server side, as detailed, for example, in Gentry C., Halevi S., "Compressible FHE with Applications to PIR," in Hofheinz D., Rosen A. (eds.) Theory of Cryptography, TCC 2019, Lecture Notes in Computer Science, vol. 11892, Springer, Cham. The encrypted PIR query is then transmitted to the selected name server.

[0041]

[0057] If the triggering event includes receiving a PIR response 54 from the server, then in step 216 the resolver 66 can use the crypto engine 68 to decrypt the ciphertext included in the response 54 and thus recover the database entry (e.g., IP address) associated with the queried domain name. If the domain name database 50 does not contain an entry associated with the respective domain name, decrypting the respective ciphertext may generate a dummy message indicating failure. A further step 218 can transmit the results of the decryption procedure to the application 64. Step 216 uses a homomorphic decryption procedure / algorithm, for example, the fully homomorphic decryption procedure / algorithm described in Gentry C., Halevi S., "Compressible FHE with Applications to PIR," in Hofheinz D., Rosen A. (eds.) Theory of Cryptography, TCC 2019, Lecture Notes in Computer Science, vol. 11892, Springer, Cham.

[0042]

[0058] 12 illustrates exemplary components of DNS server system 20 according to some embodiments of the present invention. The illustrated components may run on a single physical machine or on separate, communicatively coupled machines. Server system 20 collectively represents the set of name servers illustrated in FIG. 2.

[0043]

[0059] In some embodiments, database maintenance module 26 is configured to keep domain name database 50 up to date by inserting records corresponding to new domain names, making changes to selected records (e.g., changing domain registration data, changing the cluster allocation for each domain, removing each domain from a blacklist, etc.), and / or deleting expired records. An exemplary operation of module 26 is shown in FIG. 13. In a series of steps 222-224, module 26 may check whether database update conditions are met. Some embodiments may perform database updates on a scheduled basis (e.g., hourly) or on-demand. In an alternative embodiment, an update agent may accumulate incoming domain data 55 in a queue and determine that the update conditions are met when the queue is full. If the update conditions are met, step 226 may attempt to update database 50, e.g., by inserting a set of new records. Step 226 may include computing a hash index, e.g., by applying a hash function to each new domain name, and inserting the record with the newly computed index into a table row. However, such an insert operation may fail, for example, in the case of a hash collision, i.e., if two different domain names hash to the same index. In embodiments using a cuckoo hashing scheme, the conflict can be resolved by computing another index, such as using a second hash function. Even in such embodiments, it may not be possible to insert a particular record due to multiple hash collisions.Such a situation may require selecting a new set of hash functions and re-indexing the database 50 using the new hash functions (steps 230-232 in FIG. 13).

[0044]

[0060] If the hash function changes in response to a successful database update, step 234 can distribute an updated set of hash function specifications 56 to clients (see, e.g., Figures 7, 10, and 12). Step 234 can therefore ensure hashing consistency, i.e., that all clients consistently formulate PIR requests using the version of the hash function that was used in indexing database 50.

[0045]

[0061] In some embodiments, the PIR module 28 of the DNS server system 20 is configured to perform an encrypted lookup to the domain name database 50 in accordance with the query 52. The term "encrypted lookup" herein refers to retrieving from the database 50 records indicated by indexes included in the PIR query 52 in encrypted form, without decrypting the respective indexes. The encrypted lookup procedure may involve directly performing a set of operations, such as addition and multiplication, on encrypted data to produce an encrypted result, as exemplified by equation [2] above. Thus, an encrypted lookup does not involve first decrypting the query to generate a plaintext index and then looking up the plaintext index into the respective database, as may be done in traditional versions of encrypted DNS, such as DNS-over-HTTPS.

[0046]

[0062] An exemplary operation of the PIR module 28 is shown in FIG. 14. A series of steps 242-244 may listen for incoming PIR queries. If a query is received, step 246 may check for hashing consistency. In other words, step 246 may determine whether each query was formulated according to the same hash function specification used to index the domain name database 50. If not, in step 254, the DNS server system 20 may return an error message to each requesting client. Some embodiments may further push an updated hash function specification 56 to each client.

[0047]

[0063] In response to determining that the hashing is consistent, step 248 performs an encrypted lookup into database 50 according to PIR query 52. Step 248 can employ any method known in the art, such as those described in Gentry C., Halevi S., "Compressible FHE with Applications to PIR," in Hofheinz D., Rosen A. (eds.) Theory of Cryptography, TCC 2019, Lecture Notes in Computer Science, vol. 11892, Springer, Cham. A series of steps 250-252 can then formulate a PIR response 54 and transmit the response 54 to each client device.

[0048]

[0064] Various domain name services can be implemented in a privacy-preserving manner, as described above. Some example use case scenarios include the following:

[0049] Resolving domain names to addresses (IP address lookup)

[0065] One application of the systems and methods described herein is to perform DNS lookups, i.e., returning IP addresses associated with selected domain names. In such an embodiment, a domain name database 50 may store a set of IP addresses indexed by domain name. A PIR query 52 may include an encryption of an index determined by hashing the respective domain name, and possibly other data (e.g., an encoding of the question Q; see, e.g., FIG. 9 ). In response, the DNS server system 20 may return a PIR response 54 that includes an encryption of the respective IP addresses. The client (or another machine in communication with the respective client) can then decrypt and use the respective IP addresses to route electronic communications (e.g., web browsing).

[0050]

[0066] An exemplary sequence of steps performed by domain name resolver 66 in one embodiment configured to perform domain name resolution (mapping domain names to IP addresses) is shown in FIG. 15. To optimize DNS lookups, some embodiments may maintain a local cache that stores previously resolved IP addresses of TLDs and / or authoritative name servers. In response to receiving a request to resolve a selected domain name, some embodiments may iterate through successive levels of the domain name hierarchy. If each FQDN has not yet been fully resolved to an IP address, step 268 may determine the PQDN for each domain name. The PQDN may include a portion of the specified FQDN up to a selected level of the hierarchy (e.g., up to the TLD level, e.g., ".org" (see FIG. 6)). In step 270, resolver 66 may check whether each PQDN has been previously resolved by performing a cache lookup. If yes, the cache may hold IP addresses for name servers that can resolve the next-level FQDN 36. If no, step 272 may select a name server to resolve the current PQDN. In one example where the PQDN is ".org," the selected name server may be the root name server 20b, and so on.

[0051]

[0067] Some embodiments rely on the observation that the PIR procedure is computationally expensive, both in terms of processor load and communication size. Furthermore, as shown above in connection with FIG. 6 , a typical DNS lookup may require multiple iterative queries, for example, first to a root name server, then to a TLD name server, and finally to an authoritative server. In other words, a single DNS lookup may increase the multiplicity cost of the PIR procedure. Further complicating the issue is the fact that DNS lookups are performed relatively frequently; for example, accessing a single web page may involve multiple successive DNS lookup operations.

[0052]

[0068] Some embodiments further rely on the observation that some FQDNs are more privacy-sensitive than other FQDNs. For example, a user may be less concerned about revealing selected portions of their browsing history (e.g., visiting online news or reference sites such as Wikipedia, among others) as opposed to other portions (e.g., visiting adult content sites). Furthermore, some portions of an FQDN may be more privacy-sensitive than others. For example, using the example in FIG. 6, knowing that a user desires to access the .org top-level domain is much less informational or of greater privacy concern than knowing that the user is actually attempting to access wikimedia.org.

[0053]

[0069] Therefore, to mitigate some of the computational costs incurred by PIR, some embodiments intentionally use PIR only for a subset of DNS queries. Determining whether to use PIR may include determining whether a privacy condition is met, i.e., determining whether the current query is privacy-sensitive. Exemplary step 274 in FIG. 15 evaluates the privacy condition. If the current query is deemed privacy-sensitive (YES branch), a series of steps 276-277 may formulate the current query using homomorphic encryption (PIR). Otherwise, the current query may be performed using conventional DNS.

[0054]

[0070] Some embodiments determine whether privacy conditions are met according to the authoritative zone of the selected name server. For example, some embodiments transmit PIR queries only to TLD name server 20c and / or authoritative name server 20d, while queries addressed to root name server 20b are formulated using conventional DNS. In other words, such embodiments resolve the TLD token of the FQDN 36 via a conventional (non-private) DNS query and the domain token and / or prefix token using the PIR.

[0055]

[0071] Some embodiments of resolver 66 determine whether privacy conditions are met according to at least one of the tokens of FQDN 36. For example, resolver 66 may use traditional (i.e., non-PIR) DNS queries to resolve selected PQDNs, such as “google.com,” “wikipedia.org,” “amazonaws.com,” etc., and PIR queries to resolve other PQDNs, such as “facebook.com,” “pornhub.com,” etc. Such embodiments rely on the observation that some online activities (e.g., performing a Google search, visiting news sites, checking weather forecasts or sports scores, etc.) may pose fewer privacy concerns than other online activities (e.g., accessing adult content, streaming movies, accessing selected e-commerce, online banking, or social media portals, etc.). In another example, knowing that a user is accessing a cloud computing service (e.g., Amazon Web Services™ from Amazon, Inc., or Microsoft’s Azure™) may pose fewer information or privacy concerns. Because each domain may host thousands of different subdomains, to enable selective PIR queries, some embodiments maintain a blacklist of PQDNs that are considered privacy-sensitive and / or a whitelist of PQDNs that can be looked up using traditional DNS. Exemplary whitelists can include, among others, search engine domains, news domains, online advertising and / or other content distribution domains, and domains that offer various cloud computing services (file hosting, infrastructure as a service, etc.).Step 274 may then include looking up the current PQDN / domain name token in a whitelist and deciding to send a conventional query if the respective PQDN / token is on the whitelist, and a PIR query if it is not. Alternatively, resolver 66 may look up a blacklist and decide to send a PIR query if the respective PQDN / token is on the blacklist, and a conventional DNS query if it is not.

[0056]

[0072] Selective PIR querying can also be performed at the subdomain level. Some embodiments rely on the observation that in cases where leaking a domain-level PQDN may not constitute a particular privacy concern (e.g., google.com), leaking some subdomain tokens may be problematic. For example, "www.google.com" may be less privacy-sensitive than "meet.google.com." Some embodiments therefore maintain a whitelist and / or blacklist of prefix tokens and / or FQDNs and decide whether to query the respective authoritative servers using PIR or traditional DNS. A simple embodiment could use traditional DNS queries to resolve "www" subdomains and PIR queries otherwise.

[0057]

[0073] Table 1 provides some more examples of FQDNs and their associated privacy issues.

[0058] [Table 1]

[0059]

[0074] If step 274 determines that the conditions for using a PIR are met, then in step 276, resolver 66 may negotiate a set of homomorphic encryption parameters (e.g., keys, shared secrets, nonce, etc.) with server system 20. Some embodiments use a homomorphic encryption scheme to generate a private / public key pair or an encryption / decryption key pair. Step 277 may then formulate a PIR query 52, for example, by hashing each PQDN and encrypting each hash, and possibly other data such as an index of question Q (see FIG. 9 ), using the public keys of the negotiated pair.

[0060]

[0075] In cases where step 274 determines that the conditions for using PIR are not met, some embodiments may formulate a conventional DNS query (see FIGS. 3-4). Step 278 may further include, for example, negotiating a session encryption key pair under the DNS over HTTPs protocol and encrypting each DNS query using the public key of the key pair. In some embodiments, both conventional and PIR queries are encrypted and transmitted via a protocol such as DNS over HTTPs. Such a strategy may benefit from other features of the protocol, such as ensuring the integrity of each transmission. However, PIR queries include an additional layer of encryption compared to conventional DNS queries, which corresponds to the homomorphic encryption that enables PIR. The layer of encryption corresponding to DNS over HTTPs or a similar protocol is removed by the server. Nevertheless, although such decryption produces a plaintext version of the conventional DNS query, the server does not remove the homomorphic encryption layer from the PIR query, and therefore the PIR query remains unreadable by the DNS server system 20.

[0061]

[0076] Having transmitted the query to the appropriate name servers, in step 282, resolver 66 may wait for a response from each server. A further series of steps 284-286 may extract the IP addresses associated with the current PQDN from the server responses and cache each IP address for further use. Each IP address may include the address of a name server for the fully resolved IP address associated with the current FQDN. If the server response includes a PIR response 54, step 284 may include decoding the enclosed IP address using a homomorphic decoding procedure.

[0062]

[0077] Some embodiments implement further optimizations to mitigate the substantial computational cost of PIR. One such example includes reducing the size of domain name database 50 by dividing it into subunits / buckets according to the total number of records and / or according to the desired lookup performance and / or desired level of privacy. In such an embodiment, instead of searching the complete database of domain names, the server will only look in the buckets that hold the records for each domain. Smaller buckets allow for greater reduction in lookup time, but at the same time provide less privacy because there is less uncertainty about the identity of each domain. An exemplary bucket size that can provide a compromise between speed and privacy is 2 16 =65536, i.e., each bucket can allow resolution between up to 65536 different domain names. Each bucket can also store multiple hash tables, as described above in connection with Figure 8. Individual buckets can be operated by separate computer systems, assigned to separate processor cores of the same computer, etc.

[0063]

[0078] Some embodiments may then use a hash function (e.g., a variant of the Fowler-Noll-Vo hash such as FNV-1) to identify the bucket that holds each record. The output of the hash function may be truncated to the number of buckets by applying a modulo operation. On the server side, an exemplary bucket index may be calculated as follows:

[0064] I B (d,Q)=H B ([Q,d])modN B , [4] d and Q denote the domain name and question (e.g., A vs. AAAA), respectively, and H B denotes the hash function used to bucketize, and N B denotes the bucket number, and [Qd] denotes the concatenation of Q and d. Those skilled in the art will appreciate that the illustrated manner of calculating the bucket index is intended as an example only and is not intended to limit the scope of the present invention.

[0065]

[0079] For each domain name in the database 50, the database maintenance module 26 B Calculate the index I B Each record can be placed in a bucket with I. Placing the record can include, as described above, applying a cuckoo hashing scheme to find a location for each record in one of a number of hash tables. On the client side, the resolver 66 then B and append it to the PIR query 52. The bucket index may be transmitted as plain text or encrypted. Upon receiving the PIR query 52, the server 20 may determine the buckets according to the query 52, and then perform PIR according to the contents of each bucket to generate a PIR response 54.

[0066] Computer Security and Analytical Applications

[0080] Some embodiments can be adapted for computer security and data analysis applications. In such use case scenarios, the domain name database 50 stores records indicating each domain's membership in a particular class or category of domains. In some embodiments, the categories may be related to computer security. For example, one category may include domains characterized by distributing adult content. Another exemplary category includes a blacklist of domains known to engage in fraudulent activity. Another exemplary category includes domains characterized by engaging in denial-of-service attacks (e.g., members of a particular botnet).

[0067]

[0081] Other categories may be related to various aspects of data analysis. For example, domains can be grouped into classes / categories according to content (e.g., gaming, news, reference, education, etc.). Other grouping / classification criteria can include ownership and / or commercial affiliation. For example, all domains owned by the same company or by members of the same conglomerate or alliance can be grouped together into a separate domain category. Another classification criteria includes membership in a particular online activity. For example, all domain names associated with a particular online game and / or games produced by a particular game maker can be grouped together in a separate category. Yet another classification criteria can include geolocation; domains from a particular geographic region, country, etc. can be grouped together. Other exemplary criteria can include domain age / time of first registration.

[0068]

[0082] In yet another example of classification, domains can be grouped into clusters according to shared features or other types of similarities between the domains. FIG. 16 illustrates a set of domains 30a-b and a set of clusters 60a-b according to some embodiments of the present invention. Cluster membership need not be exclusive; in the example of FIG. 16, domain 30b belongs to both clusters 60a-b. In some embodiments, the similarity of two domains can be evaluated according to the hyperdistance separating the two domains in an N-dimensional abstract feature space. However, similarity need not be based on the domain features themselves. In one such example, two domains can be considered similar if they frequently appear together in a series of DNS queries, and such two domains can be placed in the same cluster. In another example, clusters can be automatically generated by a neural network classifier using an unsupervised learning algorithm. Individual clusters may or may not correspond to distinct domain categories. For example, a "malicious" domain category may include multiple clusters, each of which may include domains from distinct botnets.

[0069]

[0083] The clustering and / or classification of domains themselves (i.e., grouping domains into categories or clusters) is beyond the scope of this description and can be achieved using any method known in the art of data mining. This description focuses on accessing existing classifications via PIR. In some embodiments, records stored in domain name database 50 may include a Boolean value indicating whether a domain belongs to a particular category. Alternatively, records may include a label or other identifier of the category / cluster to which each domain belongs. Such records may be accessed using the PIR query and response mechanism outlined above. In some embodiments, PIR query 52 may include encryption of an index into database 50 (e.g., a hash of the domain name), while PIR response 54 may include ciphertext encoding a database entry indicating each domain's category / cluster membership.

[0070]

[0084] Some embodiments may employ the bucketing strategy described above in connection with DNS lookups to speed up server responses in security and / or analytics applications. Individual buckets may correspond to individual security categories, such as malware, fraud, botnets, spam, etc. If the number of records in one such category exceeds a predetermined threshold, some embodiments may divide the database corresponding to each category into sub-buckets and use hashing to identify the bucket containing each individual record. When issuing a query, the client may send the bucket / category index in cleartext or ciphertext.

[0071]

[0085] FIG. 17 illustrates an exemplary hardware configuration of a computing appliance 80 programmed to perform some of the methods described herein. The appliance 80 may correspond to any of the client devices 12a-f, the router 14, and the server 20. The illustrated appliance is a personal computer; other computing devices, such as servers, mobile phones, tablet computers, and wearable computing devices, may have slightly different configurations. The processor 82 includes a physical device (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate) configured to perform calculations and / or logical operations using a set of signals and / or data. Such signals or data may be encoded and delivered to the processor 82 in the form of processor instructions, e.g., machine code. The processor 82 may include an array of central processing units (CPUs) and / or graphics processing units (GPUs).

[0072]

[0086] The memory unit 84 may include volatile computer-readable media (e.g., dynamic random access memory (DRAM)) that store data and / or instructions accessed or generated by the processor 82 in the course of performing operations. The input devices 86 may include, among other things, a computer keyboard, a mouse, and a microphone, including respective hardware interfaces and / or adapters that enable a user to introduce data and / or instructions into the appliance 80. The output devices 88 may include, among other things, a display device such as a monitor and speakers, and hardware interfaces / adapters such as a graphics card that enable the respective computing device to communicate data to a user. In some embodiments, the input and output devices 86-88 share common hardware (e.g., a touchscreen). The storage device 92 includes computer-readable media that enable the non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices include magnetic and optical disks, as well as flash memory devices, and removable media such as CD and / or DVD disks and drives. Network adapter 94 includes mechanical, electrical, and signaling circuits for communicating data over a physical link coupled to an electronic communications network (e.g., networks 13 and 15 in FIG. 1) and / or to other devices / computer systems. Adapter 94 can be configured to transmit and / or receive data using a variety of communications protocols.

[0073]

[0087] Controller hub 90 collectively represents multiple system buses, peripheral buses, and / or chipset buses, and / or any other circuitry that enables communication between processor 82 and the rest of the hardware components of appliance 80. For example, controller hub 90 may include a memory controller, an input / output (I / O) controller, and an interrupt controller. Depending on the hardware manufacturer, several such controllers may be combined into a single integrated circuit and / or may be integrated with processor 82. In another example, controller hub 90 may include a northbridge that connects processor 82 to memory 84 and / or a southbridge that connects processor 82 to devices 86, 88, 92, and 94.

[0074]

[0088] It will also be apparent to those skilled in the art that the above-described aspects of the present invention may be implemented in various forms of software, firmware, and hardware, or combinations thereof. For example, certain portions of the present invention may be described as dedicated hardware logic that performs one or more functions. This dedicated logic may include an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). The actual software code or dedicated control hardware used to implement aspects consistent with the principles of the present invention is not a limitation of the present invention. Thus, while the operation and behavior of aspects of the present invention have been described without reference to specific software code, it will be understood that one skilled in the art would be able to design software and control hardware to implement those aspects based on the description herein.

[0075]

[0089] The exemplary systems and methods described above enable various domain name services to be performed while preserving the privacy of the beneficiaries of the respective services. For example, some embodiments enable translation between domain names and IP addresses, where the name server that performs the actual translation / database lookup is unaware of the respective domain names and IP addresses. Some embodiments use homomorphic encryption to enable a server-side personal information lookup (PIR) procedure. The server returns ciphertexts to the client, which then decrypts each ciphertext to generate the desired database entry (e.g., IP address).

[0076]

[0090] In traditional DNS, client queries and / or server responses are not encrypted, allowing any third party to spy on the respective DNS data. Newer developments in DNS technology encrypt queries and / or client responses, thereby essentially keeping the data private during transit. However, in such variants of DNS, name servers still decrypt DNS queries to generate plaintext domain names. In contrast to such traditional DNS, in some embodiments, the PIR procedure uses encrypted input, so that name servers no longer have access to transaction data in plaintext. Therefore, some embodiments ensure a stronger level of privacy compared to traditional DNS solutions.

[0077]

[0091] The PIR procedure is relatively costly in terms of computation and the amount of data exchanged in each client / server transaction. To mitigate costs, some embodiments do not perform all stages of domain name resolution using PIR. Instead, a client can query top-level domain (TLD) name servers using traditional DNS or a non-homomorphically encrypted variant such as DNS over HTTPS, and use the PIR procedure only to query selected name servers that resolve each domain name at the domain and / or subdomain level of the domain name hierarchy. Such a strategy relies on the observation that information provided by the latter name servers is relatively more important to privacy than, for example, the TLD portion of the domain name. Some embodiments further selectively apply PIR according to at least one token of each FQDN. In other words, resolving certain tokens (e.g., “google.com,” “www,” etc.) can be performed via traditional DNS, while resolving other, more privacy-sensitive tokens can be performed via PIR.

[0078]

[0092] DNS databases can hold millions of individual records. The size of such databases alone may make PIR queries infeasible. To address such limitations, some embodiments further employ a bucketing approach to reduce the size of the database and, therefore, the complexity of PIR calculations, as well as the size of queries and server responses. Computer experiments have revealed that reducing the database size to 65,536 records allows the average time required to perform a DNS lookup to be kept below 1 second, making application of the current system and method commercially and technically viable. A caveat to this approach is that by reducing the size of the database, privacy is also inherently reduced. However, some choices of database size may offer an acceptable compromise between privacy and speed. Furthermore, because the PIR procedure is in principle parallelizable, further gains in speed can be achieved by using a parallel computing configuration, for example, by setting up server-side PIR using multiple interconnected processor cores or a graphical processing unit (GPU) farm.

[0079]

[0093] Some embodiments of the present invention can be adapted for a variety of other scenarios different from domain name resolution, such as computer security, application control, parental control, etc. In one exemplary use case scenario, a computer security component, which may run on a client, on a router / network gateway, or on a remote security server, may engage in PIR exchanges with a server configured to perform database lookups without decrypting each query. The database records may indicate whether a particular domain is associated with a particular category related to computer security, such as whether the respective domain is blacklisted or engaged in fraudulent activity. In a parental control use case scenario, the database records may indicate, for example, whether a particular domain distributes adult material. In an application control use case scenario, the database records may indicate whether the respective domain is associated with a particular type of online activity (gaming, social media, etc.). Thus, some embodiments enable selective filtering of traffic to or from particular domains or blocking users from accessing particular domains. Such filtering / blocking is known in the art, but in contrast to conventional traffic control procedures, in some embodiments of the present invention, the server performing the actual database lookup does not know the domain name for which information is being requested. This allows, for example, for the server and associated domain name database to be owned and / or operated by a different entity than the provider of the security / parental control / application control service without compromising user privacy.

[0080]

[0094] It will be apparent to those skilled in the art that the above-described embodiments can be modified in many ways without departing from the scope of the present invention, which should therefore be determined by the following claims and their legal equivalents.

Claims

1. 1. A method for performing a Domain Name Service (DNS) lookup, using at least one hardware processor of a computer system, comprising: In response to receiving the indication of the domain name, determining whether a privacy condition is satisfied according to the domain name; responsive to determining whether the privacy condition is satisfied, if "yes," formulating a private query including encrypting a hash index indicating a location of a record in a domain name database, the hash index being encrypted according to a homomorphic encryption procedure, the hash index being determined according to the domain name; In response to formulating the private query, transmitting the private query to a name server, the name server configured to perform an encrypted lookup to the domain name database in accordance with the private query to generate an encryption of the record; in response to receiving a private response from the name server that includes the encryption of the record, decrypting the contents of the private response according to a homomorphic decoding procedure; A method comprising the step of:

2. 10. The method of claim 1, wherein, in response to determining whether the privacy condition is satisfied, if "no," the method comprises using at least one hardware processor of the computer system: formulating another query according to the domain name, wherein the content of the another query is encrypted according to a non-homomorphic encryption procedure; transmitting the other query to the name server; The method further comprising the step of:

3. 2. The method of claim 1, wherein the domain name includes a series of tokens, and determining whether the privacy condition is satisfied includes determining whether a selected token from the series of tokens matches any member of a reference list of tokens.

4. The method of claim 3 , wherein the selected token comprises a domain token or a prefix token.

5. 2. The method of claim 1, further comprising determining whether the privacy condition is met according to an authoritative zone of the name server.

6. 6. The method of claim 5, further comprising determining that the privacy condition is not met if the name server comprises a top-level domain (TLD) name server.

7. 2. The method of claim 1, wherein the private query further includes a bucket index that identifies the domain name database from among a plurality of domain name databases connected to the name server.

8. The method of claim 1 , wherein the record includes an Internet Protocol (IP) address.

9. 2. The method of claim 1, wherein the record includes a security indicator that indicates whether accessing the domain represented by the domain name exposes the user to a computer security threat.

10. 1. A computer system including at least one hardware processor, the at least one hardware processor comprising: In response to receiving the indication of the domain name, determining whether a privacy condition is satisfied according to the domain name; responsive to determining whether the privacy condition is satisfied, if "yes," formulating a private query including encrypting a hash index indicating a location of a record in a domain name database, the hash index being encrypted according to a homomorphic encryption procedure, the hash index being determined according to the domain name; In response to formulating the private query, transmitting the private query to a name server, the name server configured to perform an encrypted lookup to the domain name database in accordance with the private query to generate an encryption of the record; in response to receiving a private response from the name server that includes the encryption of the record, decrypting the contents of the private response according to a homomorphic decoding procedure; A computer system configured to:

11. 11. The computer system of claim 10, wherein the at least one hardware processor, in response to determining whether the privacy condition is satisfied, if "no": formulating another query according to the domain name, wherein the content of the another query is encrypted according to a non-homomorphic encryption procedure; transmitting the other query to the name server; The computer system further configured to:

12. 11. The computer system of claim 10, wherein the domain name includes a series of tokens, and determining whether the privacy condition is satisfied includes determining whether a selected token from the series of tokens matches any member of a reference list of tokens.

13. 13. The computer system of claim 12, wherein the selected token comprises a domain token or a prefix token.

14. 11. The computer system of claim 10, wherein the at least one hardware processor is configured to determine whether the privacy condition is met further according to an authoritative zone of the name server.

15. 15. The computer system of claim 14, wherein the at least one hardware processor is further configured to determine that the privacy condition is not satisfied if the name server includes a top-level domain (TLD) name server.

16. 11. The computer system of claim 10, wherein the private query further includes a bucket index that identifies the domain name database from among a plurality of domain name databases connected to the name server.

17. 11. The computer system of claim 10, wherein the record includes an Internet Protocol (IP) address.

18. 11. The computer system of claim 10, wherein the record includes a security indicator that indicates whether accessing the domain represented by the domain name exposes the user to a computer security threat.

19. A non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a computer system, In response to receiving the indication of the domain name, determining whether a privacy condition is satisfied according to the domain name; responsive to determining whether the privacy condition is satisfied, if "yes," formulating a private query including encrypting a hash index indicating a location of a record in a domain name database, the hash index being encrypted according to a homomorphic encryption procedure, the hash index being determined according to the domain name; In response to formulating the private query, transmitting the private query to a name server, the name server configured to perform an encrypted lookup to the domain name database in accordance with the private query to generate an encryption of the record; in response to receiving a private response from the name server that includes the encryption of the record, decrypting the contents of the private response according to a homomorphic decoding procedure; A non-transitory computer-readable medium that causes the computer system to perform the above.

20. 1. A server computer system configured to engage in Domain Name Service (DNS) transactions with a plurality of clients, the server computer system including at least one hardware processor, the at least one hardware processor comprising: receiving a private query from one of the plurality of clients, the private query including an encryption of a hash index indicating a location of a record in a domain name database, the hash index encrypted according to a homomorphic encryption procedure, the hash index being determined according to a domain name; In response to receiving the private query, performing an encrypted lookup to the domain name database according to the private query to generate an encryption of the record; transmitting a private response to the client that includes the encryption of the record; and A server computer system configured to:

Images