Silhouette of a person with rolling luggage walking through a futuristic, glowing tunnel lined with computer monitors and tech elements, with an airplane silhouette overhead and warm orange light radiating from the vanishing point.

The Journey not the Destination

GeoFrenzy’s DNS-Based Microairspace Data Distribution

 GeoFrenzy’s DNS-Based Microairspace Data Distribution

Background: Smart Geofences and Micro‐Airspace

GeoFrenzy was a startup that developed an end-to-end platform for creating, managing, and delivering “smart” geofences – virtual perimeters with associated rules or permissions (dubbed “geospatial entitlements”) for the use of space. The system was designed to handle extremely fine-grained geographic regions, effectively gridding the entire planet down to centimeter-scale cells. This granularity enables defining micro-airspace zones – for example, precise 3D airspace segments for drone operations – each with its own permissions and rules. An example use-case described by GeoFrenzy is drones operating in federal airspace, where different microzones of the sky can have unique rules that autonomous devices must obey. To standardize such geofencing, GeoFrenzy built what it called the first public geofence registry and a Fence Delivery Network (FDN) for distributing geofence data to devices.

Crucially, GeoFrenzy’s approach leverages the Domain Name System (DNS) as the backbone for this geofence registry and data delivery network. By using DNS’s global, scalable infrastructure, GeoFrenzy could distribute location-specific data (ownership info, classes of zone, rules, etc.) efficiently and even allow devices to cache large numbers of geofences locally for real-time or offline use. In fact, the patented FDN operates over standard DNS and can cache 50,000+ geofences on a device for instant access. This DNS-driven design was seen as key to supporting emerging autonomous technologies (drones, IoT devices, self-driving cars) that require continuous location context (“Where am I and what are the rules here?”) to make autonomous decisions. As DNS expert Patrik Fältström noted, “The DNS is a very useful and scalable infrastructure for such a [geofence] registry”, ideally suited to deliver the micro-location data needed by drones and other devices.

IPv6 and DNS Mapping in GeoFrenzy’s Geofence Network

At the core of GeoFrenzy’s system is a space-network model that binds IP addresses to physical locations. In practice, this means every geofence (or even point within a geofence) is assigned a unique network address – preferably an IPv6 address – that serves as its identifier. The immense address space of IPv6 (2^128 possibilities) allows GeoFrenzy to index the world’s surface (and volume) at centimeter resolution. Each geofence is defined by a set of geographic designators (points or cells), and each designator is associated with a 128-bit IPv6 address. In GeoFrenzy’s patents, these location-linked addresses are referred to as geocodes or anchor points. The system can even assign IP-based geocodes to mobile objects (like a specific drone or vehicle) or non-fixed assets, treating them as moving “geofences” with dynamic IP-based locations.

To make this scheme human-friendly and easily queryable, DNS naming is layered on top of the IPv6 geocodes. Each geofence or anchor point can also have a fully qualified domain name (FQDN) associated with its IPv6 address. For example, if a particular 3 m × 3 m location is represented by the what3words code “plummets.displays.already”, GeoFrenzy’s system could auto-generate the domain name plummets-displays-already.com for that geofence’s anchor point. This domain would map to the geofence’s IPv6 address in DNS, providing a human-readable handle that “precisely defines an area” by name and can be resolved to the numeric geocode. In practice, subdomains can encode hierarchical location context. GeoFrenzy illustrates that a place like “PNC Arena” might have subdomains for specific points: e.g. pncarena.plummets-displays-already.com where “pncarena” is the geofence name and “plummets-displays-already” is the specific anchor point inside it. This naming scheme allows both areas (geofences) and points (geocodes) to be referenced via DNS in a natural way.

Internally, GeoFrenzy also uses more coded DNS naming for data lookup. For instance, a DNS record like 000307aab18d03fe.blunt-chips-angle.geofrenzy.com combines a hex string with a word-based geocode. In this example, 000307aab18d03fe is an encoded location identifier (derived from an IPv6 address) and blunt-chips-angle is the corresponding what3words triplet, under the geofrenzy.com domain. This shows how GeoFrenzy packs machine-oriented identifiers and human-readable codes into DNS names. In some cases, the geocode data itself (like lists of coordinates that define a fence boundary) can be stored in DNS resource records (such as TXT records) rather than in the domain name string. Whether encoded in the name or in DNS record data, the DNS entries will carry metadata about the geofence.

Importantly, GeoFrenzy’s use of DNS incorporates standard protocols and security. The system relies on normal DNS resolution (which means it benefits from DNS’s distributed caching), and it can utilize DNSSEC-capable resolvers to ensure the authenticity of geofence data records. By designing around DNS infrastructure, GeoFrenzy made it possible for a device’s fencing agent to retrieve geofence info by simply performing DNS lookups, which is a lightweight operation even in constrained environments.

Each geofence’s definition ultimately boils down to an IPv6 “anchor” address and a DNS record describing that fence. The anchor’s DNS entry effectively links to the geofence’s boundary points and rules: GeoFrenzy notes that the “boundary of each geometry comprises IPv6 points in the space-network model” (multiple IPv6 addresses for the vertices or cells along the geofence) and that each anchor point has associated rule metadata (permissions, restrictions). In other words, each geofence geometry is represented by an anchor IPv6 and a set of additional IPv6 points (defining its shape), all indexed in DNS along with the fence’s rule set. This allows a query to the anchor to return the full geofence (via references to all its points and rules).

Reverse DNS Lookup Process (IPv6 to Location Metadata)

GeoFrenzy’s patents describe two complementary methods for using DNS to retrieve geofence data. In the “reverse DNS” model, the starting point is an IP address encoding a location. The process works as follows:

  1. Determine precise location: The device (running a fencing agent) determines its current geographic coordinates (e.g. via GPS) and identifies the relevant region of interest.
  2. Encode location into an IPv6 address: The device converts its location (and possibly context like zone type) into a specially formatted IPv6 address. In this scheme, portions of the 128-bit address encode the spatial coordinates (and may also embed class/entitlement info in certain bits). For example, an IPv6 like 2001:4700:f33d:0003:07aa:b18d:03fe:aab3 could be constructed, where 0003:07aa:b18d:03fe represents the location and aab3 encodes metadata, appended to a known network prefix (2001:4700:f33d).
  3. Compute the spatial “cell” identifier: Based on the encoded address, the device determines the appropriate cell or area designation (possibly a truncated prefix corresponding to a subdivision on the grid).
  4. DNS query for the cell’s address record: The device performs a DNS lookup (forward DNS query) for the computed cell address or a domain corresponding to it. This query asks the GeoFrenzy DNS service for any geofence anchor points in that cell. The DNS response returns a TXT record containing a list of anchor point IPv6 addresses that fall within the cell/region.
  5. Read and filter anchor points: The fencing agent reads the list of anchor IPv6 addresses from the DNS TXT record. Each anchor address corresponds to a geofence’s anchor in that area. If the addresses encode a “class” or type, the agent can filter them (e.g. only consider certain classes of geofences relevant to the device).
  6. Query DNS for each anchor’s data: For each relevant anchor IPv6, the agent then queries DNS (likely a reverse DNS lookup or a specific DNS zone query) to get that anchor’s associated fence information. This could involve retrieving another TXT record or address record that lists the fence’s boundary point addresses (the detailed coordinates of the geofence).
  7. Retrieve fence points: The DNS response provides the set of fence point addresses (or data) for the geofence tied to that anchor. With these, the device now has all the vertices or defining points of the geofence.
  8. Reconstruct geofence geometry and metadata: Using the anchor and its fence points, the fencing agent computes the geofence’s shape (geometry) in memory and compiles the metadata (e.g. rules, entitlements) attached to it. This may involve decoding any metadata bits from the IP addresses or retrieving additional info from DNS TXT fields.
  9. Enforce or utilize the geofence data: Finally, the device can analyze its own position relative to the reconstructed geofence and apply any rules. For example, if the rule metadata indicates “no-fly zone” and the device is a drone, it can initiate a behavior to avoid that area. If multiple geofences were returned for the region (multiple anchor points), the agent can do this for each, handling overlapping or nested fences appropriately.

Throughout this reverse DNS workflow, the DNS is essentially being used as a database mapping an IPv6 (location code) to geofence data. Notably, the term “reverse DNS” here refers to the idea that one starts with an IP to get named data (location info), rather than the conventional DNS use of mapping name→IP. GeoFrenzy’s implementation may involve private DNS zones or conventions (since a literal reverse lookup under .ip6.arpa might not be used for custom data), but the concept is that the IP address containing the location can be looked up to find the geofence names/IDs and then the details. The use of DNSSEC is recommended so that the device can trust that the DNS responses (which contain critical safety rules) are authentic.

Forward DNS Lookup Process (Name to Geofence Data)

The flipside of the above is the “forward DNS” model, where the device uses a textual geocode or domain name to query for geofence information. In this scenario, the steps are slightly different but ultimately retrieve the same kind of data (anchors, fence points, metadata) via DNS:

  1. Determine location and cell name: The fencing agent computes a textual identifier for its location. This could be a pre-defined geocode string (like a what3words triplet or some cell code) that corresponds to the region of interest. Essentially, the device figures out the DNS name of the cell in which it is located. (For example, it might form a name like 000307aab18d03fe.cell.geofrenzy.com or use a human-friendly code if available.)
  2. DNS query for the cell name: The device sends a DNS query for that cell’s domain name. The GeoFrenzy DNS server responds with a record (likely a TXT record or possibly a CNAME pointing to further data) that contains a list of geofence anchor names covering that cell. These anchor names might look like hash strings or meaningful labels (e.g. domain names of specific fences).
  3. Retrieve anchor point names: From the DNS answer, the agent obtains the set of anchor identifiers (as domain names). These could be names like deadbeef.geofrenzy.com or a structured subdomain naming each geofence anchor. Each corresponds to one geofence’s anchor.
  4. Filter by class if needed: Similar to the reverse case, the agent can ignore certain anchors if they carry class info that doesn’t apply (the class data might be indicated via a naming convention or a DNS record field).
  5. Query each anchor name for fence data: The agent then issues DNS lookups for each anchor’s domain name. In response, it receives the detailed fence data for that geofence – likely as a TXT record listing all the fence’s point coordinates or a set of related resource records.
  6. Retrieve fence points from DNS: From the anchor’s DNS records, the agent reads the list of fence point coordinates (or the IPv6 addresses representing those points).
  7. Compute geometry and metadata: As in the reverse model, the device now uses the anchor and fence points to reconstruct the geofence’s shape and gather its metadata (entitlements, rules, etc.).
  8. Apply geofence rules: With the geofence information in hand, the agent can enforce any constraints or trigger any appropriate actions because of the device’s location. This could mean notifying the user, restricting movement, or altering behavior if the device is inside or approaching a geofenced zone.

GeoFrenzy notes that in the forward model, location or metadata could be stored in any DNS record type, not just encoded in the name or IP. For example, they could use specialized DNS record types or structured TXT records to hold geofence data. The patents explicitly include examples of forward DNS queries. One such example is a query resulting in the domain 000307aab18d03fe.deadbeef.geofrenzy.com, where 000307aab18d03fe represents the location part and deadbeef represents metadata, under the GeoFrenzy domain. The response to querying this might return a list of fence point addresses or a blob of metadata in a TXT record. Essentially, forward DNS uses a textual key (like a coordinate-based name) to look up geofence info, whereas reverse DNS uses an IP key – but both achieve a mapping between location and the set of geofences in that location.

In both models, DNS is the conduit for data: a geofence query is just a DNS query under the hood, and geofence data is delivered in DNS responses (using standard DNS caching and distribution). This design means geofence data can be served by DNS servers world-wide and cached at local resolvers (like ISP or carrier DNS caches), enabling very fast lookups. In fact, GeoFrenzy deployed its authoritative DNS-based geofence registry globally in mid-2015 across major mobile carriers. This allowed mobile apps and devices to retrieve nearby fence data with minimal latency and even function if temporarily offline (thanks to cached DNS records). The DNS-based approach also scales naturally – just as the DNS can handle billions of domain records, it can likewise handle enormous numbers of micro-geofence records.

Microairspace Applications and GeoFrenzy’s Innovations

GeoFrenzy’s DNS-backed “GeoNet” platform was particularly aimed at microairspace management and next-generation location-aware devices. By encoding geospatial rules into DNS-addressable nodes, the system enables a kind of distributed airspace database. For example, an unmanned aerial vehicle (UAV) or drone equipped with GeoFrenzy’s fencing agent can determine its coordinates and instantly query the DNS to find what geofence zones (if any) exist at that location and what rules apply. If the drone is about to enter a restricted 50 m×50 m no-fly zone at a certain altitude, the DNS query would return the geofence’s anchor and points, and the drone’s onboard logic could autonomously decide to avoid that micro-airspace. Because the geo-entitlements (permissions/restrictions) are pre-defined for each tiny cell of space, an autonomous device can fetch and obey them in real time. This is essentially machine-readable airspace regulation delivered via DNS. GeoFrenzy’s system can incorporate 3D space (height, depth) as well – patents mention that geofences can be two-dimensional or three-dimensional volumes, meaning microairspace slices (by altitude) are supported. A “geographic designator” in their database could thus pinpoint a small cube of airspace, with an IPv6 address encoding that cube’s location in three axes.

The metadata attached to geofences includes ownership, permissions, and device rules for that space. In a drone context, this could mean a geofence carries data like “Owned by Alice; Class: No-Camera Zone; Entitlement: Drone must not record video here” or perhaps “Permission: transit allowed below 50 m altitude” depending on the use-case. GeoFrenzy’s GeoNet was flexible to accommodate various classes of geofences – from privacy zones to safety zones to regulatory airspace. These “smart fences” can enforce policies: as noted in one description, “smart fences contain metadata defining rules, permissions and device capabilities, allowing fence owners to control applications/devices operating in their geo-space.”. This capability is important for IoT as well, not just drones. Smart cars, delivery robots, or even smartphone apps could all query the geofence DNS to know what is allowed in the location they’re in (e.g. a smart scooter might query if sidewalk riding is permitted in a given block).

Because GeoFrenzy built the system on DNS, data distribution is inherently scalable and near real-time. Queries for geofence data are resolved by the nearest DNS server with the answer in cache (or forwarded up the chain), which means even if millions of devices are querying geofence info, the load is distributed. The DNS caching also means a device moving within a city could already have the microairspace data for its area from a single initial query (since the FDN can deliver a bulk of fences in one go). GeoFrenzy indicated that a single device could locally store tens of thousands of geofences covering its vicinity. This local caching is what allows offline functionality: if connectivity drops, the device still knows the rules of the space it’s in, because it retrieved them when a connection was available.

From a patents and innovation standpoint, GeoFrenzy secured intellectual property on this DNS-centric method of geofence delivery. For instance, US Patent 9,906,902 B2 (“Geofence Information Delivery Systems and Methods”) describes a fencing agent that “determines a position with a DNS resolver, queries geofences with an IP address, [and] receives an anchor point with an IP address from the DNS”, referring to the sequence of using DNS queries to get nearby geofence anchors. It also specifies that “each geofence is associated with a plurality of geographic designators, wherein each of the plurality of geographic designators is associated with an IP address.” This patent and related ones (many invented by Benjamin T. Jones of GeoFrenzy) lay out the architecture of linking geofences to IPv6 addresses and using DNS lookups to distribute geofence metadata. Another patent (US 11,356,407 B2, “Geocoding with geofences”) further details storing geocodes as metadata in IPv6/DNS and the forward/reverse lookup models, providing concrete examples like the what3words domains and the encoding of location bits into IP addresses. GeoFrenzy’s filings also elaborated the concept of a space-network model (SNM), wherein any region (“geometry”) – down to a “nano-cube” – can be uniquely identified by an IPv6 anchor and have its own DNS-recorded rules. This was a novel synthesis of networking and geography: treating physical space as a network addressable entity.

In summary, GeoFrenzy pioneered a DNS-based approach to micro-location data distribution. By marrying IPv6 addressing (for uniquely encoding fine-grained locations) with the DNS infrastructure (for querying and caching distributed data), they created a geofence registry that could scale globally and respond in real-time. This allowed “microairspace” information – the rules governing each little slice of sky or land – to be published like DNS records and retrieved on demand by autonomous agents. The use of DNS and reverse DNS in GeoFrenzy’s system made it possible to leverage existing Internet infrastructure (from domain registries to ISP resolvers) for a completely new domain: dynamic geospatial entitlements. According to company statements, the GeoFrenzy FDN was deployed worldwide by 2015 and integrated with major telecom networks, demonstrating the practicality of the approach. While GeoFrenzy as a company is no longer operating (it was a small California-based startup, active mid-2010s), its concepts of using DNS for location services remain influential. The idea of an “airspace DNS” or geolocation DNS has clear relevance as drones and IoT devices proliferate. GeoFrenzy’s patents and prototypes showed that DNS, including IPv6 forward and reverse lookups, can be effectively used as a global data distribution mechanism for micro-geofenced content – delivering critical location-specific data (ownership, access rights, restrictions) to any device, anywhere, with internet-like scalability. This innovative use of DNS could foreshadow how future spatial data registries (for drones, autonomous cars, smart cities, etc.) might be implemented on top of the existing internet infrastructure.

All the above is backed by GeoFrenzy’s documentation and patents, which consistently highlight the DNS-centric design. In essence, GeoFrenzy transformed geofences into addresses and DNS entries – making the “coordinates to rules” lookup as simple as a DNS query – thereby enabling rapid, distributed dissemination of microairspace data to the devices that need it.

References

7