Reference

Architecture

How xdns.wtf turns DNS, CDN, edge compute, and bucket storage into a portable application delivery system.

Overview

The target model is simple: buckets hold durable application artifacts, while DNS and the edge turn those artifacts into browser-delivered software systems.

DNS hostname
  -> CDN / edge entrypoint
  -> xDNS Gateway runtime
  -> manifest or control-plane lookup
  -> bucket object or compute handler
  -> browser response

The browser still sees a normal website or application. What changes is the packaging model: the substrate is object storage, and the delivery and compute semantics live at the gateway layer.

Primary request flow

1.  Browser requests https://app.example.com/path?q=1

2.  DNS points hostname to xDNS edge
        CNAME / A / AAAA / TXT-discovered manifest

3.  CDN / edge terminates TLS at the nearest PoP

4.  Gateway runtime receives Host + Path
        Host: app.example.com
        Path: /path

5.  Gateway resolves host -> site config
        - control-plane binding in D1
        - or TXT-discovered manifest
        - or future decentralized pointer

6.  Route match:
        - static object
        - compute handler
        - redirect
        - SPA fallback

7.  Storage or compute execution:
        - fetch object from bucket / storage root
        - or run Request -> Response function
        - or proxy to compatible upstream

8.  Stream response back to browser

Stack

Layer	Technology	Purpose
DNS	Cloudflare zone + custom domain bindings	Hostnames map traffic into the edge entrypoint.
CDN / edge	Cloudflare edge + Workers	TLS, host/path routing, request compute, cache, redirects.
Gateway runtime	xDNS Gateway	Resolve host -> manifest -> route -> static object or compute response.
Storage substrate	Storj / S3 / R2 / MinIO / future IPFS	Durable storage for assets, manifests, bundles, and app state.
Control plane	Worker API + D1	Domains, provider bindings, desired DNS records, gateway manifests.
Framework layer	Hono / Nitro / Next.js / static export	Optional higher-level packaging above the portable request primitive.

Data model

The control plane is broader than the original wildcard proxy and centers on a few durable records:

Object	Type	Constraints	Description
`tenants`	table	legacy live path	Existing *.xdns.wtf slug -> upstream origin proxy.
`provider_accounts`	table	encrypted secrets	DNS / registrar provider credentials and config.
`domains`	table	unique domain	Custom domain verification, activation, and lifecycle state.
`domain_provider_bindings`	table	1 active binding per domain	Maps a domain to its upstream DNS provider account.
`dns_records`	table	desired or remote state	Normalized DNS records for reconciliation and sync.
`gateway_sites`	table	unique hostname	Hostname -> xgate manifest or routing configuration.

Security

Storage does not imply blind origin trust

Route targets and proxy origins still need SSRF controls, path sanitization, and explicit fetch boundaries. Treat manifests and storage roots as configuration, not as unrestricted network access.

Provider credential isolation

Provider accounts are control-plane objects with encrypted secrets. They should be isolated per operator or per environment, not shared broadly across unrelated domains.

Domain verification before activation

A hostname should not become live in the gateway until ownership has been proven through TXT or equivalent validation and the control plane has marked the domain active.

Edge policy enforcement

The edge layer is the right place for auth gates, rate limiting, cache policy, canonical redirects, preview environments, and abuse controls before requests ever hit origin storage.

Legacy compatibility

The original wildcard proxy remains a valid product tier. It is simply the narrowest instantiation of the broader architecture:

*.xdns.wtf
  -> edge worker
  -> D1 tenant lookup
  -> upstream origin proxy

This is still useful, but xDNS Gateway generalizes the same pattern to:
  custom domains
  bucket-backed apps
  manifest-based routing
  edge compute over object storage

Deployment

Control planeWorker API and D1 manage domains, providers, records, and gateway manifests.

Gateway planeThe same edge runtime can serve active custom domains, fetch static bucket content, and run request compute for matching routes.

Storage planeBuckets and storage roots remain replaceable. Public host contracts should not change when moving from one S3-compatible backend to another.