TrantorZero infrastructure
No coordination server, no relay nodes. Trantor reuses the DNS infrastructure you already pay for.
Most private networking solutions rely on dedicated infrastructure: a central coordinator (Tailscale, ZeroTier), public relay nodes (Tor), or static endpoints (WireGuard). Trantor takes a different route: it stores encrypted connection metadata in the global DNS, so a client with the right passphrase can discover and reach a server with no third-party broker in between.
The result: a server that publishes nothing observable. No open ports to scan, no identifiable traffic to fingerprint, no central infrastructure to compromise. Connections look like ordinary HTTPS, and the DNS lookups that find them look like ordinary TXT queries.
Features
DNS-based control plane
Encrypted TXT records carry IP, certificate, and ECH configuration. Indistinguishable from SPF, DKIM, or DMARC traffic.
Stealth by default
Server IPs never appear in cleartext. Blocking Trantor would require breaking DNS for everyone.
Argon2id key derivation
Passphrases are stretched with 64 MB of memory-hard hashing before they ever touch the network.
Auto-rotated secrets
The master passphrase rotates every 90 days. Revoking a user passphrase regenerates it on the spot.
Multi-platform clients
Daemon for Linux, Windows and macOS, with tray GUI. Mobile apps on iOS and Android.
Encrypted Client Hello
Optional ECH integration hides the SNI field. The TLS handshake leaks no domain name to observers.
Open source (MIT)
Server, client, GUI, mobile apps — all open. No commercial entity, no telemetry, no lock-in.
Three levels of protection
Trantor secures up to three aspects of a connection, depending on the server configuration.
1IP address
Always encrypted in DNS. Only passphrase holders can resolve a server's address — even for plain HTTP services. The IP never appears in cleartext on any public record.
2TLS certificate
Forged deterministically by client and server from shared parameters. No certificate authority, no trust anchor outside the passphrase. The certificate exists nowhere on disk until both sides derive it.
3SNI (domain name)
Hidden via Encrypted Client Hello (RFC 9849). The client daemon serves the ECH config locally, so the browser encrypts the SNI without querying any external server.
How it works
1
Server publishes
trantor encrypts the IP, certificate, and ECH config under a master passphrase, and writes them as TXT records to the chosen domain.
2
Client resolves
terminus hashes the user passphrase, queries DNS, decrypts the records, and forges the same certificate locally.
3
Direct TLS
Your browser connects to the server over standard HTTPS. SNI is encrypted via ECH. The traffic looks like any other HTTPS request.
Use cases
Distributed teams
Application servers reachable only by team members holding the right passphrase. No VPN client mismatch, no exposed admin endpoints, no public ingress.
Censorship resistance
Blocking Trantor would mean blocking DNS TXT queries — which would also break email validation, domain ownership proofs, and MTA-STS.
Journalists & researchers
Connect to a source's server without leaking metadata to ISPs or middleboxes. The TLS handshake itself reveals nothing about the destination.
Zero-trust, no controller
Same network model as Tailscale or ZeroTier, but without a central coordinator that would become a single point of compromise.
Quick start
# Server side
sudo trantor init --domain foo.bar.com --provider cloudflare
sudo trantor passphrase add --domain foo.bar.com --name "team-alpha"
sudo trantor publish --domain foo.bar.com
# Client side
sudo terminus start
# Add the domain via the tray GUI or config file, then:
# Open https://foo.bar.com in your browser — you're connected.Part of the Digicreon ecosystem
Trantor stands on its own — but it shares its tooling with three other open-source projects.