Comparison

Overview #

Trantor sits in the same problem space as VPNs, mesh networks, and anonymity overlays — connecting two parties privately across an untrusted network. But it solves the problem from a different angle: instead of running infrastructure (relays, coordinators, gateways), it stores encrypted connection metadata in the existing DNS, and lets passphrase holders discover servers without any third-party broker.

This page compares Trantor with the most common alternatives, on the criteria that usually drive the choice.

Feature comparison #

Criterion Trantor Tor Tailscale / ZeroTier WireGuard
Infrastructure required Existing DNS only Public relay nodes Coordination server Static endpoints
Stealth Invisible [1] (looks like SPF/DKIM) Identifiable (public guard nodes) Visible to controller Identifiable (UDP port, DPI)
Censorship resistance High — blocks would break DNS at large Medium — many guards are blocklisted Low — block the controller, kill the network Low — block the IP / port, done
Resilience Distributed global DNS Thousands of independent nodes Central controller Point-to-point
Attack surface No port, no identifiable server Known nodes, malicious exits, traffic correlation Controller is a compromise point Exposed UDP port
Performance Direct (minimum latency) Triple-hop, slow Direct (STUN/ICE) Direct, fast
Setup complexity Low — no server to host Medium — depends on use case Medium — controller account Low — keys + endpoints
Open source MIT 3-clause BSD Mostly open, controller proprietary GPL-2

Blocking Trantor would require blocking DNS TXT queries altogether, which would also break SPF, DKIM, DMARC, MTA-STS, domain ownership proofs, and a long list of other internet plumbing. That makes Trantor expensive to censor without collateral damage.

[1] Stealth applies to the default standard mode (each user holds a passphrase). Trantor also supports an opt-in empty-passphrase mode that trades stealth for public reachability — see deployment modes.

Trantor vs Tor #

Tor and Trantor solve adjacent — but distinct — problems.

  • Threat model — Tor protects the identity of the client from the server. Trantor protects the existence and identity of the server from observers. They are complementary rather than competitors.
  • Performance — Tor's three-hop circuit adds significant latency. Trantor connections are direct over standard HTTPS, with the same performance as any other web request.
  • Detectability — Tor traffic patterns are well-known and Tor guard nodes are publicly listed. Trantor traffic is indistinguishable from ordinary HTTPS plus DNS TXT lookups.
  • Use case — Tor is the right tool for anonymous browsing of the public web. Trantor is the right tool for connecting to your own servers privately.

Trantor vs Tailscale / ZeroTier #

Tailscale and ZeroTier are the closest match to Trantor's intent: zero-config private networking for your own machines. The trade-offs:

  • Coordination — Both rely on a central coordinator (the Tailscale or ZeroTier service). If that controller is compromised or goes dark, the network breaks. Trantor has no controller — DNS is the meeting point, distributed and operated by the rest of the internet.
  • Visibility — Coordinators see metadata: who connects to whom, when, from where. Trantor publishes nothing about clients. The DNS only sees a hashed lookup that reveals neither the user nor the server.
  • Trust — Tailscale and ZeroTier require trusting a commercial entity with the membership graph. Trantor requires trusting the passphrase distribution channel only.
  • NAT traversal — Tailscale and ZeroTier handle NAT punching via STUN/ICE, which Trantor does not provide today. If both peers are behind symmetric NATs, Trantor relies on the server having a routable address.

Trantor vs WireGuard #

WireGuard is a lower layer than Trantor — a kernel-grade tunneling protocol, not a discovery system.

  • Discovery — WireGuard requires that you already know the server's IP address and public key. Trantor solves the discovery problem — clients find the server through encrypted DNS records.
  • Traffic profile — WireGuard exposes a UDP port on a known endpoint. DPI tools and port scanners can flag the traffic. Trantor connections look like standard HTTPS.
  • Layer — WireGuard tunnels arbitrary IP traffic. Trantor secures application-level (HTTPS) connections to specific domains.
  • Combine them — WireGuard and Trantor can stack. You can publish a WireGuard endpoint via Trantor: peers discover the IP and key through DNS, then bring up a WireGuard tunnel.

When to choose Trantor #

Trantor is a good fit when:

  • You want a server reachable only by passphrase holders, with no exposed admin endpoint or open port to scan.
  • You need infrastructure independence — no controller, no relay network, no commercial entity in the trust path.
  • You operate in a censored or restricted network and need traffic that blends with ordinary HTTPS and DNS.
  • You want cryptographic deniability on the server side — there is nothing publicly tied to the server's identity until a client decrypts the records.

Trantor is not the right tool when you need anonymous client identity (use Tor), full-OS tunneling for arbitrary protocols (use WireGuard), or a managed mesh with centralized policy (use Tailscale).