Abstract:
Systems, methods and devices are provided for registering DNS hostnames of Internet host devices for very large domain zones (VLZ) stored on a DNS server on a network, including setting a pseudo-zone as the VLZ, intercepting DNS updates to the pseudo-zone, mapping the entries in the pseudo-zone into a hierarchy of real parent zones and sub-zones using a mapping formula, and translating DNS updates to the pseudo-zone from an original fully qualified domain name (FQDN) into a at least one new FQDNs and adding the at least one new FQDNs to an authoritative DNS Server.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 14/710,505, filed May 12, 2015, which claims priority to U.S. Provisional Application No. 62/008,155, entitled “METHOD AND SYSTEM FOR IMPLEMENTING VERY LARGE DNS ZONES” filed Jun. 5, 2014, both of which are hereby incorporated by reference in their entireties and for all purposes. 
     
    
     FIELD 
       [0002]    This invention relates generally to the field of DNS zone management. 
       BACKGROUND 
       [0003]    One of the effects of the proliferation of specialized devices on the Internet (the Internet of Things, or IoT) is that keeping track of very large numbers of similar devices, distributed over a large geographic area and different versions of devices, is a non-trivial problem because these devices may need to be tracked and maintained for decades, even as the Internet infrastructure around them evolves. For example, a network of utility meters may be required to control millions of such devices. In another example, a network of fire alarm sensors comprising many millions of devices may be monitored by a single network service. In yet another example, each streetlight in a city can be controlled and monitored by means of an Internet service. These devices may be organized by the Internet service according to the DNS domains in which they are a) configured to register themselves or b) registered by some other process. 
         [0004]    Historically, host names have been used to register Internet devices and map their network addresses using the world-wide, distributed network of Domain Name System (DNS) [RFC1034] servers. Internet devices can make use of this ubiquitous functionality by registering their identities with a DNS server under a zone that is predetermined for the service offered by the device. A typical device name can consist of a character string derived from unique attributes of the device, such as the network MAC address and the device serial number. However, the large number of hosts that can be registered to a single zone places a heavy processing burden on the individual DNS servers and negatively affects performance of the system, for example, by causing the server to take unacceptably long to boot up and start running. Furthermore, if the zone server fails, it can affect a very large number of devices, with possibly disastrous consequences depending on the implementation. 
         [0005]    In order to be able to use the DNS for IoT devices, methods and systems are desirable to limit the size of each DNS zone and to spread the load over a number of different servers without compromising the ability to update and query for IoT devices by domain names. 
         [0006]    Thus, needs exist for improved techniques of large DNS zone management. 
       SUMMARY 
       [0007]    Provided herein are embodiments of systems and methods that provide enhanced DNS zone management including storing large numbers of DNS host names in a very large zone (VLZ). The configuration of these systems and methods is described in detail by way of various embodiments which are only examples. 
         [0008]    The systems and methods disclosed can include: 
         [0009]    A) defining a pseudo-zone to represent the VLZ at issue, the pseudo-zone being a unique, one-way map from each original fully qualified domain name (FQDN) of a host name into a hierarchy of one or more subzones, wherein the number of subzones of the hierarchy is predetermined to distribute the hosts among the subzones and thereby limit the number of host names in each subzone to a predetermined manageable size. 
         [0010]    B) Mapping the entries in the pseudo-zone into a hierarchy of real zones by means of a mapping formula. 
         [0011]    C) Translating each DNS update to the VLZ from the original fully qualified domain name (FQDN) into a new FQDN incorporating the pseudo-zone uniquely derived from the original FQDN and adding the new FQDN to the DNS. As such, one original FQDN may result in one FQDN mapping. 
         [0012]    D) Responding to DNS queries for one of the translated domain names in the VLZ by intercepting the query, converting the query to one or more modified DNS queries and sending the modified query to a DNS server that is able to resolve the new FQDN and convey the DNS response to the requestor. 
         [0013]    Other systems, devices, methods, features and advantages of the subject matter described herein will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the subject matter described herein, and be protected by the accompanying claims. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0014]    The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely. 
           [0015]      FIG. 1  is a high level representation of mapping functionality. 
           [0016]      FIG. 2  is a mapping algorithm diagram for an example embodiment of a mapping algorithm. 
           [0017]      FIG. 3  is a mapping interaction diagram. 
           [0018]      FIG. 4  is a logic flow diagram for a Dynamic DNS update using a Domain Translation Service. 
           [0019]      FIG. 5  if a logic flow diagram for a DNS Query using a Domain Translation Service. 
           [0020]      FIG. 6  is a logic flow diagram for a DNS Query using a CNAME Response. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]    Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims. 
         [0022]    Provided herein are systems and methods including updating Domain Names to the DNS for very large zones (VLZ), the querying of values from a VLZ and the mapping function used to convert the FQDNs. 
         [0023]    Mapping Function 
         [0024]    Apart from the IETF rules governing domain name syntax [RFC1035], there is no approved standard or convention for the creation of host names for devices on the Internet of Things (IoT). However, since global uniqueness of host names is often required, such names often include text and numeric strings based on one or more local attributes of the device. These can include, for example, the network MAC address, the serial number, the manufacturer&#39;s name or identifier, the device version number, the type of device, date of manufacture, country of sale and provisioning identifier. To elaborate, these attributes can be combined to form a Globally Unique Identifier (GUID) string of the form: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, where x represents an alphanumeric number in the range [0-9, a-f] 
         [0025]    A device that is connected to a network in the domain (e.g. “somezone”) may therefore try to register its host name with a DNS server using dynamic DNS (DDNS). The DDNS update may therefore attempt to register the FQDN with the authoritative server for “somezone” as: “12345678-1234-1234-1234-0123456789abcd.somezone” 
         [0026]      FIG. 1  is a high level representation of mapping functionality  100 . As shown in  FIG. 1 , a host and domain  102  can be run through a mapping function  104  and output a host, subdomain and newdomain  106 . 
         [0027]      FIG. 2  is a mapping algorithm diagram  200  for an example embodiment of a mapping algorithm. 
         [0028]    In some embodiments, the server receiving the update request may apply a mapping function, as illustrated in  FIG. 1  and  FIG. 2 , so that the domain name may be mapped into a zone hierarchy, based on the following, as shown in more detail in  FIG. 2 ; 
         [0029]    A) The original domain name  201  can be passed through a hash function and truncated to obtain an n-bit number hash string  202 , where n is chosen such that the n-bit number is uniformly distributed in the range [0, m−1] where m is the number of sub-zones desired to hold the domain names. The hash function can be chosen from a wide selection of such functions, for example, the CRC [CRC], FNV hash algorithm [FNV] or SHA-2 digest [RFC6234], provided that it offers a satisfactory uniform distribution over the chosen range. A sub-zone  204  can be an alphabetic prefix  203  followed by the hash string  202 . Prefixes themselves are DNS-compliant. 
         [0030]    B) A new parent domain  206  can be selected from a predefined list of parent domains. The new parent domain  206  can be determined by taking a modulus of the hash and using it as a selector of the parent domain to use. 
         [0031]    C) A new FQDN  205  is synthesized by inserting the new sub-zone into the old FQDN between the host name and the parent domain. For example: “12345678-1234-1234-1234-0123456789abcd.zn35c.newdomain”. 
         [0032]    This new FQDN can be used for the DDNS registration and the subzone (e.g. “zn35c”) may be created if it does not already exist. 
         [0033]    Registration 
         [0034]    Registration of DNS entries may be accomplished by means of Dynamic DNS updates as well as other means, such as IP address management [IPAM] as is well known in the art. 
         [0035]      FIG. 3  is a message interaction diagram  300 . As shown in  FIG. 3 , a Domain Translation Service, which can be a software component including instructions stored in memory that can be running in a network server (such as a DNS server) or a Software Defined Network (SDN) controller, that receives the DDNS update from an Internet device  301  over a network, can perform the mapping function to obtain a new FQDN and pass this new FQDN to the DDNS server ( 302   a ,  302   b ,  302   c , etc.) appropriate to the parent zone in the FQDN. The DNS server ( 302   a ,  302   b ,  302   c  or others) can then create a sub-zone if it does not already exist and store the new FQDN as a resource record, for example an A record or an AAAA record, in a DNS data store. The FQDN may not be stored but rather it is recalculated every time a request is made (query or update). An example of a device which can function as a server can be seen in FIG. 14 of U.S. Patent Application Publication No. 2013/0103819 which is incorporated by reference herein in its entirety. 
         [0036]    In some embodiments of this invention, as illustrated in  FIG. 4 , the Domain Translation Service may include a software module for receiving the FQDN update request via one of a variety of protocols, such as DDNS, HTTPS, REST and so on, a mapping function for performing the translation from the original FQDN to the new FQDN and a sender for registering the DDNS update to the DNS server using the DDNS update protocol [RFC2136]. 
         [0037]      FIG. 4  is a logic flow diagram  400  for a Dynamic DNS update using a Domain Translation Service. In the example embodiment, a network device can perform a DDNS registration step  402  where the network device determines whether it is network connected in step  404 . If it is not network connected, then the DDNS registration ends in step  430 . If the network device is network connected in step  404  then it gets a network domain and DNS server in step  406 . In step  408  the device determines if it is already registered. If it is already registered then the DDNS registration ends in step  430 . If it is not already registered then it obtains a device identifier, such as a GUID in step  410 . Next the device performs a DDNS registration in step  412 . 
         [0038]    In step  414  the network device undergoes a check to determine if the domain is a very large domain. If it is a very large domain then it derives a FQDN from a host name in step  416 , after which it registers the host in domain DNS in step  418 . If the domain is not a very large domain in step  414  then it skips step  416  and goes directly to step  418 . 
         [0039]    After step  418 , a DDNS update is received in step  420 . Next a determination is made of whether a sub-zone exists in step  422 . If a sub-zone does not exist then a sub-zone is created in the DNS domain in step  424  before registering the host in DNS in step  426 . If a sub-zone does exist in step  422  then step  424  is skipped before moving to step  426 . Next a registration response is sent to the network device in step  428  before the process ends in step  430   
         [0040]    In another embodiment, the Domain Translation Service may be implemented as a function of a network switch in, for example, a Software Defined Network [ref SDN] installation, wherein the Domain Translation Service may perform modification of the FQDN in the DDNS update message while the message is in transit. 
         [0041]    DNS Queries 
         [0042]    As illustrated in  FIG. 3 , a client  303  can query the device FQDN from a recursive DNS server  304  which in turn can query an authoritative server  302   a ,  302   b ,  302   c  for the VLD from the plurality of authoritative servers  302   a ,  302   b ,  302   c , or others. In some embodiments, as shown in  FIG. 5 , the authoritative DNS server for the domain can: receive the DNS query from client  303 ; perform a check to determine if the domain is a VLD; if the domain is not a VLD, the query can be handled normally by the DNS server; if the domain is a VLD, the FQDN may be synthesized by means of the mapping function; the synthesized FQDN may be resolved by the DNS server if this is possible and the queried resource records types can be returned to the requestor, recursive server  304 , as a CNAME record; or if the CNAME domain references a different authoritative server, the authoritative DNS Server can perform recursion to resolve it from the plurality of authoritative servers  302   a ,  302   b ,  302   c , etc. this time for the new FQDN in the synthesized CNAME resource record and receive the authoritative answer resource records from the DNS data store  306   a ,  306   b ,  306   c , etc. and return them to the requestor, recursive server  304 ; or return the synthesized CNAME to the requestor, recursive server  304  as a DNS response in order for the requestor to perform the DNS recursion. A time-to-live (ttl) value of the CNAME response can be small to limit the size of cache needed to store the CNAMEs in use on the network; return the DNS response answer to client  303 . 
         [0043]    In yet another embodiment, querying a device FQDN by a network client can be accomplished whereby a DNS query message to a DNS server  304  is passed through a Domain Translation  307 , for example, a Software Defined Network [SDN] installation, wherein the Domain Translation  307  can perform modification of the FQDN in the DDNS query message before the query message reaches the DNS server  304 , the DNS server responding with the resource records and the Domain Translation  307  correctly formatting the DNS response and returning the DNS response answer to the network client  303 . Similarly, the Domain Translation  305  can be embodied by an SDN installation that modifies network messages from Internet Device  301 s and routes the modified messages to authoritative DNS server  306   a ,  306   b  or  306   c . The SDN installation can comprise a network switch such as an OpenFlow-compatible network switch and a computer-based SDN controller that supports the OpenFlow protocol, for example the OpenDaylight controller [opendaylight.org] or the Virtual Application Networking controller from Hewlett-Packard [HP]. The SDN controller can include a hard drive containing the software application instructions needed to perform the Domain Translation  307 , and Domain Translation  305  services. 
         [0044]    In yet another embodiment, the Domain Translation  307  can exist as a computer software module within recursive DNS server  304 , operably configured to intercept, translate and forward the DNS query network messages between the client  303  and the recursive DNS server  304 . The Domain Translation  305  can also exist as a computer software module within recursive DNS server  304 , operably configured to intercept, translate and forward the DNS registration network messages between the Internet Device  301  and the authoritative DNS server  306   a ,  306   b  or  306   c . The number of authoritative DNS servers is not limited to 3 and may be more or less in other embodiments. 
         [0045]      FIG. 5  if a logic flow diagram for a DNS Query  500  using a Domain Translation Service. In the example embodiment, a DNS Query  502  can start with a device name being queried from a DNS server in step  504 . Next a DNS query can be detected for a device FQDN in step  506 . Then a determination is made of whether the domain is a Very Large Domain in step  508 . If the domain is a very large domain then a sub-zone name is computed from the host name in step  510 . Next the DNS query is modified for a new FQDN in step  512  before sending the DNS query to the DNS server in step  514 . If the domain is not a Very Large Domain in step  508 , then steps  510  and  512  are skipped and the process moves directly to step  514 . After step  514 , the query is received for the new FQDN in step  516  before looking up a DNS entry in the sub-zone in step  518 . A DNS response can be modified in step  520  to return the original queried FQDN. Next a DNS address response is received in step  522  before the process is completed in step  524 . 
         [0046]      FIG. 6  is a logic flow diagram for a DNS Query  600  using a CNAME Response. In the example embodiment, a DNS query is begun in step  602  where a device name is queried in step  604 . A DNS query is detected for a device FQDN in step  606  and a sub-zone name is computed from a host name in step  608 . Next a new FQDN CNAME is computed in step  610 . A DNS CNAME response is sent in step  612  and received in step  614 . Next a new FQDN is queried from a DNS server in step  616  before being received in step  618 . The DNS entry is looked up in step  620  and the DNS address response is received in step  622  before the process is complete in step  624 . 
         [0047]    As used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise. 
         [0048]    The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed. 
         [0049]    It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art. 
         [0050]    In many instances entities are described herein as being coupled to other entities. It should be understood that the terms “coupled” and “connected” (or any of their forms) are used interchangeably herein and, in both cases, are generic to the direct coupling of two entities (without any non-negligible (e.g., parasitic) intervening entities) and the indirect coupling of two entities (with one or more non-negligible intervening entities). Where entities are shown as being directly coupled together, or described as coupled together without description of any intervening entity, it should be understood that those entities can be indirectly coupled together as well unless the context clearly dictates otherwise. 
         [0051]    While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.