Patent Application
20210029076
This invention relates generally to the field of DNS zone management.
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.
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.
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.
Thus, needs exist for improved techniques of large DNS zone management.
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.
The systems and methods disclosed can include:
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.
B) Mapping the entries in the pseudo-zone into a hierarchy of real zones by means of a mapping formula.
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.
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.
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.
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.
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.
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.
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'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 respresents an alphanumeric number in the range [0-9, a-f]
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”
In some embodiments, the server receiving the update request may apply a mapping function, as illustrated in
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.
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.
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”.
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.
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.
In some embodiments of this invention, as illustrated in
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.
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
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.
As illustrated in
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 301s and routes the modified messages to authoritative DNS server 306a, 306b or 306c. 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.
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 306a, 306b or 306c. The number of authoritative DNS servers is not limited to 3 and may be more or less in other embodiments.
As used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.
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.
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.
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.
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.
This application is a continuation of U.S. patent application Ser. No. 16/290,700, filed Mar. 1, 2019, which is a continuation of U.S. patent application Ser. No. 15/616,846, filed Jun. 7, 2017, now U.S. Pat. No. 10,250,555, which is a continuation of U.S. patent application Ser. No. 14/710,505, filed May 12, 2015, now abandoned, and claims priority pursuant to 35 U.S.C. § 119(e) to U.S. Provisional Application No. 62/008,155, filed Jun. 5, 2014, the disclosures of all of which are hereby incorporated by reference in their entireties for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 62008155 | Jun 2014 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16290700 | Mar 2019 | US |
| Child | 16991031 | US | |
| Parent | 15616846 | Jun 2017 | US |
| Child | 16290700 | US | |
| Parent | 14710505 | May 2015 | US |
| Child | 15616846 | US |
