ZeroDNS: A Semantic Deterministic Addressing (SDA) Architecture
Replacing Recursive Lookups with Algorithmic Mapping

1. Introduction

The architectural separation of identity and location has been a fundamental design principle of the Internet. The Domain Name System (DNS) [1] successfully scales this separation globally by maintaining a distributed hierarchy of authoritative name servers. However, within localized environments, data centers, and highly coupled subdomain architectures, the reliance on recursive DNS lookups introduces latency and administrative overhead. Inter-service communications require stateful directory queries, yielding latencies typically ranging from 20ms to 100ms.

Furthermore, relying on external state for local addressing introduces attack vectors. Address Resolution Protocol (ARP) spoofing and DNS cache poisoning remain persistent threats because mapping identity to location relies on trusting dynamic, centralized records.

To address these limitations, we propose Semantic Deterministic Addressing (SDA), realized through the AUTONS protocol. SDA introduces a "Logic-over-Lookup" paradigm. By defining a mathematical relationship between a hostname and its IP address via a standardized Base-32 variant, SDA allows endpoints to compute a peer's IP address locally. This paper details the overarching ZeroDNS architecture, the underlying SDA encoding algorithms, scaling mechanisms via hashing, and the security implications for IPv6 and legacy IPv4 networks.

2. The SDA Architecture

2.1 The Encoding Mechanism

To bridge the gap between human-readable semantic identifiers and binary network addresses, SDA utilizes a tailored Base-32 encoding variant optimized for standard DNS syntax. As defined by the LDH (Letters, Digits, Hyphen) rule in RFC 952 [2] and RFC 1123 [3], DNS hostname segments permit only alphanumeric characters (a-z, 0-9) and the hyphen (-). Crucially, these RFCs mandate that segments cannot begin or end with a hyphen.

SDA leverages this constraint by designating the hyphen as a padding prefix. The 32 available 5-bit values are mapped sequentially to establish algorithmic alignment. Input strings are normalized to lowercase prior to encoding to adhere to DNS case-insensitivity standards:

• Null/Padding (-): Mapped to 00000 (Decimal 0). Because DNS forbids prepended hyphens, this zero-value sequence acts as a deterministic null prefix. During reverse decoding, leading zero-bits translate to hyphens, which the algorithm subsequently truncates to reconstruct the valid hostname.
• Alphabetic (a-z): Mapped sequentially from 00001 (Decimal 1) for a, through 11010 (Decimal 26) for z.
• Numeric Sub-range (0-4): Mapped to the remaining binary values: 0 → 11011 (27), 1 → 11100 (28), 2 → 11101 (29), 3 → 11110 (30), and 4 → 11111 (31).

Base-10 to Base-5 Conversion:

To accommodate the digits 5 through 9 within this strict 32-character alphabet, SDA implements a continuous numeric conversion step. To guarantee a bijective mapping, the algorithm mandates that all contiguous numeric characters presented by the user are parsed as Base-10 and converted to Base-5 prior to encoding.

For example, a host named db-7 is mathematically translated to db-12 internally (since 7₁₀ = 12₅). If an administrator explicitly names a host db-12, it translates internally to db-22 (12₁₀ = 22₅). This universal conversion rule prevents collisions and ensures the reverse-mapping algorithm unambiguously parses the decoded Base-5 digits and converts them back to Base-10.

To maintain determinism, the algorithm calculates the precise quantity of leading zeros in the parsed Base-10 string and statically prepends them to the Base-5 output; thus, db-07 predictably translates to db-012. The protocol's string length limits apply strictly to the post-conversion string. If a 10-character hostname expands to 13 characters during Base-5 conversion, it is evaluated against the 13-character length bounds.

2.2 Addressing Semantics: Subnets vs. Mathematical Prefixes

A strict parameter of the SDA protocol dictates that a 1to1 mapping must align to a host-bit range that is a multiple of 5. The encoded bits are always aligned to the rightmost (Least Significant) boundary of the IP address space.

The protocol structurally decouples the Physical Subnet Mask from the AUTONS Mathematical Prefix. To maintain compliance with RFC 4291 [4], the physical interface and local router operate on a standard /64 boundary for IPv6. However, the mathematical addressing space defined in the AUTONS record can operate on a tighter boundary, such as a /68.

This decoupling serves two functions:

1. Bit Alignment: A /68 mathematical prefix leaves exactly 60 bits for the host identifier (60 mod 5 = 0), circumventing the 4 unaligned bits present in a standard /64 Interface Identifier (IID).
2. Namespace Multiplexing: By defining the semantics on a /68 while routing on a /64, the top 4 bits of the IID serve as a namespace identifier. This permits administrators to deploy a 1to1 namespace (e.g., prefix fd00:1::0000:0:0:0/68) concurrently with a sha256 hash namespace (e.g., prefix fd00:1::1000:0:0:0/68) on the same physical broadcast domain without overlap.

IPv6 Mapping and the ULA Expansion

SDA capitalizes on the extensive scale of the IPv6 Unique Local Address (ULA) space. An enterprise may allocate the fc00::/7 private space and segment it into two /8 mathematical networks. A /8 prefix yields 120 bits for the host identifier. At 5 bits per character, this facilitates deterministic, 1to1 mathematically encoded hostnames up to 24 characters in length.

2.3 Boundary Constraints and Reserved IPs

Standard IP architectures reserve the absolute top and bottom boundaries of a subnet host-space for control functions (e.g., the Network Address and the Broadcast Address). ZeroDNS navigates these constraints algorithmically:

• The Zero-Address Paradox (Network/Subnet-Router ID): In standard addressing, assigning the all-zeros host ID is prohibited. In the 1to1 mapping protocol, an all-zeros mathematical mapping decodes to a string of hyphens (e.g., -----). Because the decoding algorithm strips leading hyphens, the output resolves to an empty string. Since an empty string is not a valid DNS hostname, it is mathematically impossible for a valid hostname to natively map to the all-zeros Network Address or IPv6 Subnet-Router Anycast address.
• The All-Ones Paradox (Broadcast ID): Conversely, the all-ones address (used for Directed Broadcast in IPv4) maps to the binary sequence 11111, which corresponds to the digit 4 in the SDA lexicon. Consequently, an internal post-conversion string consisting entirely of fours (e.g., 4444 on a 20-bit IPv4 mapping) will mathematically generate the restricted Broadcast IP. Due to the continuous numeric conversion step, a user must input the Base-10 equivalent to achieve this sequence. Since 4444₅ equals 624₁₀, an administrator can perform a directed subnet broadcast simply by addressing 624.example.com. While this provides a unique utility, this address cannot be assigned to an individual host. Because 1to1 mapping requires perfect reversibility, applying a cryptographic salt would break decoding symmetry. Therefore, ZeroDNS enforces a strict Semantic Boundary Exclusion: hostnames evaluating to all-ones are permanently reserved for network broadcast operations and must be rejected by the provisioning engine, DHCP, or Semantic SLAAC if a single host attempts to bootstrap with them.
• The Hash Boundary Fail-Safe: When utilizing a cryptographic hash algorithm (e.g., sha256), there is a statistically minute probability that the extracted bits perfectly align with a reserved mathematical boundary (all-zeros or all-ones). Because this is a stateless mathematical certainty calculable by both the host and any resolving client, ZeroDNS enforces a Deterministic Iterative Salting rule: if any hash mapping resolves to an RFC-restricted boundary, the algorithm appends an incrementing integer (e.g., hostname\x01) and re-executes the calculation until a valid address is generated.

3. The ZeroDNS Architecture and Protocol

3.1 The AUTONS Resource Record

To bridge legacy DNS with SDA, we introduce the AUTONS DNS Resource Record. The record specifies the match pattern, mathematical network prefix, mapping algorithm, supported character length bounds, and an optional list of dynamically mimicked services.

To enable dynamic routing, prefix stripping, and exception handling, AUTONS utilizes a strict pattern-matching engine defined by Top-Down Priority Evaluation:

1. Pattern Depth Limit: A single wildcard character (*) is permitted per record, matching any sequence of characters excluding the period (.). This constraint enforces a single-label depth limit; *.example.com matches api.example.com but explicitly rejects db.api.example.com. Furthermore, this intentionally excludes the apex domain (example.com), allowing the apex to be managed by traditional DNS while ZeroDNS strictly manages subdomains.
2. Length Constraint Evaluation: Length bounds (e.g., 1-4) are evaluated as primary match criteria. If a string matches the wildcard pattern but exceeds the defined bounds, the rule evaluates as false.
3. Top-Down Priority Evaluation: To permit specific pattern exceptions without triggering wildcard overlap, resolvers process AUTONS records strictly top-down independently per address family (IPv4 vs. IPv6). Upon encountering the first successful match for a given address family, the resolver executes that record alongside any immediately consecutive records sharing the exact same match criteria (i.e., both the wildcard pattern and the length bounds). Once this contiguous block is executed for the requested record type (A or AAAA), evaluation halts. This logic allows administrators to define narrow exceptions (e.g., xn--*) that override broader catch-all wildcards, while still supporting multi-homing via consecutive identical criteria blocks without cross-family execution blocking.

Example configurations:

AUTONS xn--*.example.com fd00:4321::/68    1to1      1-12
AUTONS *.example.com     fd00:1234::/68    1to1      1-12
AUTONS *.example.com     10.16.0.0/12      1to1      1-4
AUTONS *.example.com     10.32.0.0/12      sha256    5+     mx,ad,sip,web

Prefix Stripping and IDN Support:

This priority pattern-matching structure intrinsically resolves the length constraints associated with Internationalized Domain Names (IDNs). IDNs utilize Punycode, which prepends the static string xn--. By placing the xn--*.example.com pattern at the top of the evaluation chain, the algorithm treats xn-- as a static prefix, processes the specific IPv6 subnet, and halts before hitting the broader * wildcard. During resolution, the client strips the prefix and mathematically encodes only the dynamically matched wildcard portion, preserving the 12-character constraint for the core international string.

3.2 Stateless Host Resolution and the Discovery Bootstrap

To bootstrap discovery without requiring initial recursive queries to the root domain, SDA leverages the DNS Additional Section. When a client issues a standard DNS query for api.example.com, the authoritative server internally utilizes AUTONS to calculate the IP and returns the standard A/AAAA record. Concurrently, the server appends the parent zone's AUTONS records in the DNS Additional Section of the response. The client caches these records, enabling the local ZeroDNS resolver to handle all subsequent subdomain queries statelessly.

3.3 Physical Bootstrapping: Semantic SLAAC and DHCP

To accommodate both legacy IPv4 and modern IPv6 network design, ZeroDNS supports two distinct initialization paradigms for hosts booting onto physical network segments:

IPv6 Semantic SLAAC (Zero-State Bootstrapping):

As standard DHCPv6 provides limited support for client hostname registration, ZeroDNS aligns with the stateless philosophy of IPv6 via a modified Stateless Address Autoconfiguration (SLAAC) process:

1. The local router broadcasts an ICMPv6 Router Advertisement (RA). Alongside the standard Prefix Information Option (PIO), the router includes a custom Neighbor Discovery (ND) Option containing the ZeroDNS Flag and the AUTONS ruleset.
2. The client receives the RA. Utilizing its configured hostname, it executes the AUTONS mathematical algorithm locally to generate its 64-bit IID.
3. The client appends the IID to the router's prefix and performs Duplicate Address Detection (DAD). If DAD detects a collision, the interface halts and generates an administrative alert. Because network collisions (e.g., two distinct hostnames resulting in identical hashes) are stateful events, a resolving client cannot predict them statelessly. Therefore, an algorithmic fallback is impossible, and an administrator must rename one of the conflicting hosts to generate a novel semantic mapping.

Scope and IPv6 Privacy Extensions (RFC 8981 [5]):

Because Semantic SLAAC statically binds the Interface Identifier to the hostname, a statically named device will generate an identical 64-bit IID on every ZeroDNS-enabled subnet it joins. Traditional Bring-Your-Own-Device (BYOD) clients that do not require inbound addressability preserve their privacy by ignoring the ZeroDNS RA flag and utilizing standard randomized SLAAC. If a privacy-focused client requires inbound discoverability within a ZeroDNS environment, it generates a randomized, ephemeral hostname (e.g., client-8f3a2). Randomizing the semantic input inherently randomizes the mathematical IID, satisfying privacy requirements while maintaining stateless addressability.

IPv4 Stateful Bootstrapping (Modified DHCPv4):

For IPv4 environments, a modified DHCP exchange is utilized:

1. The client transmits an L2 DHCP Discover broadcast, including its hostname (Standard DHCP Option 12).
2. A ZeroDNS-aware DHCP server intercepts the broadcast, extracts the hostname, and mathematically derives the deterministic IP address based on the domain's rules.
3. The server returns the derived IP alongside a custom DHCP Option payload containing the ZeroDNS Flag and the complete AUTONS record set.

3.4 Local State and the Logic-Based Hosts File

In highly isolated environments, air-gapped clusters, or instances of total central DNS failure, reliance on external directory authorities is prohibitive. SDA modernizes the legacy /etc/hosts file mechanism. Instead of parsing static IP-to-Hostname mappings, the local OS resolver parses injected ZeroDNS pattern rules:

AUTONS  *.cluster.local  fd00:c1a5:7e12::/68  1to1  1-12

This localized logic creates a "Serverless Name System." A single declarative rule enables a machine to resolve an unbounded number of internal endpoints statelessly, ensuring cluster communication remains fully operational offline.

3.5 Algorithmic Service Discovery (Replacing SRV, MX, and SVCB)

Traditional service discovery requires multi-stage recursive queries. Delivering email necessitates querying the MX record to retrieve a prioritized list of hostnames, followed by A/AAAA queries for those hostnames. Complex environments, such as Microsoft Active Directory and Enterprise VoIP, rely heavily on a dense hierarchy of SRV records encoding priority, weight, and port numbers. This multi-step process introduces latency, relies on external state, and breaks down entirely during directory outages.

ZeroDNS deprecates the need to maintain these complex stateful zone files through Synthetic Record Generation. By appending service flags (e.g., mx, ad, sip, web) to an AUTONS rule, the administrator authorizes the client's local OS resolver to mathematically hallucinate these records statelessly using a standardized lexicon:

• Mail Exchange (MX): Targets resolve to mx00 through mx24.
• Active Directory (AD): Domain controllers map to ad00-ad24, Global Catalogs to gc00-gc24, and Kerberos to kb00-kb24.
• Unified Communications (SIP): VoIP PBX servers resolve to sip0-sip4.
• Service Binding (HTTPS/SVCB): The web flag applies to the queried host directly, synthesizing an in-place protocol upgrade record.

The Mechanics of Synthetic Record Generation:

To ensure absolute compatibility with legacy software, applications require zero code modifications. When a legacy application (e.g., a mail transfer agent) queries the OS for the MX records of example.com, the OS DNS resolver intercepts the request. Recognizing the mx tag in the cached AUTONS rule, the resolver statelessly synthesizes a perfectly compliant DNS response array, returning mx00.example.com through mx24.example.com, algorithmically assigning incremental preference values (e.g., 10, 20, 30) based on the semantic suffix.

Complex SRV and SVCB Synthesis:

ZeroDNS handles deeper discovery protocols with equal determinism:

• VoIP and Active Directory (SRV): When a client queries _sip._tcp.example.com or _ldap._tcp.dc._msdcs.example.com, the OS dynamically generates the SRV payload locally. It synthesizes the targets (e.g., sip0 to sip4 for SIP, ad00 to ad24 for LDAP), populates the standard port (5060 for SIP, 389 for LDAP), and generates mathematically ascending priority weights. The client proceeds with its native failover logic, entirely unaware that the directory was locally synthesized.
• Modern Web Routing (RFC 9460 [6] - SVCB/HTTPS): Modern web browsers query HTTPS records to discover if a server supports HTTP/3 (QUIC) or Encrypted Client Hello (ECH) prior to initiating a TCP connection. When the web flag is present, ZeroDNS statelessly synthesizes an HTTPS record for the queried host, authorizing the browser to instantly upgrade to HTTP/3 over UDP/443, eliminating both the DNS lookup and the initial TCP handshake latency without requiring separate algorithmic routing endpoints.

The Architectural Benefits:

• Zero Application Friction: Because the translation occurs at the OS resolver level (e.g., systemd-resolved or the Windows DNS Client), enterprise applications operate natively without being aware of the underlying SDA protocol.
• Absolute Resilience: In legacy networks, if central DNS fails, Active Directory authentication and VoIP phone registration immediately collapse. With ZeroDNS, the OS synthesizes the SRV records, and calculates the IPs of the PBX or domain controllers using local math, allowing highly-coupled infrastructure to survive total DNS outages.
• State Reduction: Administrators are freed from managing fragile, dynamic SRV, MX, and SVCB zone files, dramatically flattening network topology management.

The Base-5 Cap Optimization:

The specific upper limits applied to the algorithmically mimicked services constitute an intentional optimization. For two-character prefixes (like mx and ad), capping the iterations at 24 (which translates to 44₅) ensures the suffix never exceeds two characters. For the three-character sip prefix, capping it at 4 (which remains 4₅) limits the suffix to a single character. This strict semantic boundary guarantees that the entire Algorithmic Service Discovery lexicon fits within a maximum length of 4 characters (e.g., mx44 or sip4), allowing it to operate natively within the constrained 20-bit bounds of an IPv4 /12 legacy subnet.

4. Security Benefits and the Root of Trust

4.1 Cryptographic Provenance (DNSSEC Requirement)

Because ZeroDNS shifts routing authority from centralized directories to client-side logic, the initial distribution of the AUTONS record forms the absolute boundary of trust. To prevent an attacker from intercepting the discovery query and distributing malicious mathematical prefixes, ZeroDNS implementations necessitate Domain Name System Security Extensions (DNSSEC). By cryptographically verifying the signature of the initial AUTONS payload against the root zone, the client assures the integrity of all subsequent stateless calculations.

4.2 Bidirectional Trust and the AUTOPTR Record

While mathematical symmetry allows for deterministic IP-to-hostname decoding, a SIEM or client cannot implicitly trust a decoded hostname unless the owner of the IP address space cryptographically authorizes the mapping. Without this authorization, a malicious actor could generate a mathematical IP in an untrusted subnet, decode it to db-01, and falsely assert the identity db-01.example.com.

To resolve this vulnerability, SDA introduces the AUTOPTR Record, deployed within the in-addr.arpa or ip6.arpa zones at the subnet boundary. The AUTOPTR payload conforms strictly to the AUTONS syntax, utilizing identical wildcard patterns and length bounds. However, because cryptographic hashes are inherently one-way functions, AUTOPTR records apply exclusively to 1to1 mapping algorithms. Hash-based subnets cannot be algorithmically reversed.

1.0.0.0.0.0.d.f.ip6.arpa. IN AUTOPTR *.example.com fd00:1::/68 1to1 1-12

To reverse-resolve an IP, the client queries the ARPA zone, retrieves the AUTOPTR record, verifies the mathematical prefix, decodes the host bits, and applies the parsed string to the wildcard pattern. This mechanism natively facilitates IDN reversal: an AUTOPTR rule for xn--*.example.com automatically prepends the Punycode prefix to the decoded wildcard string. When both the forward and reverse zones host DNSSEC-signed records that agree, the protocol achieves robust bidirectional trust.

4.3 Layer 2 Security and 802.1X Integration

While deterministic IPs eliminate dynamic spoofing vulnerabilities, SDA enables the creation of a cryptographically bound "Chain of Trust" down to the physical MAC address when integrated with IEEE 802.1X.

Because the IP is statically derived from the hostname, a switch acting as an 802.1X authenticator can programmatically validate the relationship. When a device authenticates its hostname and identity via a RADIUS server, the switch calculates the deterministic IP and dynamically injects a Permanent Static ARP/NDP entry into its hardware tables, mapped strictly to the authenticated MAC address. By coupling physical port authentication with algorithmic IP derivation, traditional LAN hijacking is neutralized.

5. Conclusion: IPv6 Synergy and Hash Extensibility

Semantic Deterministic Addressing (SDA) offers a performant, scalable, and deterministic alternative to recursive DNS lookups for localized and subdomain routing. By leveraging a strict 5-bit alignment protocol, decoupling physical subnets from mathematical prefixes, and executing top-down priority pattern matching via Semantic SLAAC, SDA enables stateless logic-based networking.

While the protocol supports legacy networks, ZeroDNS finds its truest expression within the expansive address space of IPv6. The default 60-bit host identifier (e.g., a /68 mathematical prefix) natively accommodates 12-character semantic hostnames, satisfying the vast majority of enterprise naming conventions through perfect 1to1 mathematical mapping. For hostnames exceeding this limit, the cryptographic hash tier provides robust fallback capacity. To guarantee absolute cryptographic consistency, the input to the hash function is never the raw ASCII string, but rather the strictly normalized Base-32 binary sequence. In a 60-bit extraction, the Birthday Paradox dictates 2³⁰ collision resistance. Thus, on a local network of 10,000 servers, the probability of an IPv6 hash collision remains statistically negligible (≈ 10^-14).

Conversely, the constrained bit-space of IPv4 mandates strict administrative discipline. In a massive /12 private subnet (yielding 20 host bits), the 1to1 mathematical mapping is capped at exactly 4 characters. Hostnames exceeding this length must fall back to the hash tier. However, applying the Birthday Paradox to a 20-bit hash space reveals that collision probabilities become statistically significant (nearing 50%) at just 1,200 hosts, and are virtually guaranteed around 4,096 hosts. While the protocol inherently relies on standard Duplicate Address Detection (DAD) alerts to allow administrators to intervene during stateful network collisions, scaling a network into frequent DAD conflicts severely degrades the zero-touch elegance of the architecture.

Therefore, organizations deploying ZeroDNS on legacy IPv4 must strictly adhere to short, 4-character identifiers for managed endpoints. Ultimately, ZeroDNS serves as a compelling architectural catalyst for enterprise IPv6 adoption, an environment where the protocol flourishes natively without artificial semantic constraints or hash-space anxiety.