Passive delegations and records

BACKGROUND

In a computer network such as the Internet, users can identify web servers, email servers, or other resources by alphanumerical domain names. However, routers, switches, and other network services or devices identify such resources by numerical IP addresses. A domain name system facilitates operations of such computer networks by providing a translation service between the alphanumeric domain names and numerical IP addresses. For example, a domain nameserver can translate the domain name “www.example.com” to the IP address “192.168.0.1.” Routers, switches, or other computer services or devices can then access resources associated with this domain name based on the IP address.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In a domain name system, authoritative servers are specifically configured to provide authoritative translations of domain names. Multiple authoritative servers typically operate concurrently for a domain name to provide redundancy, load balancing, and/or other suitable functions. Such an arrangement allows operation of the domain name system as long as at least one authoritative server is reachable. However, the foregoing arrangement does not provide any contingency when none of the authoritative servers is reachable. Several embodiments of the disclosed technology can provide such backup capabilities to the DNS system by implementing standby authoritative servers that are only accessed when none of the concurrent authoritative servers are reachable, or when a number of reachable concurrent authoritative servers falls below a predetermined threshold (e.g., one, two, etc.).

Several embodiments of the disclosed technology can increase reliability of a DNS system by providing contingent backup capability. Even when all of the concurrent authoritative servers are unreachable, the standby authoritative server(s) can still facilitate continued operation of the DNS system by providing at least basic name resolution capabilities. Also, such standby authoritative server(s) can be cost-efficient and simple to implement due to low functionality requirements. For instance, to provide only basic name resolution capabilities, the standby authoritative server(s) can be implemented on less costly servers than the concurrent authoritative servers. Such standby authoritative server(s) can also have low maintenance requirements by, for example, storing information that does not require constant updating. In addition, failover to such standby authoritative server(s) can be straightforward because standby authoritative server(s) can be idle during normal operation.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating computing frameworks having passive nameserver(s) in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIGS. 2A and 2B</figref> are schematic diagrams illustrating a portion of the computing framework during normal operation and emergency operation, respectively, in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIGS. 3A and 3B</figref> are block diagrams showing software components suitable for the level-1 nameserver of <figref idref="DRAWINGS">FIG. 1</figref> during normal operation and emergency operation, respectively, and in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIG. 4A</figref> is a schematic diagram illustration an example data structure suitable for the security query of <figref idref="DRAWINGS">FIG. 2A</figref> in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIG. 4B</figref> is a schematic diagram illustration an example data structure suitable for the question field of <figref idref="DRAWINGS">FIG. 4A</figref> in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIG. 4C</figref> is a schematic diagram illustration an example data structure suitable for the security record of <figref idref="DRAWINGS">FIG. 2B</figref> in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIGS. 5A-5E</figref> are flow diagrams illustrating embodiments of a process of providing backup capabilities to a DNS system in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIGS. 6A and 6B</figref> are example user interfaces useful for configuration of active/passive nameservers in accordance with embodiments of the disclosed technology.

<figref idref="DRAWINGS">FIG. 7</figref> is a computing device suitable for certain components of the computing frameworks in <figref idref="DRAWINGS">FIGS. 1-3B</figref>.

DETAILED DESCRIPTION

Certain embodiments of systems, devices, components, modules, routines, and processes for managing backup capability of domain name systems via passive nameserver delegations and records are described below. In the following description, specific details of components are included to provide a thorough understanding of certain embodiments of the disclosed technology. A person skilled in the relevant art will also understand that the disclosed technology may have additional embodiments or may be practiced without several of the details of the embodiments described below with reference to <figref idref="DRAWINGS">FIGS. 1-7</figref>.

As used herein, the term “domain name system” or “DNS” generally refers to a computer system configured to translate alphanumerical domain names into numerical IP addresses to effect communications in a computer network. In the following description, such translation can be referred to as “name resolution” or “resolving a domain name.” A domain name system can include one or more operatively coupled DNS servers containing a database of domain name translations. Example DNS servers can include authoritative servers and caching servers organized into a hierarchy. One example DNS computing framework is described below with reference to <figref idref="DRAWINGS">FIG. 1</figref>.

An “authoritative server” generally refers to a DNS server configured to return authoritative domain name translations for particular domain names in response to DNS queries. For example, an authoritative server can contain a mapping of URLs of domain names to IP addresses defined by domain administrators or other authorized entities. In another example, an authoritative server can also contain a mapping of a host portion of email addresses (e.g., “@hotmail.com”) to IP addresses. In a further example, an authoritative server can also contain name server (“NS”) records of other authoritative servers to which resolution authority is delegated. Authoritative servers for a domain or host may be configured by DNS hosting companies or network registrars, such as, for example, Amazon, GoDaddy, or Verisign.

A “caching server” generally refers to a DNS server configured to resolve a domain name of a target domain by, for example, recursively querying authoritative servers. For instance, each part of the URL “www.example.com” has a specific DNS server (or group of servers) that is authoritative. A root server can contain network addresses of authoritative servers for top-level domains such as “.com,” “.net,” or “.org.” In one example resolution operation, a caching server can first query the root server for network addresses of authoritative servers for the “.com” domain. Then, the caching server queries the “.com” authoritative server for network addresses of authoritative servers for “example.com” domain. The caching server can then query the authoritative servers for the “example.com” domain for an IP address associated with the domain name “www.example.com.”

Also used herein, the term a “DNS query” generally refers to an electronic data package representing a request from, e.g., a caching server to an authoritative server for retrieving DNS records. For example, an A-type DNS query is a request for retrieving a 32-bit IPv4 address of a target domain name. An AAAA-type DNS query is a request for retrieving a 128-bit IPv6 address of a target domain name. In accordance with embodiments of the disclosed technology, an name server (“NS”)-type query can be a request for retrieving an NS record that can include URLs of active and passive authoritative servers for a target domain name.

As used herein, an “active authoritative server” or “active nameserver” generally refers to a working authoritative server configured to provide name resolution and/or other suitable DNS functionalities on a generally continuous basis. In contrast, a “passive authoritative server” or “passive nameserver” generally refers to a standby authoritative server configured to be accessed for name resolution only upon certain conditions. In one example, a passive authoritative server can be accessed only when none of the associated active authoritative servers are reachable. In another example, a passive authoritative server can be accessed only when a number of reachable active authoritative servers falls below a threshold selected by an administrator or other suitable entities.

In accordance with embodiments of the disclosed technology, authoritative servers listed in an NS record can be divided into active and passive authoritative servers. In certain embodiments, active and passive authoritative servers can be identified by corresponding prefixes, suffixes, or other suitable indicators in associated URLs. For instance, a “.com” authoritative server can have example an NS record associated with the domain name “www.example.com” as follows:

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="49pt" align="center" /><colspec colname="4" colwidth="70pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Owner name</entry><entry>Class</entry><entry>Record type</entry><entry>Target Name</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>www.example.com</entry><entry>IN</entry><entry>NS</entry><entry>ns1.example.com</entry></row><row><entry>www.example.com</entry><entry>IN</entry><entry>NS</entry><entry>ns2.example.com</entry></row><row><entry>www.example.com</entry><entry>IN</entry><entry>NS</entry><entry>pns1.example.com</entry></row><row><entry>www.example.com</entry><entry>IN</entry><entry>NS</entry><entry>pns2.example.com</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>&lt;br /&gt; As shown above, each entry of the example NS record can include four fields: owner's name (i.e., “www.example.com”), class (i.e., “IN” indicating Internet), record type (i.e., “NS”), and target name (e.g., ns1.example.com). According to the above example NS records, active authoritative servers for the domain name “www.example.com” are located at URLs “ns1.example.com” and “ns2.example.com.” Corresponding passive authoritative servers are identified by the prefix “pns,” and are located at are located at URLs “pns1.example.com” and “pns2.example.com.”

In other embodiments, the active and passive authoritative servers can also be identified by a flag in, for example, the record type field. For instance, the foregoing NS record associated with the domain name “www.example.com” can be as follows:

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="56pt" align="center" /><colspec colname="4" colwidth="56pt" align="left" /><thead><row>&lt;entry /&gt;<entry namest="offset" nameend="4" align="center" rowsep="1" /></row><row>&lt;entry /&gt;<entry>Owner name</entry><entry>Class</entry><entry>Record type</entry><entry>Target Name</entry></row><row>&lt;entry /&gt;<entry namest="offset" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;<entry>www.example.com</entry><entry>IN</entry><entry>NS</entry><entry>ns1.example.com</entry></row><row>&lt;entry /&gt;<entry>www.example.com</entry><entry>IN</entry><entry>NS</entry><entry>ns2.example.com</entry></row><row>&lt;entry /&gt;<entry>www.example.com</entry><entry>IN</entry><entry>PNS</entry><entry>ns3.example.com</entry></row><row>&lt;entry /&gt;<entry>www.example.com</entry><entry>IN</entry><entry>PNS</entry><entry>ns4.example.com</entry></row><row>&lt;entry /&gt;<entry namest="offset" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>&lt;br /&gt; As shown above, authoritative servers “ns1.example.com” and “ns2.example.com” are indicated in the record type field as active authoritative servers with the indicator “NS.” Authoritative servers “ns3.example.com” and “ns4.example.com” are indicated in the record type field as passive authoritative servers with the indicator “PNS.” In further examples, The active and/or passive authoritative servers may be identified in the NS record with a flag in another field (e.g., active/passive field, not shown) or in other suitable manners.

A domain name system typically includes multiple authoritative servers and caching servers. The authoritative servers are configured to return specific domain name translations in response to DNS queries received from caching servers. Caching servers are configured to retrieve the translations from the authoritative servers and store (or “cache”) the retrieved translations for a period of time for responding to DNS queries from client devices. To resolve a domain name (e.g., “www.example.com”), a caching server can query a higher level server (e.g., a “.com” server) for an NS record that contains one or more URLs of delegated authoritative servers for the domain name. Based on the NS record, the caching server can locate the authoritative server(s) to retrieve a translation (e.g., IP address of “192.168.0.1”) corresponding to the domain name.

Typically, an NS record associated with a domain name include URLs of multiple authoritative servers for redundancy, load balancing, and/or other suitable functions. For instance, an NS record for the domain name “www.example.com” can include two, three, or four URLs of authoritative servers such as, for example, “ns1.example.com,” “ns2.example.com,” “ns3.example.com,” etc. A caching server can query all of these authoritative servers based on, for example, response times of previous queries to these authoritative servers. Thus, when “ns1.example.com” has a response time that is about the same as that of “ns2.example.com,” the caching server can query them generally evenly. In another example, when “ns1.example.com” has a response time lower than that of “ns2.example.com,” the caching server may query “ns1.example.com” more often than “ns2.example.com.” The foregoing arrangement of multiple authoritative servers, however, do not provide any backup capabilities when all of the authoritative servers are unreachable or otherwise inaccessible. For example, when none of “ns1.example.com” or “ns2.example.com” is accessible, the caching server may fail to provide a response to a DNS query for “www.example.com” unless a resource record is already cached.

Several embodiments of the disclosed technology can provide such backup capabilities to the DNS system by implementing passive authoritative servers that are only accessed when none (or a predetermined number) of active authoritative servers is reachable. For instance, as described above, an NS record for “www.example.com” can also include URLs of the passive authoritative servers “pns1.example.com” and “pns2.example.com.” During operation, a caching server queries active authoritative servers such as “ns1.example.com” or “ns2.example.com” when at least one of these active authoritative servers is available. The caching server can be configured to query passive authoritative server “pns1.example.com” or “pns2.example.com” only when a number of available active authoritative servers falls below a predetermined threshold. Thus, in certain implementations, passive server “pns1.example.com” is queried only when none of the active authoritative server is reachable.

Several embodiments of the disclosed technology can increase reliability of a DNS system by providing passive or emergency backup capabilities. For instance, even when all of the active authoritative servers are unreachable, the passive authoritative server(s) can still facilitate continued operation of computing systems and/or networks by providing at least basic name resolution capabilities. Also, passive authoritative server(s) can be simple to implement due to reduced functionality requirements. For instance, passive authoritative server(s) can be implemented to provide only basic name resolution capabilities without full functionalities of corresponding active authoritative servers. Thus, passive authoritative server “pns1.example.com” or “pns2.example.com” can be implemented on less costly servers and require less configuration than those for “ns1.example.com” or “ns2.example.com.” Further, passive authoritative server(s) can have low maintenance requirements by, for example, storing domain name translations or other suitable information that does not requiring constant or even periodic updating. In addition, failover to passive authoritative server(s) can be straightforward because passive authoritative server(s) are not accessed during normal operation.

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating a DNS computing framework <b>100</b> having advanced backup capability in accordance with embodiments of the disclosed technology. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the computing framework <b>100</b> can include a client device <b>102</b>, a caching server <b>112</b>, and one or more authoritative servers <b>130</b> interconnected by a computer network <b>107</b>. The computer network <b>107</b> can include the Internet, a local area network, a metropolitan area network, a wide area network, and/or other suitable types of network.

The client device <b>102</b>, the caching server <b>112</b>, and the authoritative servers <b>130</b> can each include a processor and memory (not shown) containing instructions for execution by the processor to provide certain software components discussed in more detail below. Even though particular components of the computing framework <b>100</b> are shown in <figref idref="DRAWINGS">FIG. 1</figref>, in other embodiments, the computing framework <b>100</b> can also include additional and/or different components. For example, the computing framework <b>100</b> can include additional caching servers <b>112</b>′ and <b>112</b>″, additional client devices <b>102</b>′ and <b>102</b>″, and/or other suitable components.

The client device <b>102</b> can include a desktop, a laptop, a tablet, a smartphone, and/or other suitable types of computing device. For example, the client device <b>102</b> can be an iPhone or iPad provided by Apple, Inc. of Cupertino, Calif., an Android device, a Chromebook device, a Windows device, or any other suitable devices. In the illustrated embodiment of <figref idref="DRAWINGS">FIG. 1</figref>, the client device <b>102</b> can include a name resolver <b>104</b> and a local DNS cache <b>106</b>. In other embodiments, the client device <b>102</b> may also include other suitable hardware and/or software components. The name resolver <b>104</b> can be configured to determine a network address (e.g., an IP address) associated with a domain name (e.g., “www.example.com”). The name resolver <b>104</b> may be a part of an operating system or an application executing on the client device <b>102</b>.

The local DNS cache <b>106</b> can be configured to store resource records of previously resolved domain names. In one embodiment, the name resolver <b>104</b> can determine an IP address by accessing a resource record stored in the local DNS cache <b>106</b>. In other embodiments, when a resource record does not exist in the local DNS cache <b>106</b>, the name resolver <b>104</b> can query the caching server <b>112</b> for the desired resource record <b>116</b> by, for example, transmitting a DNS query <b>108</b> to the caching server <b>112</b> and receiving a DNS response <b>110</b> from the caching server <b>112</b>.

The authoritative servers <b>130</b> can include a plurality of DNS servers arranged in a hierarchy. For example, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, the authoritative servers <b>130</b> can include a root nameserver <b>134</b>, a level-1 nameserver <b>136</b> subordinate to the root nameserver <b>134</b>, and a level-2 nameservers <b>138</b> subordinate to the level-1 nameserver <b>136</b>. Even though a three-level hierarchy of DNS servers <b>130</b> is shown in <figref idref="DRAWINGS">FIG. 1</figref>, in other embodiments, the authoritative servers <b>130</b> can include one, two, four, or any other suitable number of levels and/or servers. For example, the authoritative servers <b>130</b> can also include a level-3 nameserver (not shown) subordinate to the level-2 nameserver <b>138</b>.

As shown in <figref idref="DRAWINGS">FIG. 1</figref>, in the hierarchy of the authoritative servers <b>130</b>, the root nameserver <b>134</b> can contain a resource record (not shown) containing a network address for the level-1 nameserver <b>136</b> corresponding to, e.g., a top-level domain such as “.com”. The level-1 nameserver <b>136</b> can include a NS record <b>115</b> containing URLs for the level-2 nameservers <b>138</b> corresponding to a domain name, e.g., “example.com.” The level-2 nameservers <b>138</b> can then include a resource record <b>116</b> containing an IP address (e.g., 192.168.0.1) that corresponds to a server associated with the domain name “www.example.com.” Though not shown in <figref idref="DRAWINGS">FIG. 1</figref>, the level-2 nameservers <b>138</b> can include a set of active authoritative servers and another set of passive authoritative servers all identified in the NS record <b>115</b>, as discussed in more detail below with reference to <figref idref="DRAWINGS">FIGS. 2A and 2B</figref>.

As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the caching server <b>112</b> can include a DNS recursor <b>113</b> operatively coupled to a DNS cache <b>114</b>. The DNS recursor <b>113</b> can be configured to recursively resolve a domain name of a target domain by transmitting a query <b>120</b> to and receiving NS record <b>115</b> or resource record <b>116</b> from the one or more authoritative servers <b>130</b>. The DNS cache <b>114</b> can be configured to store any resource records <b>116</b> previously resolved by the DNS recursor <b>113</b> for a period of time, for example, as specified by a time-to-live value. In certain embodiments, a value of the time-to-live period can be set by one or more of the authoritative servers <b>130</b>. In other embodiments, the time-to-live value may be set by an administrator, an application, or other suitable entities.

The caching server <b>112</b> can be configured to return a copy of the cached resource records <b>116</b> as a DNS response <b>110</b> in response to a DNS query <b>108</b> from the client device <b>102</b>. In one embodiment, the caching server <b>112</b> can determine if a resource record <b>116</b> corresponding to a domain name already exists in the DNS cache <b>114</b>. If the resource record <b>116</b> already exists in the DNS cache <b>114</b>, the caching server <b>112</b> transmits a copy of the resource record <b>116</b> as a DNS response <b>110</b> to the client device <b>102</b> via the computer network <b>107</b>. If a resource record <b>116</b> does not exist in the DNS cache <b>114</b>, the caching server <b>112</b> can invoke the DNS recursor <b>113</b> to retrieve a copy of the resource record <b>116</b> from the authoritative servers <b>130</b>.

In operation, a user <b>101</b> can request access to a domain name (e.g., “www.example.com”) using the client device <b>102</b>. The name resolver <b>104</b> at the client device <b>102</b> can first determine if a resource record <b>116</b> for the requested domain name already exists or cached in the local DNS cache <b>106</b>. If one already exists, the client device <b>102</b> can initiate network operations to servers associated with the domain name based on the cached resource record <b>116</b>. If one does not exist, the client device <b>102</b> can consult the caching server <b>112</b> for a corresponding resource record <b>116</b>.

In response to the received request, the caching server <b>112</b> can first determine if a resource record <b>116</b> is available in the DNS cache <b>114</b>. If one is available, the caching server <b>112</b> can return the resource record <b>116</b> as a DNS response <b>110</b>. If one is not available, the caching server <b>112</b> can invoke the DNS recursor <b>113</b> to recursively query the authoritative servers <b>130</b>. For example, the caching server <b>112</b> can first query the root nameserver <b>134</b> for a resource record containing a network address of the level-1 nameserver <b>136</b> (e.g., 198.41.0.4). Then, the caching server <b>112</b> can query the level-1 nameserver <b>136</b> for a NS record <b>115</b> containing a network address of the level-2 nameserver <b>138</b>.

The caching server <b>112</b> can then query an active authoritative server in the level-2 nameservers <b>138</b> to retrieve a copy of the resource record <b>116</b> containing a network address of the requested domain name (e.g., 192.168.0.1) that corresponds to a server associated with the domain name “www.example.com.” If the active authoritative server in the level-2 nameservers <b>138</b> is not reachable, the caching server <b>112</b> can query additional active authoritative server if one is available. If none of the active authoritative servers is reachable, the caching server <b>112</b> can then query one or more passive authoritative servers for the resource records <b>116</b>, as described in more detail below with reference to <figref idref="DRAWINGS">FIGS. 2A and 2B</figref>.

<figref idref="DRAWINGS">FIGS. 2A and 2B</figref> are schematic diagrams illustrating a portion of the computing framework <b>100</b> in <figref idref="DRAWINGS">FIG. 1</figref> during first and second operational modes, respectively, in accordance with embodiments of the disclosed technology. In particular, <figref idref="DRAWINGS">FIG. 2A</figref> illustrates a first operational mode in which at least one active nameserver is reachable. <figref idref="DRAWINGS">FIG. 2B</figref> illustrates a second operational mode in which no active nameservers is reachable and a passive nameserver is accessed for name resolution. Certain components of the computing framework <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref> are omitted in <figref idref="DRAWINGS">FIGS. 2A and 2B</figref> for clarity.

As shown in <figref idref="DRAWINGS">FIG. 2A</figref>, the level-2 nameservers <b>138</b> can include a first active nameserver <b>138</b><i>a</i>, a second active nameserver <b>138</b><i>b</i>, and a passive nameserver <b>138</b><i>c</i>. Even though particular number of active and passible nameservers <b>138</b><i>a</i>-<b>138</b><i>c </i>are shown in <figref idref="DRAWINGS">FIG. 2A</figref>, in other embodiments, the level-2 nameservers <b>138</b> can include any other suitable numbers of active and/or passive nameservers. The level-1 nameserver <b>136</b> can contain an NS record <b>115</b> that identifies each of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>and the passive nameserver <b>138</b><i>c. </i>

In certain embodiments, the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>can be implemented with functionalities that the passive nameserver <b>138</b><i>c </i>does not have. For example, the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>can be implemented to provide name resolution between virtual machines located in the same cloud service, in different cloud services, in the same virtual network, or in different virtual networks, that the passive nameserver <b>138</b><i>c </i>does not provide. Instead, the passive nameserver <b>138</b><i>c </i>can be implemented with limited functionalities to provide, for example, basic name resolution for select domain names (e.g., upper-level domain names or default IP addresses for domain names). For convenience of discussion, in the following description, the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>and the passive nameserver <b>138</b><i>c </i>all contain the same resource record <b>116</b> associated with an example domain name “www.example.com”.

During operation, the caching server <b>112</b> can first query the level-1 nameserver <b>136</b> for resolving the domain name “www.example.com”. In response, the level-1 nameserver <b>136</b> provides an NS record <b>115</b> associated with the domain name to the caching server <b>112</b>. Based on the received NS record <b>115</b>, the caching server <b>112</b> can determine that the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>and the passive nameserver <b>138</b><i>c </i>are authoritative for the domain name “www.example.com”. In response, the caching server <b>112</b> can query the first or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>for a resource record <b>116</b> associated with “www.example.com”. In certain embodiments, the caching server <b>112</b> can query the first or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>randomly, alternately, or in other suitable orders. In other embodiments, the caching server <b>112</b> can query the first or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>based on, for example, response times to previous queries to these name servers. In yet other embodiments, the caching server <b>112</b> can determine which one of the first or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>to query based on other suitable criteria. Upon receiving the query <b>120</b> from the caching server <b>112</b>, the first or second nameserver <b>138</b><i>a </i>and <b>138</b><i>b </i>can transmit the requested resource record <b>116</b> to the caching server <b>112</b>.

During operation in the first operational mode, the caching server <b>112</b> does not query the passive nameserver <b>138</b><i>c </i>unless both the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>are unreachable. When, for example, the first active nameserver <b>138</b><i>a </i>is unreachable, the caching server <b>112</b> can contact the second active nameserver <b>138</b><i>b </i>for the resource record <b>116</b>, or vice versa. The passive nameserver <b>138</b><i>c </i>can be in standby with little or no access from the caching server <b>112</b>. As such, configuration, maintenance, or other work can be readily performed on the passive nameserver <b>138</b><i>c</i>. In certain embodiments, the caching server <b>112</b> can periodically transmit echo messages <b>121</b> to the passive nameserver <b>138</b><i>c</i>. Upon receiving the echo message <b>121</b>, the passive nameserver <b>138</b><i>c </i>can provide an echo response <b>123</b> configured to indicate a status (e.g., online, offline, etc.) of the passive nameserver <b>138</b><i>c</i>. In other embodiments, the caching server <b>112</b> can transmit no messages to the passive nameserver <b>138</b><i>c </i>as long as a predetermined number of active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>are reachable.

As shown in <figref idref="DRAWINGS">FIG. 2B</figref>, the caching server <b>112</b> can determine that the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>are both unreachable by contacting these nameservers <b>138</b><i>a </i>and <b>138</b><i>b</i>. In certain embodiments, the caching server <b>112</b> can indicate that the first and/or second nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>are unreachable in response to not receiving the requested resource record <b>116</b> in a predetermined period of time, or not receiving any response from the first and/or second nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>after a predetermined number of retries. In other embodiments, the caching server <b>112</b> can indicate that the first and/or second nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>are unreachable based on other suitable conditions. In response, the caching server <b>112</b> transmits a query <b>120</b> to the passive nameserver <b>138</b><i>c</i>. In response to the received query <b>120</b>, the passive nameserver <b>138</b><i>c </i>can provide the resource record <b>116</b> to the caching server <b>112</b>.

During operation in the second operational mode, the caching server <b>112</b> can also periodically contacting the first and/or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>by, for example, transmitting a query <b>120</b> thereto. If a response is received from the first and/or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b</i>, the caching server <b>112</b> can cease accessing the passive nameserver <b>138</b><i>c </i>and revert to the first operational mode, as described with reference to <figref idref="DRAWINGS">FIG. 2A</figref>.

Even though the second operational mode is described above as being based on the condition that none of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>are reachable, in other embodiments, the second operational mode can also be based on a condition that a predetermined number of active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>remains reachable or becomes unreachable. In one example, the second operational mode can be initiated when only one active nameserver <b>138</b><i>a </i>or <b>138</b><i>b </i>remains reachable. In another example, in response to determining that one or two of the active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>become unreachable, the caching server <b>112</b> can start querying the passive nameserver <b>138</b><i>c</i>. In further examples, the second operational mode may be initiated based on operator input or other suitable conditions.

In <figref idref="DRAWINGS">FIGS. 2A and 2B</figref>, only one passive nameserver <b>138</b><i>c </i>is shown for illustration purposes. In other embodiments, the level-2 nameservers <b>138</b> can include two, three, or any suitable number of passive nameservers. During operation in the second operational mode, the caching server <b>112</b> can access the passive nameservers randomly, sequentially, or in other suitable orders. In further embodiments, the caching server <b>112</b> can also access the passive nameservers based on, for example, response times from previous queries and/or other suitable conditions.

In the foregoing description, the technique of passive nameserver delegation is described using NS records as examples. In other embodiments, such passive nameserver delegation can also be applied to A-type, AAAA-type, DS-type, other suitable types of DNS records. For instance, an A-type DNS record can include both active IP addresses (e.g., 192.168.0.1 to 192.168.0.10) and passive IP addresses (e.g., 172.168.0.1 to 172.169.0.10) for a domain name (e.g., www.example.com). The caching server <b>112</b> provides a resource record <b>116</b> containing the active IP addresses to a DNS query <b>108</b> during normal operation. However, when none (or a predetermined number) of the servers at the active IP addresses are unreachable, the caching server <b>112</b> can then provide the passive IP addresses in response to the DNS query <b>108</b>. Similar to the passive authoritative servers described above, servers at the passive IP addresses can also be cost effective to implement by, for example, only providing fewer number of functionalities as compared to those at the active IP addresses.

<figref idref="DRAWINGS">FIGS. 3A and 3B</figref> are block diagrams showing software components <b>141</b> suitable for the caching server <b>112</b> of <figref idref="DRAWINGS">FIGS. 1-2B</figref> during the first and second operational modes, respectively, and in accordance with embodiments of the disclosed technology. In particular, <figref idref="DRAWINGS">FIG. 3A</figref> illustrates the first operational mode in which at least one active nameserver is reachable. <figref idref="DRAWINGS">FIG. 3B</figref> illustrates the second operational mode in which no active nameservers is reachable and a passive nameserver is accessed for name resolution.

In <figref idref="DRAWINGS">FIGS. 3A and 3B</figref> and in other Figures hereinafter, individual software components, objects, classes, modules, and routines may be a computer program, procedure, or process written as source code in C, C++, Java, and/or other suitable programming languages. A component may include, without limitation, one or more modules, objects, classes, routines, properties, processes, threads, executables, libraries, or other components. Components may be in source or binary form. Components may include aspects of source code before compilation (e.g., classes, properties, procedures, routines), compiled binary units (e.g., libraries, executables), or artifacts instantiated and used at runtime (e.g., objects, processes, threads). Components within a system may take different forms within the system. As one example, a system comprising a first component, a second component and a third component can, without limitation, encompass a system that has the first component being a property in source code, the second component being a binary compiled library, and the third component being a thread created at runtime.

The computer program, procedure, or process may be compiled into object, intermediate, or machine code and presented for execution by one or more processors of a personal computer, a network server, a laptop computer, a smartphone, and/or other suitable computing devices. Equally, components may include hardware circuitry. A person of ordinary skill in the art would recognize that hardware can be considered fossilized software, and software can be considered liquefied hardware. As just one example, software instructions in a component can be burned to a Programmable Logic Array circuit, or can be designed as a hardware circuit with appropriate integrated circuits. Equally, hardware can be emulated by software. Various implementations of source, intermediate, and/or object code and associated data may be stored in a computer memory that includes read-only memory, random-access memory, magnetic disk storage media, optical storage media, flash memory devices, and/or other suitable computer readable storage media excluding propagated signals.

As shown in <figref idref="DRAWINGS">FIG. 3A</figref>, the caching server <b>112</b> can include a processor <b>131</b> coupled to a memory <b>132</b>. The processor <b>131</b> can include a microprocessor, a field-programmable gate array, and/or other suitable logic devices. The memory <b>132</b> can include volatile and/or nonvolatile media (e.g., ROM; RAM, magnetic disk storage media; optical storage media; flash memory devices, and/or other suitable storage media) and/or other types of computer-readable storage media configured to store data received from, as well as instructions for, the processor <b>131</b> (e.g., instructions for performing the methods discussed below with reference to <figref idref="DRAWINGS">FIGS. 5A-5E</figref>). As shown in <figref idref="DRAWINGS">FIG. 3A</figref>, the memory <b>132</b> can also contain data representing a set of NS records <b>115</b>, resource records <b>116</b>, and/or other suitable data.

The processor <b>131</b> can execute instructions to provide a plurality of software components <b>141</b> configured to provide backup capability of authoritative nameservers. As shown in <figref idref="DRAWINGS">FIG. 3A</figref>, the software components <b>141</b> can include an interface component <b>142</b>, a query component <b>144</b>, an analysis component <b>146</b>, and a control component <b>148</b> operatively coupled to one another. In one embodiment, all of the software components <b>141</b> can reside on a single computing device (e.g., a DNS server). In other embodiments, the software components <b>141</b> can also reside on a plurality of distinct computing devices. In further embodiments, the software components <b>141</b> may also include network interface components and/or other suitable modules or components (not shown).

As shown in <figref idref="DRAWINGS">FIG. 3A</figref>, the interface component <b>142</b> can be configured to receive a DNS query <b>108</b>, from, for example, the client device <b>102</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The interface component <b>142</b> can also be configured to provide a DNS response <b>110</b> to the client device <b>102</b> in response to the received DNS query <b>108</b>. Also, the interface component <b>142</b> can be configured to transmit one or more query <b>120</b> to the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>and in response, receiving resource records <b>116</b>. As shown in <figref idref="DRAWINGS">FIG. 3A</figref>, in the first operational mode, the interface component <b>142</b> can also be configured to transmit an echo message <b>121</b> to and receiving an echo response <b>123</b> from the passive nameserver <b>138</b><i>c</i>. In certain embodiments, the interface component <b>142</b> can include a network interface module with suitable firmware or software to perform the foregoing operations. In other embodiments, the interface component <b>142</b> can include other suitable types of communications modules.

The query component <b>144</b> can also be configured to process the received DNS query <b>108</b>. In one embodiment, the query component <b>144</b> can retrieve a cached resource record <b>116</b> in the memory <b>132</b> and construct the DNS response based thereon. If a cached resource record <b>116</b> does not exist in the memory <b>132</b>, the query component <b>144</b> can be configured to construct a query <b>120</b> to one of the level-2 nameservers <b>138</b> for a resource record <b>116</b> associated with a domain name. In certain embodiments, the query component <b>144</b> can include a data processor that sets appropriate flags or fills in appropriate values in a template of a query/response data structure. One example data structure suitable for the query <b>120</b>, DNS query <b>108</b>, and DNS response <b>110</b> is described in more detail below with reference to <figref idref="DRAWINGS">FIGS. 4A and 4B</figref>.

The analysis component <b>146</b> can be configured to determine when to switch between the first operational mode and the second operational mode. In one embodiment, the analysis component <b>146</b> can be configured to receive from the interface component <b>142</b> communications status with the various level-2 nameservers <b>138</b>. Example communications status can include a timeout status, a number of attempted retries, a number of successful prior transactions, and/or other suitable information. Based on the received communications status, the analysis component <b>146</b> can indicate a switch from the first operational mode to the second operational mode based on the following example conditions: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0057">when none of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>is reachable;</li><li id="ul0002-0002" num="0058">when a predetermined number (e.g., one or zero) of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>is reachable;</li><li id="ul0002-0003" num="0059">when a predetermined number (e.g., one or two) of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>become unreachable; or</li><li id="ul0002-0004" num="0060">when a predetermined percentage (e.g., 50%, 40%, 30%, 20%, 10%, or 0%) of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>is reachable;</li><li id="ul0002-0005" num="0061">when a predetermined percentage (e.g., 50%, 40%, 30%, 20%, 10%, or 0%) of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>is unreachable; or</li><li id="ul0002-0006" num="0062">any of the foregoing conditions and no additional active nameserver is listed in the NS record <b>115</b>.</li></ul></li></ul>

Based on the received communications status, the analysis component <b>146</b> can also indicate a switch from the second operational mode to the first operational mode based on the following example conditions: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0064">when at least one of the first or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>becomes reachable;</li><li id="ul0004-0002" num="0065">when a predetermined number (e.g., two) of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>becomes reachable;</li><li id="ul0004-0003" num="0066">when a predetermined percentage (e.g., 50%, 40%, 30%, 20%, 10%, or 0%) of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>becomes reachable; &lt;br /&gt; The foregoing examples conditions are shown for illustration purposes only. In other embodiments, the analysis component <b>146</b> can indicate a switch between the first and second operational modes based on operator input or other suitable conditions. </li></ul></li></ul>

In certain embodiments, the analysis component <b>146</b> can include counters, dividers, comparators, or other suitable data operators suitably coupled to perform the various operations described above. For example, the analysis component <b>146</b> can include a comparator having a first input representing a number of reachable active nameservers and a second input representing a threshold. The comparator can also include an output representing a result of a comparison between the number of reachable active nameservers and the threshold. In other embodiments, the analysis component <b>146</b> can include data filters, bias operators, and/or other suitable

The control component <b>148</b> can be configured to direct the interface component <b>142</b> to transmit the query <b>120</b> to the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>or the passive nameserver <b>138</b><i>c </i>based on the determination of first or second operational mode from the analysis component <b>146</b>. For example, as shown in <figref idref="DRAWINGS">FIG. 3A</figref>, the control component <b>148</b> can direct the interface component <b>142</b> to transmit the query <b>120</b> to the first and/or second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>in the first operational mode. In contrast, as shown in <figref idref="DRAWINGS">FIG. 3B</figref>, the control component <b>148</b> can direct the interface component <b>142</b> to transmit the query <b>120</b> to the passive nameserver <b>138</b><i>c </i>in the second operational mode.

<figref idref="DRAWINGS">FIG. 4A</figref> is a schematic diagram illustrating an example data structure <b>200</b> suitable for the query <b>120</b> or the DNS query <b>108</b> of <figref idref="DRAWINGS">FIG. 1</figref> in accordance with embodiments of the disclosed technology. As shown in <figref idref="DRAWINGS">FIG. 4A</figref>, the data structure <b>200</b> can include a header field <b>202</b> and a question field <b>204</b>. The header field <b>202</b> can include parameters that describe the type of query and which fields are contained in the query. For example, the header field <b>202</b> can contain a query identifier, a one-bit field that specifies whether the data structure <b>200</b> is a query or a response, or other suitable parameters.

The question field <b>204</b> can contain a question for a DNS server (e.g., the level-1 nameserver <b>136</b> of <figref idref="DRAWINGS">FIG. 2A</figref>). <figref idref="DRAWINGS">FIG. 4B</figref> is a schematic diagram illustration an example data structure suitable for the question field <b>204</b> of <figref idref="DRAWINGS">FIG. 4A</figref> in accordance with embodiments of the disclosed technology. As shown in <figref idref="DRAWINGS">FIG. 4B</figref>, the question field <b>204</b> can include a name field <b>212</b>, a type field <b>214</b>, and a class field <b>216</b>. The name field <b>212</b> can contain a domain name (e.g., “www.example.com”) represented as a sequence of labels (e.g., “example” and “com”). The type field <b>214</b> can contain data specifying a query type, for example, data indicating an NS-type query. The class field <b>216</b> can contain data specifying the class of the query (e.g., “IN” indicating Internet). In other embodiments, the question field <b>204</b> can also include other suitable fields.

<figref idref="DRAWINGS">FIG. 4C</figref> is a schematic diagram illustration an example data structure <b>230</b> suitable for the NS record <b>115</b> or resource record <b>116</b> of <figref idref="DRAWINGS">FIGS. 2A and 2B</figref> in accordance with embodiments of the disclosed technology. As shown in <figref idref="DRAWINGS">FIG. 4C</figref>, the data structure <b>230</b> can include certain fields generally similar to that of <figref idref="DRAWINGS">FIG. 4B</figref>. For example, the data structure <b>230</b> can include a name field <b>212</b>, a type field <b>214</b>, and a class field <b>216</b>. The data structure <b>230</b> can also include a response data field <b>218</b> containing, for example, URLs of the first and second active nameservers <b>138</b><i>a </i>and <b>138</b><i>b </i>and the passive nameserver <b>138</b><i>c </i>of <figref idref="DRAWINGS">FIGS. 2A and 2B</figref>. In other embodiments, the data structure <b>230</b> can also include a time-to-live field, a length of response data field, or other suitable fields.

<figref idref="DRAWINGS">FIG. 5A</figref> is a flow diagram illustrating embodiments of a process <b>300</b> of providing backup capabilities to a DNS system in accordance with embodiments of the disclosed technology. Even though various embodiments of the process <b>300</b> are described below with reference to the computing framework <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref> and the software components <b>141</b> of <figref idref="DRAWINGS">FIGS. 3A and 3B</figref>, in other embodiments, the process <b>300</b> may be performed with other suitable types of computing frameworks, systems, components, or modules.

As shown in <figref idref="DRAWINGS">FIG. 5A</figref>, the process <b>300</b> can include determining authoritative name servers at stage <b>302</b>. In certain embodiments, as shown in <figref idref="DRAWINGS">FIG. 5B</figref>, determining the authoritative name servers can include transmitting a query for resolving a domain name at stage <b>312</b>. The query can be transmitted from, for example, the caching server <b>112</b> (<figref idref="DRAWINGS">FIG. 1</figref>) to the level-1 server <b>136</b> (<figref idref="DRAWINGS">FIG. 1</figref>). A response to the transmitted query can then be received at stage <b>314</b>. The received response can have a data structure generally similar to that shown in <figref idref="DRAWINGS">FIG. 4B</figref>. Based on the received response, the process <b>302</b> can include identifying authoritative name servers at stage <b>316</b>. In one embodiment, the identified authoritative name servers can include multiple active nameservers and passive nameservers. In other embodiments, the identified authoritative name servers can include multiple active nameservers and one passive nameserver. In further embodiments, the authoritative name servers may be determined based on cached NS records <b>115</b> (<figref idref="DRAWINGS">FIG. 1</figref>) on the caching server <b>112</b> or via other suitable techniques.

Referring back to <figref idref="DRAWINGS">FIG. 5A</figref>, the process <b>300</b> can include contacting active nameservers at stage <b>304</b>. <figref idref="DRAWINGS">FIG. 5C</figref> shows an example process <b>304</b> for contacting the active nameservers. In other embodiments, contacting the active nameservers can include other suitable operations in addition to or in lieu of those shown in <figref idref="DRAWINGS">FIG. 5C</figref>. As shown in <figref idref="DRAWINGS">FIG. 5C</figref>, contacting active nameservers can include selecting an active nameserver at stage <b>322</b>. In certain embodiments, selection of an active nameserver can be based on previous response times of the identified active nameservers. In other embodiments, the active nameserver can be selected randomly, sequentially, or in other suitable orders. The process <b>304</b> can also include transmitting a query for resolving a domain name to the selected active nameserver at stage <b>324</b>.

The process <b>304</b> can then include a decision stage <b>326</b> to determine whether the selected active nameserver is reachable. In certain embodiments, the active nameserver is deemed reachable if a response is received from the selected active nameserver in a predetermine period of time or after a predetermined number of retries. In other embodiments, the active nameserver can be deemed reachable or unreachable based on other suitable conditions. In response to determining that the selected active nameserver is reachable, the process <b>304</b> includes receiving a response from the selected active nameserver containing, for example, the resource record <b>116</b> (<figref idref="DRAWINGS">FIG. 1</figref>) associated with the domain name at stage <b>328</b>. In response to determining that the selected active nameserver is not reachable, the process <b>304</b> includes another decision stage <b>328</b> to determine if additional active nameservers are available, for example, listed in the NS record <b>115</b>. In response to determining that additional nameservers are available, the process <b>304</b> reverts to selection another active nameserver at stage <b>322</b>; otherwise, the process <b>304</b> proceeds to indicating that no active nameservers are reachable at stage <b>330</b>.

Referring back to <figref idref="DRAWINGS">FIG. 5A</figref>, the process <b>300</b> can include a decision stage <b>306</b> to determine whether to access passive nameserver(s), for example, based on the indication from operation at stage <b>330</b> of the process <b>304</b>. Various conditions may be used to determine whether to access passive nameserver(s). Example conditions are discussed above with reference to <figref idref="DRAWINGS">FIG. 3A</figref>. In response to determining to access passive nameserver(s), the process <b>300</b> can proceed to contacting passive nameserver(s) at stage <b>308</b>.

<figref idref="DRAWINGS">FIG. 5D</figref> illustrates one example process <b>308</b> for contacting passive nameserver(s). As shown in <figref idref="DRAWINGS">FIG. 5D</figref>, the process <b>308</b> can include determining a number of passive nameservers at stage <b>332</b>, for example, based on entries in the NS record <b>115</b> (<figref idref="DRAWINGS">FIG. 1</figref>). The process <b>308</b> can then include a decision stage <b>334</b> to determine if more than one passive nameservers are available. In response to determining that more than one passive nameservers are available, the process <b>308</b> includes selecting one of the passive nameservers based on similar or different conditions for selecting active nameservers discussed above with reference to <figref idref="DRAWINGS">FIG. 5B</figref>. The process <b>308</b> can then proceed to transmitting a query to the selected passive nameserver at stage <b>338</b> and receiving a response from the selected passive nameserver at stage <b>340</b>. In response to determining that only one passive nameserver is available, the process <b>308</b> proceeds directly to transmitting a query to the selected passive nameserver at stage <b>338</b>.

Referring back to <figref idref="DRAWINGS">FIG. 5A</figref>, in response to determining not to access passive nameserver(s), the process <b>300</b> can proceed to resolving the domain name at stage <b>310</b>. <figref idref="DRAWINGS">FIG. 5E</figref> illustrates an example process <b>310</b> for resolving the domain name. As shown in <figref idref="DRAWINGS">FIG. 5E</figref>, the process <b>310</b> includes identifying name translations from the response from the active or passive nameserver at stage <b>342</b>. The process <b>310</b> can also include responding to a DNS query at stage <b>344</b> from, for example, the client device <b>102</b> (<figref idref="DRAWINGS">FIG. 1</figref>) and/or caching the identified name translations as resource records at stage <b>346</b>.

<figref idref="DRAWINGS">FIGS. 6A and 6B</figref> are example user interfaces <b>350</b> and <b>360</b>, respectively, useful for configuration of active/passive nameservers in accordance with embodiments of the disclosed technology. As shown in <figref idref="DRAWINGS">FIG. 6A</figref>, the user interface <b>350</b> can include multiple entries <b>352</b> each configured to allow an administrator or other suitable entity to enter one or more URLs of active/passive nameservers. For example, the user interface <b>350</b> can include a first entry <b>352</b><i>a </i>configured to receive a URL of an active nameserver (i.e., “ns1.example.com”) and a second entry <b>352</b><i>b </i>configured to receive another URL of an active name server (i.e., “ns2.example.com”). The user interface <b>350</b> can also include an entry <b>354</b> configured to receive a URL of a passive nameserver (i.e., “pns.example.com”). Even though particular entries <b>352</b> are shown in <figref idref="DRAWINGS">FIG. 6A</figref>, the number of entries <b>352</b> may be expanded by, for example, actuating “Add” buttons <b>356</b>.

As shown in <figref idref="DRAWINGS">FIG. 6B</figref>, the user interface <b>360</b> can include multiple entries <b>362</b> configured to receive URLs of nameservers (e.g., “ns1.example.com,” “ns2.example.com,” and “ns3.example.com”). Each of the entries <b>362</b> can also include a designation field <b>364</b> configured to receive an indication whether the associated URL corresponds to an active or passive nameserver. For example, In the illustrated embodiment, selectable buttons are shown in the designation field <b>364</b> to indicate that “ns1.example.com” and “ns2.example.com” corresponds to active nameservers, and “ns2.example.com” corresponds to a passive nameserver. Similar to the user interface <b>350</b> of <figref idref="DRAWINGS">FIG. 6A</figref>, the number of entries <b>362</b> can also be expanded by actuating the “Add” button <b>356</b>.

<figref idref="DRAWINGS">FIG. 7</figref> is a computing device <b>400</b> suitable for certain components of the computing framework <b>100</b> in <figref idref="DRAWINGS">FIGS. 1-2B</figref>. For example, the computing device <b>400</b> may be suitable for the level-1 nameserver <b>136</b>, level-2 nameserver <b>138</b>, the client device <b>102</b>, and the caching server <b>112</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In a very basic configuration <b>402</b>, computing device <b>400</b> typically includes one or more processors <b>404</b> and a system memory <b>406</b>. A memory bus <b>408</b> may be used for communicating between processor <b>404</b> and system memory <b>406</b>.

Depending on the desired configuration, the processor <b>404</b> may be of any type including but not limited to a microprocessor (μP), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. The processor <b>404</b> may include one more levels of caching, such as a level one cache <b>410</b> and a level two cache <b>412</b>, a processor core <b>414</b>, and registers <b>416</b>. An example processor core <b>414</b> may include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP Core), or any combination thereof. An example memory controller <b>418</b> may also be used with processor <b>404</b>, or in some implementations memory controller <b>418</b> may be an internal part of processor <b>404</b>.

Depending on the desired configuration, the system memory <b>406</b> may be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or any combination thereof. The system memory <b>406</b> can include an operating system <b>420</b>, one or more applications <b>422</b>, and program data <b>424</b>. As shown in <figref idref="DRAWINGS">FIG. 7</figref>, in certain embodiments, the application <b>422</b> may include, for example, the interface component <b>142</b>, the query component <b>144</b>, the analysis component <b>146</b>, and the control component <b>148</b>, as described in more detail above with reference to <figref idref="DRAWINGS">FIG. 3A</figref>. In other embodiments, the application <b>422</b> can also include other suitable components. The program data <b>424</b> may include, for example, the resource records <b>116</b>. This described basic configuration <b>402</b> is illustrated in <figref idref="DRAWINGS">FIG. 9</figref> by those components within the inner dashed line.

The computing device <b>400</b> may have additional features or functionality, and additional interfaces to facilitate communications between basic configuration <b>402</b> and any other devices and interfaces. For example, a bus/interface controller <b>430</b> may be used to facilitate communications between the basic configuration <b>402</b> and one or more data storage devices <b>432</b> via a storage interface bus <b>434</b>. The data storage devices <b>432</b> may be removable storage devices <b>436</b>, non-removable storage devices <b>438</b>, or a combination thereof. Examples of removable storage and non-removable storage devices include magnetic disk devices such as flexible disk drives and hard-disk drives (HDD), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid state drives (SSD), and tape drives to name a few. Example computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.

The system memory <b>406</b>, removable storage devices <b>436</b>, and non-removable storage devices <b>438</b> are examples of computer readable storage media. Computer readable storage media include storage hardware or device(s), examples of which include, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media which may be used to store the desired information and which may be accessed by computing device <b>400</b>. Any such computer readable storage media may be a part of computing device <b>400</b>. The term “computer readable storage medium” excludes propagated signals and communication media.

The computing device <b>400</b> may also include an interface bus <b>440</b> for facilitating communication from various interface devices (e.g., output devices <b>442</b>, peripheral interfaces <b>444</b>, and communication devices <b>446</b>) to the basic configuration <b>402</b> via bus/interface controller <b>430</b>. Example output devices <b>442</b> include a graphics processing unit <b>448</b> and an audio processing unit <b>450</b>, which may be configured to communicate to various external devices such as a display or speakers via one or more A/V ports <b>452</b>. Example peripheral interfaces <b>444</b> include a serial interface controller <b>454</b> or a parallel interface controller <b>456</b>, which may be configured to communicate with external devices such as input devices (e.g., keyboard, mouse, pen, voice input device, touch input device, etc.) or other peripheral devices (e.g., printer, scanner, etc.) via one or more I/O ports <b>458</b>. An example communication device <b>446</b> includes a network controller <b>460</b>, which may be arranged to facilitate communications with one or more other computing devices <b>462</b> over a network communication link via one or more communication ports <b>464</b>.

The network communication link may be one example of a communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. A “modulated data signal” may be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), microwave, infrared (IR) and other wireless media. The term computer readable media as used herein may include both storage media and communication media.

The computing device <b>400</b> may be implemented as a portion of a small-form factor portable (or mobile) electronic device such as a cell phone, a personal data assistant (PDA), a personal media player device, a wireless web-watch device, a personal headset device, an application specific device, or a hybrid device that include any of the above functions. The computing device <b>400</b> may also be implemented as a personal computer including both laptop computer and non-laptop computer configurations.

Specific embodiments of the technology have been described above for purposes of illustration. However, various modifications may be made without deviating from the foregoing disclosure. In addition, many of the elements of one embodiment may be combined with other embodiments in addition to or in lieu of the elements of the other embodiments. Accordingly, the technology is not limited except as by the appended claims.