Frequently asked questions

DNS is the only globally distributed, always-on, always-allowed directory on the internet. Every connected device queries it, every network operator routes it, every firewall lets it through. That makes DNS the perfect carrier for tiny, encrypted control messages: a server can publish its IP, certificate, and ECH config as TXT records, and a client anywhere on the internet can pull them.

The traffic profile is also indistinguishable from legitimate uses: SPF, DKIM, DMARC, domain ownership proofs, and other widespread protocols all use DNS TXT records. A Trantor lookup looks like one of those.

No — Trantor connections ride on standard TLS. The traffic between client and server is plain HTTPS, encrypted under TLS like any other website. What is specific to Trantor is how the certificate that protects the TLS session is established: client and server independently forge identical ECDSA P-256 certificates from parameters derived from the master passphrase. An attacker without the passphrase can capture the bytes on the wire but cannot derive the session keys.

The threat model for the data channel is therefore the same as for any modern HTTPS site: as long as TLS itself is not broken and the passphrase is not leaked, the data stays confidential and integrity-protected. Trantor adds a layer around standard TLS (encrypted discovery, encrypted SNI via ECH) — it does not weaken the TLS layer itself.

User passphrases are processed through Argon2id with 64 MB of memory, before any DNS lookup happens. The DNS record name is derived from that hash, so an attacker without the passphrase cannot even point at the right TXT record — they would have to brute force the DNS resolver itself.

Once a record is retrieved, decryption uses AES-256-GCM with a key derived through the same Argon2id parameters. The combination makes offline brute force impractical at scale: each candidate guess costs ~64 MB of RAM and significant CPU.

No — defeating impersonation is one of the things the deterministic certificate forging is designed to do. Each known impersonation vector fails for the same underlying reason: the attacker doesn't have the master passphrase, so they cannot produce the certificate the legitimate server holds.

• Compromised DNS provider or on-path DNS tampering. An attacker who replaces the encrypted TXT records with their own can publish whatever IP and certificate parameters they want. But the client doesn't trust those parameters blindly: it forges its own certificate from the parameters combined with the master passphrase. Without the master passphrase, the attacker's parameters cannot lead to a certificate whose private key matches the server's. The TLS handshake fails — the worst case is denial of service, never silent MITM.
• Network-level MITM (BGP hijack, malicious ISP). Same outcome. The attacker can route traffic to their own IP, but they don't have a TLS certificate the client will accept — that certificate has to derive from the master passphrase, which never travels in cleartext and never appears outside passphrase holders' machines.
• Phishing via a different hostname. If an attacker convinces a user to add evil.example.com to their Trantor config with a passphrase the attacker controls, the user has effectively trusted a different server. This is social engineering, not a Trantor protocol failure — distributing passphrases through trustworthy channels is part of any deployment.

DNSSEC (where supported) and DoH/DoT are recommended as defense-in-depth: they prevent attackers from causing denial of service through DNS tampering, but the certificate forging defeats impersonation regardless.

Without ECH, the SNI field of the TLS handshake leaks the destination domain in cleartext to anyone watching the network. Trantor protects everything else, but the SNI itself is a TLS-level field — it has to be encrypted at the TLS layer, which is what ECH (RFC 9849) does.

ECH support is rolling out: Firefox 119+ supports it natively, Chrome supports it behind a flag, Safari has partial support. If your browser doesn't support ECH, Trantor still encrypts the IP and forges the TLS certificate locally — only the SNI remains visible. The level-3 protection (domain name) is optional; levels 1 and 2 always apply.

Trantor uses a two-tier system. The server holds a master passphrase (256-bit random) that encrypts the actual connection data. Each user passphrase is stored as its own DNS record containing the master passphrase, encrypted with that user's key.

Revoking a user passphrase regenerates the master passphrase, re-encrypts and republishes all remaining user records, and deletes the revoked one. Existing users notice nothing — their next refresh picks up the new master transparently. The revoked user loses access immediately, because their record has been deleted from DNS and the new master is not encrypted under their key.

Not by passively observing the network. The TLS handshake looks like ordinary HTTPS, the SNI is encrypted via ECH (when supported), and the server doesn't expose any Trantor-specific port, banner, or response pattern. From the outside, a Trantor-served site is indistinguishable from any other HTTPS site.

On the DNS side, the records that describe a Trantor domain are stored under names derived from Argon2id-hashed passphrases — there is no fixed prefix or recognizable pattern. An observer cannot enumerate Trantor-managed hostnames without already holding a passphrase. What the observer can see is that a given DNS zone publishes some TXT records, but TXT records are everywhere (SPF, DKIM, DMARC, domain proofs, ACME challenges), so their mere presence reveals nothing.

An attacker who already holds a valid passphrase for a domain can of course derive the record name and confirm that the domain is Trantor-managed — but at that point the attacker is an authorized user, not an outsider.

To block Trantor reliably, a network operator would need to block DNS TXT queries to arbitrary domains. That is technically possible — but it would also break:

• SPF, DKIM, DMARC (email anti-spam)
• Domain ownership proofs used by certificate authorities
• MTA-STS, BIMI, and other email-related TXT records
• DKIM key publishing for outgoing mail
• Most Let's Encrypt DNS-01 challenges

For most networks, the operational cost of blocking TXT records is far higher than the value of blocking Trantor specifically. Targeted blocking of a single Trantor domain requires inspecting every TXT response — feasible at small scale, expensive at internet scale.

A traditional VPN gives you a tunnel over an explicit, well-known endpoint: an IP address, a port, often a known protocol (OpenVPN, WireGuard, IPsec). Network observers can see that you have a VPN connection, even if they can't see the contents.

Trantor doesn't tunnel anything. It tells your client where the server is, lets you forge the same TLS certificate the server uses, and stays out of the way. The traffic on the wire is plain HTTPS to a domain you happen to know, indistinguishable from any other web request. There is no VPN endpoint to see.

No. The master passphrase exists in two places only: in memory on the server, and in memory on each authorized client after decryption. It is never transmitted in cleartext or in any reversible form.

What travels over DNS is each user's record, which contains the master passphrase encrypted under that user's derived key. An observer sees only ciphertext. A user who decrypts it learns the master passphrase but not the underlying user key — the master is symmetrically encrypted, not signed.

Nowhere central. The server runs on whatever machine you choose — a VPS, a home server, a colocation rack. The DNS records live in whatever DNS provider you use (Cloudflare, Route53, Gandi, or any DNS host that exposes an API). The clients run on the user's machines. There is no Trantor infrastructure in the loop. There is no Trantor company in the loop.