YuraNetwork WHITEPAPER
Home Guide Wiki Whitepaper Privacy Downloads
Advanced architecture (public-safe)

YuraNetwork: a private namespace + routing system

This is not “a VPN with a website”. YuraNetwork combines an inside-only DNS namespace (.yura), a hard edge boundary, and a routing registry that maps private hostnames to private targets — while keeping the public internet out by default.

Install / Connect Publish a site
No secrets here: mechanisms and boundaries only. No keys, no internal lists, no private registry contents.

Executive summary: why it’s one-of-a-kind

Inside-only naming

A real DNS namespace that only tunnel clients can resolve. No public directory required.

Hard public blocking

.yura is actively blocked at the edge unless you’re in the tunnel subnet — anti-enumeration by design.

Composable routing

Built-in services (search/portal) plus user-registered private targets in private IP space.

Architecture diagram

YuraNetwork tunnel architecture diagram

1) Layered model

L3: WireGuard transport

Encrypted client↔gateway transport. Clients live in 10.77.0.0/24; gateway is 10.77.0.1.

L7: Private DNS

*.yura resolves via tunnel DNS (10.77.0.1) to the gateway. No public DNS listing is needed.

L7: Routing registry

Hostnames map to private targets (inside tunnel) or to built-in services (search/portal).

2) Privacy boundary: anti-enumeration edge control

Public internet cannot crawl .yura

At the edge, .yura is blocked unless the request originates from the tunnel subnet. This prevents external scanning, crawling, and enumeration. It’s enforced, not “discouraged”.

Discovery is internal

Discovery happens inside the tunnel via services like yurasearch.yura. The public site intentionally does not list domains or counts.

2.1) Multi-node routing pipeline (how requests actually flow)

The tunnel system is built around roles (nodes), so the boundary and routing logic is clean and auditable. This is the “first node → next node → gateway → target” idea — without exposing private inventory.

Hop 0 — Client node - tunnel client device - resolves *.yura via DNS=10.77.0.1 Hop 1 — Edge gateway node (nginx) - terminates TLS - enforces the private boundary (only tunnel subnet allowed) Hop 2 — Control/router node (Node service) - canonicalizes hostnames - consults routing registry - chooses built-in service vs registered private target Hop 3 — Service nodes / target nodes - built-in services: search / portal (inside-only) - registered targets: your machines/services inside 10.77.*
Key point: the public internet never reaches Hop 2/3 for .yura because Hop 1 blocks it.

3) Onboarding: token-based provisioning

Instead of shipping long-lived secrets inside an installer, YuraNetwork provisions tunnel configs using a short-lived token flow. This reduces blast radius if an installer is copied or inspected.

POST /api/token/generate → tokenId + tokenSecret (single-use) → unused token TTL: ~20 minutes (default) POST /api/token/connect → WireGuard config Client applies config + sets DNS to 10.77.0.1
After a token is consumed, idle sessions are cleaned up server-side (~30 minutes idle default) unless disconnected earlier.

Identifiers generated by the system

  • tokenId: UUID for one-time provisioning
  • clientName: derived label for WireGuard client config (non-sensitive)
  • publisherId: long-lived publisher identity (pub_*)
  • siteKey: per-site management key (for updates/rotation)

Design goal: identifiers support operations, while avoiding public enumeration and avoiding long-lived shared secrets in installers.

Why token TTL matters

  • Limits replay and link-sharing abuse
  • Forces fresh provisioning after time passes
  • Reduces value of leaked screenshots/logs

4) Publishing: local-first private websites

Yura Site Kit

A generated zip starts a local static server, registers a domain, and stores a site key for future runs — keeping content hosted on your machine.

Open publish flow

Routing constraints (safety)

  • Targets are private (inside 10.77.*)
  • Ports validated
  • Gateway can probe reachability before mapping

Publishing deep dive (public-safe)

Publishing is designed to keep content local while making the hostname globally usable inside the tunnel.

1) You connect and receive a tunnel IP (10.77.x.x) 2) You run a local server on your machine (static files, app, or service) 3) You register a .yura hostname to route to your private target 4) The gateway validates + routes requests to your target 5) You can update the target or rotate keys without re-installing everything
The Site Kit automates the boring parts: port selection, local server startup, registration, and saving config for repeat runs.

Why this is safer than “open a port”

  • Your origin isn’t publicly reachable
  • There’s no public DNS record to enumerate
  • Edge enforcement keeps scanners out

How you run multiple sites

  • Use multiple folders (each has its own config)
  • Each site can bind a different local port
  • Each site can have its own hostname + site key

5) Trust model: public PKI + private CA

Public portal

Standard web PKI (Let’s Encrypt) for yuranetwork.com.

Private services

Yura Root CA + CRL for .yura:

/api/ca/root.crt /api/ca/root.crl

6) Routing registry lifecycle (public-safe)

Register

A publisher registers a hostname in the private namespace and maps it to a private target (inside the tunnel subnet). The gateway can validate input (format/port/subnet) and probe reachability.

Update / rotate

Targets can be updated (e.g. IP changes), and credentials can be rotated. This supports real operations without long-lived brittle secrets.

Publisher vs Site model

Publisher - identity that is allowed to create/manage sites - can rotate publisher credentials Site - a specific .yura hostname - has a site key for authenticated management - maps to a private target (10.77.* + validated port)
Details are operationally important, but we avoid exposing real identifiers publicly.

7) Key lifecycle (publisher + site)

Publisher keys

Publisher identity is allowed to create/manage sites. Publisher keys are long-lived by design so operators can manage multiple sites without re-onboarding every time.

  • Used to generate site kits and manage site lifecycle
  • Rotation exists for hygiene (compromise containment)

Site keys

Each site has its own management key so control can be scoped. If one site key is compromised, it doesn’t automatically compromise the whole publisher.

  • Used to update targets (IP/port) safely
  • Rotation exists for per-site containment

8) Security controls (concrete, verifiable)

Hard blocks

Private namespace blocked unless inside tunnel subnet.

Gating

Admin-only / expensive operations gated to prevent abuse.

Key hygiene

Publisher/site key rotation supports real operations and compromise containment.

Threat model table (explicit)

Attacker: Public internet scanner Goal: enumerate private services Control: .yura blocked at edge unless inside tunnel subnet Attacker: Abuse actor Goal: force expensive ops / DoS Control: token-gated admin operations (e.g. search reindex) Attacker: Passive observer on public network Goal: read tunnel traffic Control: WireGuard encrypted transport Attacker: Connected member (inside tunnel) Goal: access a shared domain Reality: if a domain is shared and you are connected, access is allowed Control: access is social/organizational + domain distribution

9) Failure modes (real-world)

Client DNS points to old IP

If the client resolves yuranetwork.com to an old server IP, token connect fails. Fix: reliable DNS (1.1.1.1 / 8.8.8.8) + flush cache.

Gateway not bound to tunnel IP

If nginx isn’t listening on 10.77.0.1:443, inside-only services won’t load. Fix is server-side binding.

This whitepaper is intentionally detailed but public-safe. If you want, we can add a formal “Guarantees & limitations” section and a glossary for operators.