HK1159282B

HK1159282B - Secure resource name resolution

Info

Publication number: HK1159282B
Application number: HK11113625.3A
Authority: HK
Inventors: R．M．特蕾西; L．梅伦
Original assignee: 微软技术许可有限责任公司
Priority date: 2008-08-08
Filing date: 2009-07-20
Publication date: 2016-01-08

Description

Secure resource name resolution

Background

The present invention relates to a name resolution technique. In computer communication networks, several different techniques may be used to identify resources accessible via the network. These resources may include hosts attached to the network, such as client and server computing devices, as well as networking resources such as routers, gateways, firewalls, and other devices. In one technique, a resource may be identified by one or more identification numbers, such as a Media Access Control (MAC) address or an Internet Protocol (IP) address. However, it has been recognized that while these addresses are useful for computer-to-computer communications, users often find it difficult to remember these identification numbers, and this difficulty may prevent users from accessing network resources. Resources may therefore additionally or alternatively be identified by text identifiers that are more easily remembered by the user. Technologies implementing textual identifiers for identifying resources include NetBOIS, Local Link Multicast Name Resolution (LLMNR), and Domain Name System (DNS).

Techniques for providing such textual identifiers may also provide a conversion service for matching textual identifiers that are easily remembered by a user to numeric identifiers that are more easily handled by a computer device (or vice versa). For example, in DNS, when a user enters a textual identifier (a "domain name" in DNS) into a computing device to initiate communication with a resource identified by the domain name, a DNS client on the computing device will query a DNS server to "resolve" the domain name to an IP address. Upon receiving the query, the DNS server will find the IP address corresponding to the domain name, either through information available locally to it or by querying other DNS servers, and return the IP address to the DNS client. The computing device may then initiate communication with the resource using the IP address.

It has been recognized that some such name resolution techniques may be abused. For example, in DNS, an attacker may be able to misdirect a computing device to the attacker's own resources (e.g., the attacker's server) by responding to a DNS query with the IP address of the attacker's resources before the DNS server responds with a legitimate IP address. The computing device may thus be misdirected and will connect to the attacker's resources rather than legitimate resources. Then, upon connecting to the attacker's resources, the computing device may leak data to the attacker or receive fake data or malware from the attacker.

Certain security techniques have been implemented to reduce the likelihood of this situation, for example by including a randomized identifier in each DNS query and requiring them to be included in a response to the query, which would prevent an attacker from responding with spoofed addresses unless the attacker could guess or detect the randomized identifier of the query. One security technique that has been proposed to address these security issues is the Domain Name System Security Extensions (DNSSEC) protocol implemented with DNS. DNSSEC provides a digital signature by the Certification Authority (CA) of the DNS result so that the result can be verified as accurate. In addition, it has been proposed to use DNS or DNSSEC for the internet protocol security (IPsec) protocol to allow encryption and/or authentication of communications between DNS clients and DNS servers.

SUMMARY

Applicants have recognized and appreciated that the security of conventional name resolution techniques, including DNS, can be improved. Furthermore, conventional name resolution techniques are not designed to operate in a manner that connects to several networks via a single network interface and a single set of network hardware, thus hindering the growth of overlay networks.

Described herein are principles for securing name resolution technology and for ensuring that name resolution technology can function in modern networks. Some of the described methods are compatible with network configurations having overlay networks that are accessible via the same interface as the underlay network. According to some of the principles described herein, a set of resolution parameters may be implemented by a user, such as an end user or administrator, that are used in a name resolution process to secure the process and/or to perform the process in an overlay network. In some implementations, the set of resolution parameters may be maintained in accordance with a rule table and used to govern the name resolution process. For example, resolution parameters may be created to govern a DNSSEC session, or how to communicate with a network implemented with microsoft's Direct Access (Direct Access) overlay technology, or to govern communications using any other networking technology.

In some embodiments, a method is provided that includes accepting as input a first identifier of a network resource, consulting a set of sets of resolution parameters to determine a set of applicable resolution parameters to apply to the first identifier, and obtaining a second identifier. The second identifier may be obtained by performing a name resolution process to determine a second identifier for the network resource based on the first identifier. The name resolution process is governed by the set of applicable resolution parameters.

In other embodiments, at least one computer-readable storage medium is provided having encoded thereon computer-executable instructions that, when executed, cause a computer to perform a method. The method includes accepting as input from an application a domain name of a resource accessible via a network, determining a set of applicable resolution parameters from a set of sets of resolution parameters, and establishing a connection to a Domain Name Service (DNS) server on the network according to the set of applicable resolution parameters. The DNS server may be identified by the set of applicable resolution parameters. The method also includes communicating the DNS query to the DNS server according to the set of applicable resolution parameters, receiving a response from the DNS server that includes a numeric identifier for the resource, and providing the numeric identifier to the application.

In still other embodiments, an apparatus is provided that includes at least one processor and at least one tangible computer-readable storage medium having encoded thereon a data structure that includes information related to a set of resolution parameters. The data structure is stored in a manner that can be used by the name resolution software component to govern the name resolution process. The data structure includes a first location to record information defining a set of one or more identifiers of network resources to which the resolution parameters are to be applied; a second location to record information defining a type of security measure to be implemented on a communication channel over which a name resolution process exchanges information; a third location where information defining at least one trusted certification authority is to be recorded; and a fourth location to record information defining at least one network resource with which the communication channel is to be established. The at least one tangible computer-readable storage medium includes a plurality of instances of a data structure, each instance of the data structure being associated with a particular set of resolution parameters. The at least one processor is adapted to execute the name resolution software component, and the name resolution software component is adapted to perform a name resolution process according to at least one set of applicable resolution parameters. The name resolution software component reads at least some of a plurality of data structures encoded on at least one tangible computer-readable storage medium to determine one or more sets of applicable resolution parameters.

The foregoing summary is a non-limiting summary of the invention defined by the appended claims.

Brief Description of Drawings

The drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1 illustrates an exemplary computer system in which techniques operating according to some of the principles described herein may function;

FIGS. 2A and 2B illustrate tables of exemplary resolution parameters that may be implemented in accordance with some of the principles described herein;

FIG. 3 is a flow diagram of an exemplary process for performing name resolution that may be implemented according to some of the principles described herein;

FIG. 4 is a flow diagram of an exemplary process for identifying a set of applicable resolution parameters that may be implemented according to some of the principles described herein;

FIG. 5 is a flow diagram of an exemplary process for parsing a textual identifier into a numeric identifier that may be implemented according to some of the principles described herein;

FIG. 6 is a flow diagram of an exemplary process for determining whether an identifier stored in a cache may be returned as a result of a name resolution process that may be implemented in accordance with some of the principles described herein;

FIG. 7 is a flow diagram of an exemplary process for establishing a set of resolution parameters that may be implemented according to some of the principles described herein;

FIG. 8 illustrates an exemplary user interface that may be used to input resolution parameters;

FIG. 9 is a block diagram of components of an exemplary computing device that may implement techniques according to some of the principles described herein; and

FIG. 10 is an illustration of an exemplary manner of interoperability of modules that may be implemented in accordance with one or more techniques operating according to principles described herein.

Detailed Description

For example, although DNSSEC is proposed to ensure that the results of DNS queries are legitimate, it relies on two conditions that may be found to be unacceptable. First, each DNS server involved in responding to DNS queries (possibly in a different location and managed by a different party) must be implemented to handle DNSSEC, which makes it difficult to roll out to the entire internet. Second, the DNS client must essentially act as a full resolver rather than passing the responsibility of most resolving queries to the full resolver (DNS server) as in normal DNS. This adds processing to the client, as the DNS client will become responsible for ensuring that the result is legitimate and correct by checking the digital signature of each result returned to the DNS client to determine whether the Certificate Authority (CA) that issued the certificate used to sign the result is the one that should be trusted. Placing this responsibility on the client computing device executing the DNS client risks overburdening the computing device, which is particularly problematic in less capable computing devices such as Personal Digital Assistants (PDAs) and mobile phones. To remove this burden from the client, the burden may be placed on the server or other network resource.

Furthermore, conventional name resolution techniques are not suitable for working in situations where an overlay network may be present. In the past, computing devices may have been connected to each network through a dedicated network interface, and the network interface has been configured by users and/or by devices on each network to interact with the networks, including configuring the interface to support name resolution techniques implemented by the networks. For example, when a computing device, such as a laptop, connects to a wired network, a Dynamic Host Configuration Protocol (DHCP) server on the network may provide the computing device with an IP address, an identifier of the gateway, and an identifier of a DNS server, among other configuration parameters. Any communication through the interface using the textual identifier will thus be resolved by the DNS server. If a computing device wants to connect to a different network or use a different name resolution technique, a separate interface must be configured. For example, a second wired interface may be used, or a wireless interface may be used.

Applicants have recognized and appreciated that in modern networks, "overlay" networks are becoming increasingly common. These overlay networks are configured to co-exist with existing networks on the same hardware and are logical overlays on top of existing hardware networks. Each network device connected to the overlay network is also connected to one or more existing hardware networks, such as an existing local area network and/or an existing wide area network. These overlay networks may be implemented in any of a variety of ways, such as using microsoft direct access. The overlay network may thus be considered a restricted subgroup of one or more other networks.

Using these techniques, a computing device connected to a given hardware network may thus be connected to multiple networks, including an underlay network and one or more overlay networks, simultaneously via a single interface. Conventional name resolution techniques will not be able to support such networks because the type of name resolution protocol or the network resources (e.g., DNS servers) with which a computing device should communicate to obtain name resolution may be different for an overlay network as compared to the name resolution techniques of the underlay network. Furthermore, because some networks may keep certain information about how to access certain resources on the network, e.g., the location/identity of a particular secure server or other network resource, secret to keep that information from being given to potential attackers, the particular server or other resource may be the only possible source of the expected result of the name resolution query. Alternatively, a certain network resource may have an identifier that is unknown outside of the overlay network, or an identifier that is a duplicate of a textual identifier of another resource outside of the overlay network, and a particular server or other resource may be the only possible source of the desired result of the name resolution query for the particular network resource. Thus, a computing device may have to contact a particular server or other resource during the name resolution process, which may be different for communications on the overlay network than the underlying hardware network, even if the overlay networks use the same name resolution techniques. For this reason, one network interface of the computing device may have to maintain multiple addresses of DNS servers for each of multiple overlay networks so that the computing device can communicate with each overlay network. This is not possible with conventional computing devices, networking technologies, and name resolution technologies.

Described herein are principles for securing name resolution technology and for ensuring that name resolution technology can function in modern networks having multiple overlay networks accessible via a single network interface. In some implementations, a user, such as an end user and/or administrator, may compile a set of resolution parameters applicable to a computing device for one, some, or all network interfaces of the computing device to use to resolve names using name resolution techniques for networks accessible through the interfaces. These resolution parameters may then govern the name resolution process performed by the interface. For example, in some such implementations, the resolution parameters may specify DNSSEC parameters and/or parameters for direct access, although it should be appreciated that other name resolution techniques and other types of networking and security techniques may be used. These resolution parameters may be stored in any manner, such as in a rule table that may be examined by the name resolution module and used to compose a name resolution query.

The resolution parameters may include any suitable information regarding how to perform the name resolution process. Further, the specific parameters used may depend on the type of network for which name resolution is sought. For example, for networks where DNSSEC is used as a name resolution technique, these parameters may include security parameters, such as which domain the resolution parameters apply to, whether the server validates the response, whether encryption should be used to communicate with the server, what type of encryption should be used, what authentication(s) should be trusted to sign the results, and which DNS server(s) the results should be queried for. As another example, for overlay networks such as those implemented using direct access, resolution parameters such as which network/domain the resolution parameters apply to, which DNS server(s) should be queried for results, whether encryption should be used, what type of encryption should be used, what authentication should be trusted to sign the results, and what proxy server should be used when communicating with the overlay network may be implemented. Any suitable resolution parameter may be used depending on the network and the name resolution protocol that may be used to implement the network.

As used herein, a name resolution process may be any suitable technique for determining numeric identifiers corresponding to textual identifiers or determining textual identifiers corresponding to numeric identifiers according to any suitable name resolution protocol. In the examples listed below, the Domain Name Service (DNS) protocol may be used as an example of a name resolution protocol, and the name resolution process may be described as adhering to the DNS protocol. However, it should be understood that DNS is merely one example of a name resolution protocol with which techniques operating according to the principles described herein may operate, and that any suitable name resolution protocol may be implemented, as embodiments of the invention are not limited in this respect.

It should be understood that although many of the examples herein are described in the context of determining numeric identifiers corresponding to input textual identifiers, in some embodiments, a name resolution process may be implemented that additionally or alternatively takes numeric identifiers as input and determines corresponding textual identifiers. Further, it should be appreciated that while the examples listed below describe techniques that operate with a one-to-one correspondence of text identifiers and numeric identifiers (e.g., determining a single numeric identifier corresponding to a single text identifier), this is merely one exemplary embodiment, and in some implementations, a text identifier may have multiple corresponding numeric identifiers and a numeric identifier may have multiple corresponding text identifiers.

The techniques described herein may be implemented in various computing systems, examples of which are described in more detail below. Such systems typically involve the use of suitably configured computing devices that implement functional modules that each provide one or more operations necessary to accomplish the execution of such techniques. Each functional module may be implemented in its own way; not necessarily all implemented in the same way. As used herein, a functional module is a structural component of the system that performs the duties of an operation. The operational responsibilities may be part of the entire software element. For example, the functional modules may perform the functions of a process, a discrete process, or any other suitable processing unit. The functional modules may include computer-executable instructions and may be encoded on computer storage media. Further, such computer-executable instructions may be written using any of a number of suitable programming languages and/or programming or scripting tools, and they may also be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine. The functional modules may execute in parallel or in series, as appropriate, and may communicate information between each other using shared memory on the computer on which the modules execute, using a message passing protocol, or in any other suitable manner. While the following describes example functional modules performing one or more tasks, it should be appreciated that the described functional modules and task partitions are merely illustrative of the types of functional modules that may implement the example techniques described herein and that the present invention is not limited to implementation in any particular number, partition, or type of functional modules. In some implementations, all functions may be implemented in a single functional module. Further, for clarity, functional modules are discussed below as all being executed on one or two computing devices, but it should be understood that in some implementations, functional modules may be implemented on many separate computing devices adapted to communicate with each other. For example, one computing device may be adapted to execute an input module that receives a first identifier, such as a textual identifier, and communicate with a name resolution module on a second computing device to perform a name resolution process to determine a numeric identifier corresponding to the textual identifier.

In one exemplary implementation of the principles described herein, a software application executing on a computing device may accept input from a user of a textual identifier of a desired network resource with which the software application wants to establish a connection. For example, the software application may be a web browser, the textual identifier may be a domain name of a website, and the network resource may be a web server hosting the website. To open a connection to a desired network resource, the software application or connection module will use the numeric identifier of the network resource, and thus the name resolution module (also referred to herein as the "resolution module") can convert the textual identifier into a numeric identifier that is used as a network address, such as an IP address in IPv4 or IPv6 format.

The textual identifier of the network resource will thus be passed to a name resolution module adapted to perform a name resolution process to obtain a numeric identifier, which the name resolution module may then return to the software application. However, prior to performing the name resolution process, the resolution module may review the set of sets of resolution parameters to determine which, if any, of the sets of resolution parameters apply to the name resolution process to be performed. The collection may be stored in any suitable manner, including in a computer storage medium such as a memory in any suitable format. To review the collection to determine which of the sets of parameters applies, the resolution module may retrieve a portion or all of the collection from memory and perform any kind of comparison process, including, for example, comparing the input identifier to parameters in the portion or all of the sets that indicate which network resources a particular set of resolution parameters applies to.

Each set of resolution parameters in the set may be applicable to one or more network resources and may govern the manner in which the name resolution process determines the identifier of the network resource to which they are applicable. These resolution parameters may include any suitable parameters that may affect how the name resolution process is performed, including any of the exemplary parameters described above. For example, each set of name resolution parameters may specify a particular resolution resource, such as a particular DNS server, with which the resolution module should communicate to determine the numeric identifier.

Review of the collection by the parsing module can be accomplished in any suitable manner. In one implementation, the review may include comparing the text identifier to the identifiers of each of the sets of resolution parameters to determine whether there is a match between the identifiers. For example, the identifier of a set of resolution parameters may be a DNS suffix such as ". corp.contoso.com", such that any textual identifier that matches the later part of the identifier is the identifier to which the resolution parameters apply. Thus, if the input text identifier is "webserver. Once one or more sets of applicable resolution parameters are determined, a name resolution process may be performed according to the applicable resolution parameters. For example, if a parameter specifies a particular resolution resource, such as a DNS server, a connection will be established to that resolution resource; if the parameter specifies an encryption level to be used, communication with the name resolution resource will use the encryption level.

Once the parsing module establishes a connection to the parsing resource using the applicable parameters, a parsing request is issued to the parsing resource over the connection, the parsing request including a textual identifier and requesting a corresponding numeric identifier. The resolution resource may perform any suitable process, including any of a variety of processes known in the art for determining a corresponding numeric identifier, such as by consulting information it maintains locally, or by forwarding the request to another resolution resource according to applicable resolution parameters. Once the resolution resource determines the numeric identifier, the resolution resource may perform any suitable validation process on the numeric identifier. For example, if applicable resolution parameters specify that DNSSEC should be used to determine the digital identifier and specify one or more particular certifications that are trusted to provide valid certificates that may be used to certify the result, the resolution resource may determine in a validation process whether the result was signed using a certificate issued by any of the one or more particular certificating authorities. If so, the resolution resource may provide the numeric identifier to a resolution module on the computing device as a result of the resolution request. The resolution module may then confirm that the results were generated according to the applicable resolution parameters and present the results to the software application for use in establishing a connection to the required network resource. On the other hand, if the result is not signed using the specified certificate, the result may be discarded or provided to the parsing module with an indicator indicating that it is not signed according to the parsing parameters.

Several different advantages may be provided by performing a name resolution process in accordance with the principles described herein. First, by maintaining a collection of sets of resolution parameters, the name resolution process can be parameterized with resolution parameters to ensure that the resolution process is secure and the results can be trusted. For example, while in conventional name resolution techniques the computing device must trust that a result from a particular result is legitimate, resolution parameters from the set allow a resolution module within the computing device to query a particular trusted resolution resource to obtain an identifier (numeric or textual) of the desired network resource with a high degree of confidence in response to being legitimate. In addition, the resolution module can be more confident that a given resolution resource will have a corresponding identifier that the module is looking for. In addition, by using a set of resolution parameters, the resolution process can be made more secure by specifying, for example, whether encryption should be used, what type of encryption should be used, and how the encryption should be certified. Further, by specifying the particular resolution resources with which to communicate, the collection can enable the resolution module on the computing device to perform fewer functions and be less burdensome on the computing device, as some functions can be pushed onto network resources, such as resolution resources, that the collection indicates are suitable for processing. For example, in one exemplary DNSSEC implementation, certain validation processes may be performed on a resolution resource, such as a DNS server, in the network. The resolution module, having this set, will know to contact the specific resolution resources that are capable of performing the DNSSEC task. Additionally, using the set, the resolution module can perform different name resolution procedures on different input identifiers, such as contacting a particular resolution resource to obtain a textual identifier for a network resource in the overlay network, or using a secure communication channel to exchange identifiers related to a particular secure network resource.

Other functions and advantages of these and other techniques, which operate according to the principles described herein, will be more fully understood from the examples described below. The following examples are intended to facilitate an understanding of the invention and to illustrate the benefits of the principles described herein, but do not exemplify the full scope of embodiments of the invention.

The techniques operating in accordance with the principles described herein may be implemented in any suitable computer system including any suitable number and type of computing devices, including any suitable number and type of network resources. FIG. 1 shows an illustrative computer system in which some exemplary implementations of the principles described herein may operate. However, it should be understood that other implementations may operate in any other suitable computer system.

Fig. 1 illustrates a computer system that includes a communication network 100 to which user devices (i.e., computing devices 102) can be connected. The communication network 100 may be any suitable wired and/or wireless network, including portions of a larger wired and/or wireless network, such as a home network, a subnet of an enterprise network, the internet, and/or others. Computing device 102 is shown as a desktop personal computer, but may be any suitable computing device, such as a laptop personal computer, a PDA, a smart phone, a server, a rack-mounted computer, a networking device such as a router or switch, or other computing device.

The computing device 102 is coupled to a data store 104 that stores sets of resolution parameters. Data store 104 may be encoded on any suitable computer storage medium or media and may store information in any suitable format. Among the information stored in the data store 104 are resolution parameters that may be used to govern a name resolution process for determining a second identifier corresponding to an input first identifier, such as determining a numeric identifier of a network resource corresponding to an input textual identifier. As described above, the resolution parameters may include any suitable information that may be used during the name resolution process. Computing device 102 may be adapted to execute one or more functional modules that implement this name resolution process in which resolution parameters are used to form a connection to a network resource connected to communication network 100.

The sets of resolution parameters stored in data store 104 can be provisioned in any of a variety of ways, including by a user local to computing device 102 using any suitable user interface, and/or remotely by an administrator using computing device 106. In one example, the administrator may specify the resolution parameters at the computing device 106 and push them down to the computing device 102 through any suitable network management technique. For example, if the communication network 100 comprises a microsoft Windows network available from microsoft corporation of redmond, washington, an administrator may use a domain controller to push resolution parameters out using a group policy over an Active Directory (Active Directory) protocol. However, it should be understood that this is only one example of a network management technique that may be implemented, and that any suitable technique may be used depending on the resources available on the network.

The computing device 102 may use the sets of resolution parameters to perform a name resolution process for determining an identifier (numeric or textual) of a network resource, such as the network resource 108, which may be any computing device accessible via a network, such as any kind of server. To this end, the computing device 102, after accepting input of the first identifier of the network resource 108, may consult the set of sets of resolution parameters stored in the data store 104 to determine a set of applicable resolution parameters, and then perform a name resolution process governed by the set of applicable resolution parameters. During the name resolution process, a resolution module executing on the computing device 102 may communicate with the name resolution resource 110 to determine one or more identifiers of the network resources 108. Any suitable name resolution process may be performed according to the principles described herein, including any of the exemplary name resolution processes described below. This process may include exchanging information with any suitable networking device, such as the resolution resource 110, in any suitable manner. Although the resolution resource 110 is illustrated in FIG. 1 as a server, it should be understood that any suitable computing device may be used as the resolution resource, including multi-purpose devices such as personal computers and single-purpose devices such as hardware name resolution devices.

In some implementations, the communication network 100 may not be a single network, but rather a hardware network having one or more overlay networks 100A instantiated thereon. The overlay network 100A may be instantiated entirely on hardware implementing the communication network 100 or may operate on hardware used in the communication network 100. The communication network 100A may share networking hardware, such as routers and switches, with the communication network 100, but there may be certain network resources, such as client and server computing devices, that may be connected to the communication network 100 via hardware, but that are not accessible to devices that are not members of the overlay network 100A.

As described above, to communicate with network resources on the overlay network, the computing device 102 may have to communicate with particular resolution resources having information about the network resources available on the overlay network 100A, as only these particular resolution resources have knowledge about the network resources available on the overlay network 100A. In these implementations, the sets of resolution parameters may specify one or more particular resolution resources 110A with which the computing device 102 may communicate during the name resolution process to obtain an identifier of a network resource, such as network resource 108. Some or all of the sets of resolution parameters in the set may have identifiers that match network resources of the overlay network 100A. When the resolution module of the computing device 102 reviews the set to determine the set of applicable resolution parameters, the applicable resolution parameters may indicate that an identifier of the desired network resource may be retrieved from the particular resolution resource 110A. Thus, the name resolution process performed by the computing device 102, when parameterized with the set of applicable resolution parameters, may communicate with the particular resolution resource 110A to retrieve the identifier of the desired network resource 108. It should be appreciated that this review and name resolution process may be performed in any suitable manner, including by any of the exemplary techniques described below.

Additionally, in some implementations, the applicable resolution parameters may also specify that communication to the network resource 108 should be accomplished via the proxy server 112. Upon returning the second identifier of the network resource, the resolution module may then additionally or alternatively return an identifier, such as a numeric or textual identifier, for the proxy server 112.

As described above, a set of resolution parameters may include any information that may be used in conducting a name resolution process. Fig. 2A and 2B illustrate exemplary data structures storing sets of resolution parameters that may be used with two exemplary networking technologies in some implementations according to the principles described herein. In addition, although fig. 2A and 2B illustrate two different sets of parameters that include parameters related to two different techniques, it should be understood that in some implementations, the techniques may be implemented in the same set of resolution parameters. Further, the collection may be implemented as any suitable data structure, and in some implementations may include other data structures, each storing information related to one or more sets of resolution parameters. These data structures may be stored in a computer-readable storage medium associated with a client computing device that may request name resolution. It should be understood that the data structures shown in fig. 2A and 2B, and the parameters they store, are merely illustrative of the types of data structures and parameters that may be used, as any one or more types of networking technologies may be used.

FIG. 2A illustrates a first data structure storing a set 200A of resolution parameters, with two exemplary sets of resolution parameters. As shown in FIG. 2A, in some implementations, the set of resolution parameters may be organized as a table including a plurality of fields and rows, each field specifying a type of resolution parameter and each row specifying a set of resolution parameters, although other implementations are possible as any suitable format may be used. The illustrative resolution parameters shown in collection 200A include parameters related to the DNS resolution process, such as whether to use the DNSSEC protocol and whether or how to implement other DNS security parameters. However, as noted above, it should be understood that DNS is merely an example of the types of name resolution techniques and protocols with which the principles described herein may operate, and that any suitable name resolution protocol may be used.

The first illustrative resolution parameter shown in FIG. 2A is a "name" parameter 202. The parameters 202 indicate which identifiers, and thus which network resource(s), a set of resolution parameters applies to. The name parameters 202 may be used by the resolution module to determine which set(s) of resolution parameters in the collection apply to a given resolution process for an input identifier. The name parameter 202 may store any identifier of the network resource, including any numeric or textual identifier. For example, the numeric identifier may be an identifier of a particular network resource, such as an IP address of "1.2.3.4", or may be an identifier of a range of network resources, such as an IP address subnet of "157.0.0.0/8". Similarly, the textual identifier available for the name parameter may be an identifier of a particular network resource, such as a Fully Qualified Domain Name (FQDN) like "itweb.

The next resolution parameter shown in fig. 2A is the DNSSEC parameter 204. More specifically, the exemplary "DNSSEC" parameter stores a binary value (on or off) indicating that DNSSEC validation is required during the resolution process for the network resource that matches the name parameter. When the DNSSEC parameter 204 of a set of resolution parameters is set to on/true, the resolution resource may perform the resolution process according to the DNSSEC protocol and may ensure that any results are verified according to the resolution parameters. The resolution module performing the resolution process may also ensure that any results of the DNS query have been validated according to the DNSSEC standard, and may indicate in the sent DNS request that DNSSEC validation has been requested, for example, by setting a "DNSSEC OK" (DO) flag in the header of the request.

The security of the DNS exchange between the following parameters and the computing device, e.g. between the DNS client and the DNS server or any other group of devices. The first parameter, the "DNS over IPsec" parameter 206, may store a binary (on/off or true/false) value indicating whether IPsec is implemented on the communication channel used for the name resolution process. For example, if the IPsec parameter is set to true, the resolution module may perform encryption and/or authentication procedures when establishing a connection to the name resolution resource. If "DNS over IPSec" for a set of resolution parameters is set to on/true, the resolution module can check the other parameters of the set to determine the settings for the IPSec protocol. The next two parameters, "IPsec encryption level" 208 and "IPsec CA" 210 are examples of such parameters. The "IPsec encryption level" may store any value that specifies whether encryption should be used and/or what type of encryption should be used. The "IPsec encryption level" parameter 208 may store a no/low/medium/high value indicating a particular encryption type, e.g., "low" may indicate triple data encryption standard (3DES) or Advanced Encryption Standard (AES) encryption of any size, while "high" may indicate AES encryption of 192 or 256 bits. Alternatively, the IPsec encryption level may store a reference to a particular encryption standard, such as AES (256). "IPsec CA" 210 may store identifiers of one or more certifying authorities that are trusted to issue authentication certificates for resolving resources. During the authentication process of IPsec, when set up, the resolution module may confirm that the resolution result was authenticated using an authentication certificate issued by one of the trusted CAs to the trusted resolution resource. Additionally, if DNSSEC is opened, the response from the DNS server is checked to determine if the Extended Key Usage (EKU) signature in the response is from one of the trusted CAs and thus to determine that the DNS server that produced the result is authorized by the resolution parameters to perform DNSSEC attestation on behalf of the computing device.

The last parameter shown in FIG. 2A, namely "DNS Server" 212, can store a list of one or more DNS servers with which the resolution module should communicate during the resolution process. When an identifier entered into the resolution module matches a name parameter of a set of resolution parameters, then the resolution module will query any DNS server listed in the "DNS server" parameter for the identifier corresponding to the entered identifier. The "DNS server" parameter may store any suitable identifier, including any suitable numeric and/or textual identifier, of one or more DNS servers that may be used to establish a connection to the DNS server.

FIG. 2A shows two illustrative data structures that store sets of resolution parameters that may form a collection 200A, each set including illustrative values that may be stored as parameters for the collection. It should be understood that these groups are examples of the types of groups that may be used, and that any value may be used as a parameter and any number of sets of parameters may be used.

FIG. 2B illustrates a second exemplary data structure storing a set of resolution parameters 200B. As in FIG. 2A, the collection 200B is organized as a table having a plurality of fields identifying parameters and a plurality of rows identifying sets of resolution parameters, but it should be understood that any format may be used. Further, in the example of FIG. 2B, the resolution parameters include those that may be used in conjunction with Microsoft direct Access functionality for overlay networks. However, it should be understood that direct access is merely exemplary of the types of networking technologies and protocols with which the principles described herein may operate, and that any suitable networking technology may be used, including any suitable overlay networking technology.

The first parameter shown in FIG. 2B is the "name" parameter 220. Similar to the name parameter 202 of the collection 200A, this parameter identifies the network resource to which a set of resolution parameters are applicable, and may be used by the resolution module to determine which set(s) of resolution parameters in the collection apply to a given resolution process for an input identifier. The name parameter 220 may store any identifier of the network resource, including any numeric or textual identifier, including any of the exemplary parameters described above in connection with the collection 200A.

The next parameters in fig. 2B relate to the direct access technique. The "zone-specific DNS server" parameter 222 may store any suitable identifier for one or more DNS servers that may be queried as part of a name resolution process for network resources available on the overlay network. As described above, in some overlay networks, certain network resources may not be generally accessible to all computing devices on the hardware network on which the overlay network resides, and this limitation may be enforced in part by not widely distributing identifiers of network resources. To obtain an identifier for a network resource on the overlay network, the resolution module may then contact one or a small set of resolution resources. Thus, if the identifier entered into the resolution module matches the name parameter 220 of a set of resolution parameters, the resolution module may contact the DNS server specified in the "zone specific DNS Server" parameter 222 to obtain the corresponding identifier of the network resource.

The "regional specific agent" 224 is the next parameter shown. This parameter 224 may be used by the parsing module to indicate to the software application that the software application is contacting a network resource on the overlay network and configure the software application to perform its connection using a proxy server or to perform its connection using an identified proxy server. For example, if the software application desires a connection to a particular network resource and the set of applicable resolution parameters indicates to the resolution module that a proxy server should be used, the resolution module may indicate to the software application that it should connect to the network resource via the proxy server. The proxy server parameter 224 of the collection 200B may store any acceptable value, including a numeric and/or textual identifier of the resource, a null or other indicator that a proxy server is not required, or a value indicating that a default proxy server setting should be used by the software application.

The next parameter, "remote DNS over IPsec" 226 is used to indicate whether a connection to a network resource on the overlay network should be protected according to the IPsec protocol, e.g., using encryption and/or authentication. As with the "DNS through IPsec" parameter 206 of set 200A, the "DNS through IPsec" parameter 226 of set 200B may take binary values, such as on/off or true/false, indicating whether IPsec is used. Also similar to the collection 200A, "remote DNS encryption level" 228 may store any suitable value indicating whether and what type of encryption should be used in securing a connection to a resolution resource, and "IPsec CA" 230 may store any suitable identifier for one or more certificate authorities that are trusted to issue certificate certificates for resolution resources.

As with FIG. 2A, FIG. 2B also shows two illustrative data structures that store sets of resolution parameters that may form a collection 200B, each set including illustrative values that may be stored in the parameters of the collection. It should be understood that these groups are examples of the types of groups that may be used, and that any value may be used as a parameter and any number of sets of parameters may be used.

Further, it should be understood that although the two sets 200A and 200B are shown separately and with a view to two different technologies — DNS security/DNSSEC and direct access, it should be understood that in some implementations, a set of resolution parameters may include parameters for both technologies simultaneously and/or for any other type of networking technology. For example, for a given overlay network, the set of resolution parameters may instruct the resolution module to perform name resolution for the overlay network using DNSSEC and other DNS security measures.

In some techniques that operate according to the principles described herein, additional resolution parameters may be included in the set of resolution parameters, but these additional resolution parameters are not part of any particular set of resolution parameters. These global parameters may also be used to govern the resolution process, but may indicate when or whether any of the sets of resolution parameters are used, may indicate how failures in name resolution are handled, or may be resolution parameters that apply to all sets. For example, if the computing device supports Network Location Awareness (NLA) that can inform the computing device of the hardware network to which it is connected, the set can include an indication of whether to forgo review of all or a portion of the table based on the type or identity of the network to which the device is connected. For example, if the NLA indicates that the computing device is not connected to a particular hardware network on which an overlay network exists, the "NLA bypass" parameter may indicate to the parsing module that it should forgo reviewing all settings for the overlay network, or may indicate that it should forgo reviewing all sets of parsing parameters for a particular overlay network.

Additionally or alternatively, a global parameter may indicate how to issue a resolution request when located outside of a particular network. For example, if the computing device is outside of a particular hardware network, the "query behavior" parameter may indicate that the parsing module should query for a particular type of identifier, such as an IPv6 numeric identifier followed by an IPv4 numeric identifier, or an IPv6 numeric identifier only. Another global parameter may relate to how to react if the name resolution process fails, in that the second identifier is not located according to the applicable set of resolution parameters. The "exit behavior" parameter may indicate that the resolution module should attempt to use an alternative name resolution technique, or may indicate that exit is not allowed. For example, the parameter may indicate that if the DNS procedure fails, the LLMNR or NetBIOS procedure should be attempted.

These exemplary sets and resolution parameters, as well as any other suitable resolution parameters in any suitable set, may be used by a resolution module to perform a name resolution process according to any one or more types of name resolution techniques. Any suitable name resolution process may be implemented and governed by a suitable set of resolution parameters. Fig. 3 illustrates a process 300 that may be used to conduct name resolution. However, it should be understood that process 300 is merely exemplary of the types of techniques that may be implemented and that any suitable technique may be used.

The process 300 begins in block 302 where a functional module of a computing device receives a first identifier of a network resource. The first identifier may be received by and from any suitable source, including from a user via a suitable user interface, including by a user interface of a software application. The first identifier may be any suitable identifier of the network resource, including any suitable textual identifier according to a name resolution protocol, such as a domain name of the DNS protocol. The first identifier may then be passed to a name resolution module to determine a second identifier for the network resource at block 304. This may be done for any reason. For example, if the first identifier is a textual identifier received by the software application, the software application may determine that it requires a numeric identifier of the network resource as the second identifier to establish the connection to the network resource. However, this use case is merely an example, as the principles described herein are compatible with name resolution procedures performed with any suitable motivation.

At block 306, the resolution module determines whether the set has any resolution parameter sets applicable to the identifier for which name resolution is sought. This may be done in any suitable manner. For example, the resolution module may retrieve a set of sets of resolution parameters from the data store and compare the first identifier to the set to determine which, if any, of the sets of resolution parameters apply to the first identifier. This comparison may be accomplished in any manner, such as by comparing the first identifier to the "name" parameter described above in fig. 2A and 2B. The resolution module may then determine that one or more of the sets of resolution parameters are appropriate for the name resolution process to be performed by the module, and may either use the appropriate set of resolution parameters to govern the process, or determine an appropriate set of resolution parameters by combining the sets of resolution parameters in any suitable manner.

The determination of a set of applicable resolution parameters by block 306 may be made in any suitable manner. The exact manner in which this step is performed may depend on the format of the collection and on the resolution parameters selected for inclusion in the collection. Fig. 4 shows one example of a determination process, but it should be understood that process 400 is merely illustrative of actions that may be performed as part of block 306 of process 300, and that other processes are possible.

The process 400 begins at block 402 where the parsing module accesses sets of parsing parameters from a data store. The data store may be local to the computing device on which the parsing module executes, as in the example of fig. 1, or it may be available to the computing device via any suitable communication medium or media, such as a computer communication network. At block 404, the resolution module may retrieve, for each set of resolution parameters in the set, a pattern of matching identifiers indicating which identifiers of network resources each set applies to. The pattern may be any suitable indicator of network resources, including the name parameter or any other numerical or textual indicator described above in connection with fig. 2A and 2B. At block 406, the first identifier is compared to each pattern to determine whether the set of resolution parameters corresponding to the pattern applies to the first identifier. For example, if the first identifier is "webserver.

At block 407, once the applicable set(s) of resolution parameters are determined, parameters to be used to govern the name resolution process are retrieved in the set(s). In some implementations, only a single set of resolution parameters will be retrieved as a set of applicable resolution parameters, while in other implementations, multiple sets of resolution parameters may be retrieved. If multiple sets are obtained, any suitable process may be used to determine the applicable set of resolution parameters from the sets of resolution parameters. For example, the parameters may be combined to determine a set of applicable resolution parameters having a highest security level, or a lowest security level, or any other suitable criteria. As another example, if multiple sets of resolution parameters match, the resolution module may select the set with the most closely matching patterns. For example, if the first identifier is "a.corp.ms.com" and there is a group corresponding to "corp.ms.com" and a group corresponding to "ms.com" in the set, then a group of resolution parameters corresponding to "corp.ms.com" may be selected as it is more specific.

Returning to process 300 of FIG. 3, at block 308, once the applicable set of resolution parameters is determined, the resolution module may perform a name resolution process parameterized with the applicable set of resolution parameters. The resolution module may then obtain a second identifier of the network resource as an output of the resolution process. For example, if the first identifier is a textual identifier, the second identifier may be a numeric identifier such as an IP address, or vice versa. The resolution module may then return the second identifier to the function module that passed the first identifier to it at block 302, and the process ends, at block 310.

The acts of blocks 308 and 310 may be performed in any suitable manner. FIG. 5 illustrates an exemplary process 500 that may be used to perform a name resolution process parameterized with a set of applicable resolution parameters. However, it should be understood that process 500 is merely illustrative of the types of name resolution processes that may be implemented and that any suitable process may be implemented in accordance with any suitable name resolution techniques and protocols. It should also be appreciated that although process 500 is described in terms of specific resolution parameters, these parameters are also merely exemplary and any suitable parameters may be used in accordance with the principles described herein.

The process 500 of FIG. 5 begins at block 502, where the resolution module establishes a connection to a name resolution resource identified by an applicable set of resolution parameters, such as identified by a "DNS Server" parameter. The nature of the resolution resources may vary depending on the type or types of name resolution techniques and protocols implemented. However, in some implementations, the name resolution resource may be a network resource such as a DNS server. In block 504, a connection to the resolution resource may be protected according to the "DNS over IPsec" parameter set to on/true. The security of the connection may depend on other parameters, such as an "encryption level" parameter identifying the type of encryption to be used and/or an "IPsec CA" parameter identifying one or more certificate authorities that may issue certificates authenticating the identity of the resolution resource. Techniques for securing a communication connection using the IPsec protocol are well known in the art and will not be discussed in further detail herein.

At block 506, once the connection to the resolution resource is secured, the resolution module may communicate a name resolution request over the channel. The resolution request may include any suitable data for performing name resolution, including the first identifier and any parameters indicating procedures that the resolution resource may need to follow. For example, the resolution request may indicate that DNSSEC has been enabled for the resolution request according to some parameter of the applicable set of resolution parameters, and the resolution resource should perform a validation process on the second identifier according to DNSSEC before returning the second identifier. For example, the resolution request may include one or more indicators of one or more certification authorities that are trusted to return trusted results indicated by the set of resolution parameters, and the resolution resource may confirm that one of the certification authorities is used.

Depending on the particular name resolution technique selected and indicated by the resolution parameter, the resolution resource may perform any suitable technique to obtain the second identifier for the network resource. For example, if the resolution resource is a DNS server, the resolution resource may check its local identifier cache to determine if it "knows" the second identifier that corresponds to the first identifier received in the resolution request. If the second identifier is not in its cache, it may transmit the resolution request to another DNS server, which may then perform the same process. This will continue until the original resolution resource receives a response that includes the second identifier. If the set of applicable resolution parameters indicates that DNSSEC is "ON", when the resolution resource obtains a result, either from its own cache or from another DNS server, the resolution resource can check the result to determine if it has been "signed" by a trusted source that can guarantee the legitimacy of the result. If the result is determined to be valid, it may be returned to the parsing module that issued the parsing request.

At block 508, the resolution module receives a response from the resolution resource over the secure channel, and at block 510, confirms that the second identifier was certified by the resolution resource and signed by a trusted certificate authority. At block 512, based on the determination of block 510, the resolution module determines whether the identifier is validated according to the set of applicable resolution parameters. If the second identifier is validated, at block 514, the second identifier is returned to the functional module that originally issued the request by providing the first identifier (as in block 302 of FIG. 3), and the process ends. On the other hand, if the response is not validated according to the set of applicable resolution parameters, then at block 516 the resolution module processes the result and returns an error message to the functional module indicating that no result was found, and the process ends.

In some implementations, the resolution module may also maintain a local high-speed store of identifiers for network resources. The resolution module, upon receiving a response to the resolution request that includes the second identifier, may store the first identifier, the second identifier, and resolution parameters for obtaining the second identifier in a cache. Then, when the resolution module receives a new request for the second identifier, the resolution module may check the cache to determine whether it already stores the second identifier, and if so, may return the second identifier from the cache without issuing a resolution request to the resolution resource. FIG. 6 illustrates an exemplary process 600 for performing a resolution process using a cache. However, it should be understood that process 600 is merely illustrative and that any suitable technique may be implemented in accordance with the principles described herein.

The process 600 begins at block 602 where a resolution module receives a first identifier and determines a set of applicable resolution parameters. This may be accomplished in any suitable manner, including by any of the exemplary techniques described above. At block 604, the resolution module may check the cache to determine whether the first identifier is listed in the cache. If the first identifier is not in the cache based on the determination of block 606, the name resolution process continues as described above at block 608. When the second identifier is obtained through the name resolution process, then information describing the obtaining action may be stored in a cache at block 610. The information may include any of various types of data and instructions regarding the acquisition process. For example, the information may include the first identifier, the second identifier, and/or the set of applicable resolution parameters used in the act of obtaining. Once the information is stored in the cache, process 600 ends.

On the other hand, if it is determined at block 606 that the first identifier is in the cache, at block 612, the set of resolution parameters stored in the cache with the first identifier is retrieved and compared to the set of applicable resolution parameters retrieved at block 602. This comparison may be done to ensure that any second identifier returned from the cache is an identifier obtained from the set of applicable resolution parameters. For example, the comparison of block 612 may determine that the parameters are equal, or that the parameters used to obtain the identifier stored in the cache are at least as secure as the parameters retrieved in block 602. Alternatively, the comparison of block 612 may determine that the source of the second identifier in the cache, the resolution resource from which the second identifier was obtained, is the same as the source required for the set of applicable resolution parameters. As another example, the cache may instead store the time at which the second identifier was retrieved, and the resolution module may compare this to the last time the resolution parameter was edited to determine if the resolution parameter was the same at execution time as when the identifier in the cache was retrieved. Any suitable comparison process may be performed at block 612.

At block 614, if the parameters do not match, a name resolution process is performed according to the set of applicable resolution parameters as described above to ensure that any identifiers obtained are properly obtained. If, however, it is determined at block 614 that the parameters match, then at block 616, the second identifier is returned from the cache to the functional module that provided the first parameter, and the process 600 ends.

The foregoing are several different techniques for determining a second identifier based on a first identifier input to a resolution module by a function module. It should be understood, however, that each of these techniques is merely illustrative of the type of techniques that can be implemented in accordance with the principles described herein. Any one or more types of methods may be implemented to perform the name resolution process to determine an identifier of a network resource based on a name resolution technique, whether implemented as a hardware network or an overlay network, or may be based on resolution parameters provisioned for a resolution module.

The resolution parameters supplied for the resolution module may be supplied in any suitable manner. For example, in one implementation, the resolution parameters may be entered locally by a user of the computing device and stored in a data store associated with the computing device. In another implementation, the resolution parameters may be provided over a network when the computing device is connected to the network. FIG. 7 illustrates an example of one such latter process for providing resolution parameters to a computing device via a network. However, it should be understood that process 700 of fig. 7 is merely illustrative and that other processes are possible. Further, it should be understood that although the example of FIG. 7 is described in terms of a Microsoft Windows computer network, other networks are possible in which the computing device is configured by the network when connected to the network.

The process 700 begins at block 702 where an administrator enters a set of resolution parameters into a domain controller of a network. The set of resolution parameters may be entered in any suitable manner, including as part of a Microsoft active directory group policy for a network. The group policy may apply to any portion of the network, including to a group of computing devices connected to the network and/or to a group of users of the network. At block 704, the domain controller receives the resolution parameters and stores them as a group policy, which is then sent to all members of the group. This transmission of block 704 may occur after a set period of time, such as every 15 seconds, or when a member of the group (either a computer or a user) joins or logs into the network. At block 706, the computing device executing the parsing module described herein receives the group policy in any suitable manner and stores it in a data store associated with the computing device. Then, at block 708, when the name resolution process is performed, the resolution module applies the set of resolution modules to the name resolution process in any suitable manner, including any of the exemplary techniques described above.

The resolution parameters may be entered using any suitable user interface. For example, in some implementations, a text-based command line tool may be used to input the parsing parameters. In other implementations, the resolution parameters may be entered using a graphical user interface. Fig. 8 illustrates an example of one such graphical user interface that may be used in accordance with some of the principles described herein. However, it should be understood that some implementations may use alternative user interfaces, and embodiments of the invention are not limited to using any particular input technique for the resolution parameters.

Graphical user interface 800 includes a plurality of controls that may be used to input resolution parameters. Textbox 802 may be used to enter the name of the network resource, including the schema to be used to match the name of the network resource, as in the "name" parameter described above in connection with fig. 2A and 2B. The graphical user interface may also include entering information relating to a certificate authority that may be used for IPsec security procedures and/or for signing the identifier according to a security name resolution technique like DNSSEC. A series of controls 806 relating to DNS security may also be implemented with controls indicating parameters such as whether DNSSEC validation is required, whether IPsec is used, and what type of encryption is used if IPsec is used. Another series of controls 808 may also be implemented for use with an overlay network, such as direct access, accepting parameters such as an identifier of an acceptable resolution resource, such as a DNS server, an identifier of a proxy server to use, whether IPsec is to be used, and what type of encryption is to be used if IPsec is to be implemented. Graphical user interface 800 also includes a button 810 for creating and updating a set of parsing parameters, including the parameters entered in each of controls 802 and 808. Other global resolution parameters may also be input to the graphical interface via the framework 812. Once a set of resolution parameters is created, the set of parameters may be displayed in a frame 814 at the bottom of graphical user interface 800, the frame having a plurality of columns that align to the types of parameters that may be entered using interface 800.

When a set of parameters is created or updated using graphical user interface 800, the set of parameters may be stored in any suitable data structure in any suitable format. The data structure may be stored in a data structure that stores sets of resolution parameters, such as sets 200A and 200B of FIGS. 2A and 2B. As discussed above, these data structures may be encoded on any suitable computer storage medium. Thus, when a user enters parameters using the graphical user interface 800, the graphical user interface 800 may initiate a recording process to record the entered parameters onto a computer-readable medium in any suitable manner.

The techniques operating according to some or all of the principles described herein may be implemented in any manner. For example, in some implementations, the techniques may be implemented as computer-executable instructions encoded on one or more computer-readable storage media, such as magnetic media (e.g., a hard disk drive), a Compact Disc (CD), a Digital Versatile Disc (DVD), persistent or non-persistent solid-state memory (e.g., flash memory, magnetic RAM, etc.), or any other suitable storage media. The computer storage medium may be implemented as computer-readable storage medium 906 of fig. 9 (i.e., as part of computing device 900) or as a separate computer storage medium. It should be understood that "computer-readable medium," which as used herein includes "computer-readable storage medium," refers to a tangible storage medium having at least one physical structure that can be altered in some manner during the process of recording data thereon. For example, the magnetization state of a portion of the physical structure of the computer readable medium may be altered during the recording process.

In some such embodiments, computer-executable instructions implementing techniques that operate according to principles described herein may be implemented as one or more separate functional modules (e.g., a parsing module as described above). As described above, a "functional module" is a structural component of a system that performs a particular operational role, however, after instantiation, a functional module can be a portion of an entire software element or an entire software element (e.g., a function or discrete process). Generally, functional modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the functional modules may be combined or distributed as desired in various embodiments. These functional modules may be adapted in some implementations to interact with other, unrelated functional modules and/or processes, such as those implementing a software program application or implementing an operating system for a computing device, or in other implementations to interact with other functional modules that together with these modules form an overall system such as an operating system, such as the microsoft Windows operating system available from microsoft corporation of redmond, washington (i.e., these functional modules may be implemented as part of, or external to, an operating system). It should also be understood that in some implementations, some functional modules may be implemented separately from other functional modules, or some functional modules may not be implemented.

In some, but not all implementations, the techniques may be embodied as computer-executable instructions that are executable on any suitable computing device operating in any suitable computer system, including the exemplary computer system of fig. 1. For example, techniques that operate according to some or all of the principles discussed herein may operate on the following systems: a single multi-purpose programmable digital computer device, a coordination system of two or more multi-purpose computer devices that share processing power and jointly perform the techniques described herein, a coordination system of a single computer device or computer devices (co-located or geographically distributed) dedicated to performing the techniques described herein, one or more Application Specific Integrated Circuits (ASICs) for performing the techniques described herein, one or more Field Programmable Gate Arrays (FPGAs) for performing the techniques described herein, or any other suitable system.

Fig. 9 illustrates one exemplary implementation of a computing device in the form of a computing device 900 that may be used in a system implementing the techniques described herein, although other implementations are possible. Moreover, it should be understood that FIG. 9 is intended to be neither a depiction of necessary components for a computing device to operate in accordance with the principles described herein, nor a comprehensive depiction.

Computing device 900 may include a processor 902, a network adapter 904, and a computer-readable storage medium 906. Computing device 900 may be, for example, a desktop or laptop personal computer, a workstation, a server, a mainframe, a smartphone, or any other suitable computing device. Network adapter 904 may be any suitable hardware and/or software that enables computing device 900 to communicate with any other suitable computing device over any suitable computing network. The computing network may be any suitable wired and/or wireless communication medium or media for exchanging data between two or more computers, including the internet. In some implementations, the network adapter 904 can be implemented as two or more separate network adapters to provide connectivity via two or more types of interfaces (e.g., a wired network adapter such as an ethernet adapter and a wireless network adapter such as an IEEE 802.11g adapter). The computer-readable storage medium 906 may be any suitable tangible storage medium suitable for storing data to be processed by the processor 902 and/or instructions to be executed by the processor 902. The processor 902 is capable of processing data and executing instructions. These data and instructions may be stored on computer-readable storage media 906 and may enable communication between components of computing device 900, for example.

The data and instructions stored on the computer-readable storage media 906 may include computer-executable instructions to implement techniques that operate according to the principles described herein. In the example of fig. 9, computer-readable storage media 906 stores computer-executable instructions that implement various modules and store various information, as described above. Computer-readable storage media 906 stores data and instructions related to one or more application programs 908 that may be executed on the computing device. The applications may include applications that may accept a first identifier of a network resource and attempt to obtain a second identifier of the network resource. The computer-readable storage media 906 may also include a name resolution module 910 for determining a second identifier for the network resource based on the first identifier according to any suitable technique, including any of the exemplary techniques described above. The computer-readable storage medium 906 also includes sets 912 of resolution parameters. As discussed above, the collection may be organized and formatted in any suitable manner, and the resolution parameters may include any suitable parameters for governing the execution of the name resolution process of the name resolution module 910. In one implementation, for example, the collection 912 may be implemented on the computer-readable storage media 906 as part of a registry of the Microsoft Windows operating system. The computer-readable storage media 906 additionally may include a cache 914 of identifiers that have been retrieved by the name resolution module 910. The cache may be organized in any suitable manner and may contain any suitable one or more types of information, including sets of first and second identifiers for network resources, sets of resolution parameters for obtaining identifiers, times at which identifiers were obtained, and/or any other one or more types of information.

Finally, in the example of fig. 9, the computer-readable storage medium 906 may include a set of Application Programming Interface (API) functions that implement the set of sets of resolution parameters and determine the contents of the set. For example, the API may implement a GetProxyInfo (get proxy information) function to determine a proxy that may be used to contact a particular network resource, take an identifier of the network resource as input. The GetProxyInfo function may use the input identifier for the resource to locate one or more sets of resolution parameters in the set that are applicable to the network resource, and may then return an identifier for the proxy server when any of the sets of resolution parameters indicates that the proxy server is to be used. A getpolicy tablelnfo (get policy table information) API function may also be implemented to return the contents of the collection (i.e., the sets of resolution parameters). Furthermore, the GetEffectivePolicy API function may return some (or all) of the sets of resolution parameters in the collection depending on which resolution parameters are not applicable for a given scenario. For example, if some of the sets of resolution parameters apply to a particular network and computing device 900 is not connected to that network, the sets may not be returned as part of the output of the geteffectivolicy function. In addition, a GetAddrInfo (get address information) or DNS query function may be implemented that takes the first parameter as input and performs a name resolution process governed by a set of sets of resolution parameters to determine the second identifier and return the second identifier. It should be appreciated that these API functions are merely examples of the types of API functions that may be implemented and that embodiments of the present invention are not limited in this respect.

Modules implementing techniques that operate according to principles described herein may interact in any suitable manner. FIG. 10 illustrates an exemplary arrangement of modules that may be implemented in accordance with some principles described herein.

In the example of fig. 10, application 1000 interacts with one or both of connection module 1002 and name resolution module 1004 to determine a second identifier corresponding to the first identifier. For example, application 1000 may query name resolution module 1004 directly, or application 1000 may attempt to open a connection to a network resource with connection module 1002 using a first identifier, and the connection module may request a second identifier from the name resolution module for use when opening the connection. The name resolution module 1004, in attempting to obtain the second identifier, may use the sets 1006 of resolution parameters as described above, and may also use the cache 1008 of identifiers as described above. Finally, when using the set of resolution parameters 1006 to obtain the second identifier, the name resolution module 1004 may also use various connection techniques 1010, including using the connection module 1012 to open a connection to the resolution resource, and using the authentication module 1014 and/or the encryption module 1016 to perform any security procedures that may be specified by the resolution parameters in the set.

Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art.

Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

Also, the invention may be embodied as a method, examples of which have been provided. The actions performed as part of the method may be ordered in any suitable way. Thus, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

Use of ordinal terms such as "first," "second," "third," etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of "including," "comprising," "having," "containing," "involving," and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

Claims

1. A method of name resolution, comprising:

(A) accepting as input a first identifier of a network resource;

(B) consulting a set of sets of resolution parameters to determine a set of applicable resolution parameters applicable to the first identifier, the set of applicable resolution parameters governing communications between a host computing device and a remote computing device to which the host computing device issues a name resolution request, wherein consulting the set of sets of resolution parameters comprises:

(B1) comparing a first identifier of the network resource to a pattern associated with each of the sets of resolution parameters to determine whether each set of resolution parameters applies to the first identifier; and

(C) obtaining a second identifier of the network resource from the remote computing device, the obtaining comprising conducting a name resolution process to determine the second identifier of the network resource based on the first identifier, wherein the name resolution process is governed by the set of applicable resolution parameters.

2. The method of claim 1, wherein the obtaining further comprises:

(C1) sending a name resolution request to the remote computing device based on the set of applicable resolution parameters.

3. The method of claim 1, wherein the first identifier is a textual identifier of the network resource and the second identifier is a numeric identifier of the network resource.

4. The method of claim 1, wherein the resolution parameters include information regarding one or more types of encryption to be used.

5. The method of claim 1, wherein the resolution parameters include identifiers of one or more network resources with which information is to be exchanged during the name resolution process.

6. The method of claim 1, wherein the name resolution process is a process according to the domain name system, DNS, protocol.

7. The method of claim 6, wherein the name resolution process is a process according to the DNS security extensions, DNSSEC, protocol.

8. The method of claim 6, wherein the name resolution process is adapted to work with an overlay network implemented using direct access.

9. A method of name resolution, the method comprising:

(A) accepting as input from an application a domain name of a network resource accessible via a network;

(B) determining a set of applicable resolution parameters from a set of sets of resolution parameters, wherein determining the set of applicable resolution parameters from the set of resolution parameters comprises comparing a domain name of the network resource to a pattern associated with each of the sets of resolution parameters to determine whether the set of resolution parameters applies to the domain name;

(C) establishing a connection to a Domain Name Service (DNS) server on the network according to the set of applicable resolution parameters;

(D) communicating a DNS query to the DNS server according to the set of applicable resolution parameters;

(E) receiving a response from the DNS server comprising a numeric identifier of the network resource; and

(F) providing the numerical identifier to the application.

10. The method of claim 9, wherein the act of establishing a connection to a DNS server comprises: establishing a connection to the DNS server identified by the set of applicable resolution parameters.

11. The method of claim 9, wherein the method further comprises:

confirming that the response was generated according to the parsing parameters; and

if the response is not generated from the resolution parameters, the numeric identifier is not provided to the application.

12. The method of claim 9, wherein validating that the response was generated according to the resolution parameters comprises determining whether the response was verified according to the DNS security extensions, DNSSEC, protocol.

13. The method of claim 12, wherein communicating the DNS query to the DNS server in accordance with the set of applicable resolution parameters comprises encrypting communications in accordance with an encryption technique identified by the set of applicable resolution parameters.

14. The method of claim 9, wherein the method further comprises:

storing the response and the set of applicable resolution parameters for retrieving the response in a cache; and

after receiving the domain name as a second input as part of a second request for the numeric identifier, determining whether the set of applicable resolution parameters for retrieving the response is sufficient to provide a response to the second request, and if so, providing the response from the cache.

15. The method of claim 9, wherein the act (F) further comprises:

(F1) providing an identifier of a proxy server for the network resource to the application.