Register a domain anonymously: WHOIS privacy and what still leaks

What redaction actually removed

In 2018 the registration record for most domains went blank. GDPR arrived, ICANN told registrars to stop publishing registrant names, addresses, phone numbers and emails in public WHOIS output, and a lookup that used to return a person started returning REDACTED FOR PRIVACY and a contact form. It reads like privacy. It is a display setting.

Underneath, nothing moved. Your registrar still holds the full record, is still required to hold it under its accreditation, and still hands it over to anyone with standing to ask — a court order, a law-enforcement request, and in practice something far cheaper. A UDRP complaint costs a few thousand dollars, needs no judge, and triggers a registrar verification step that discloses the underlying registrant to the complainant before the case is even decided. That is the unmasking route almost nobody models, and it is the one a trademark holder reaches for first.

Two other things survived the redaction. The first is history: commercial archives snapshotted WHOIS for two decades and those snapshots do not expire, so a name registered before 2018 with real details is permanently exposed no matter what the record says today. The second is the rest of your own configuration — the nameservers you picked, the address buried in your SOA, the DMARC reporting mailbox, every certificate you have ever requested. Redaction blanked one field and left four others publishing, and those four are where this guide spends most of its time.

Pick the extension before you pick the registrar

Registrar policy is downstream of registry policy, and registry policy is downstream of where the registry company happens to be incorporated. A registrar can promise whatever it likes about privacy; it cannot promise more than its registry permits, and neither of them can promise anything about a court in the registry's own jurisdiction. So the order matters, and most people get it backwards: choose the extension first, then choose who sells it to you.

Three properties separate extensions. Where the registry operator sits decides whose courts can order a name suspended at the root — for the large legacy gTLDs that is the United States, which is why a .com held by someone with no US presence at all can still be seized on a US order, and why your own jurisdiction matters far less than you would hope. What the registry publishes by default varies enormously: some ccTLD registries redact more than gTLDs do, others print a registrant name for anyone who asks, and a few require a verified local presence you could only satisfy with a real identity. Whether privacy services are permitted at all is a registry rule rather than a registrar feature — a handful of extensions forbid proxy registration outright, and a registrar that sells you privacy on one of those will simply have it stripped later.

None of that is stable enough to memorise, and any list of "privacy-friendly TLDs" you find online is partly wrong by the time you read it. Check it yourself instead: step two runs the lookups that answer all three questions for any extension you are considering, using a domain you do not own. Run them before you pay, because a bad extension cannot be fixed by transferring registrars. It can only be fixed by starting again on a different name.

Three registrar models, and what each one survives

Strip the marketing and there are three arrangements on offer. In the proxy model you are the registrant and the registrar publishes its own contact details in place of yours. Your data is already in the registrar's database, the redaction is cosmetic on top of a complete record, and the proxy provider's own terms almost always reserve the right to reveal you on a "reasonable" third-party request. It defeats scrapers and data brokers completely. It defeats nothing that arrives with a lawyer.

In the owner-of-record model — the arrangement Njalla made popular — the provider registers the name in its own name and grants you a contractual right to use it, so your identity never becomes the registrant at all. There is nothing in the registry to disclose because there is nothing there. The trade is real and worth stating plainly: you do not legally own the domain. You are relying on one company's solvency, its appetite for resisting a request, and its continued interest in the business. If it folds, is acquired, or decides you are more trouble than you are worth, your recourse is a contract dispute over an asset registered to somebody else.

The third arrangement is a clean registrant identity of your own: a real registration in a handle with no history, on an inbox that exists for nothing else, paid in crypto, at a registrar in a jurisdiction unrelated to your host and to you. It scales past one domain, it depends on no single company's goodwill, and it is what the rest of this guide builds. It also fails hardest if you are careless, because everything rests on that identity never being correlated with you somewhere else — the failure mode the ownership guide walks through layer by layer. The two models combine well, incidentally: an owner-of-record registration bought from a clean identity is stronger than either on its own.

The signup form: what you can refuse, what will suspend you

The form asks for a name, a postal address, a phone number and an email. Three of those are contract data the registrar is required to hold and will almost never verify. One of them is load-bearing. The email is the one that matters: under the registrar accreditation agreement the registrant address has to be verified after registration, and if nobody clicks the link the domain is suspended — usually within fifteen days. A throwaway inbox that stops existing takes the domain with it.

So the address must be an alias you genuinely control and will still be reading in three years, at a provider that does not demand a phone number to open an account and will not close it for inactivity. Everything else on that form is a consistency problem rather than a truth problem: choose a plausible set of details, store them encrypted, and use exactly the same ones at the registrar, in the account profile, and in any support ticket you ever open. Inconsistency is what routes an account into manual review, and manual review is where a human starts asking for documents.

Then pay from a rail that carries no legal name into the record. A card defeats the whole exercise whatever the WHOIS says, because the processor's record outlives the registration and is trivially subpoenaed; the anonymous payment guide ranks the options by what each one leaks. If the registrar takes Monero directly, that is the clean path. If it only takes Bitcoin, treat the payment as permanently traceable and fund it accordingly. If it takes neither, the registrar has told you something useful about the customers it wants.

DNS is the second registration

The moment you publish a zone you republish yourself, in fields nobody thinks of as identity. The SOA record carries an email address encoded with its first dot standing in for the @, and hand-written zone files routinely carry a real one. The nameserver names are a fingerprint: point two domains at the same custom nameservers and you have linked them permanently, in a dataset that reverse-nameserver search engines index and keep. And when those nameservers live inside the domain itself, the registry publishes glue records — their IP addresses, in the root zone, beyond the reach of any CDN you put in front of the site. People spend a week hiding an origin and then hand out its address in a glue record.

DNSSEC deserves a specific warning, because it is sold as a security feature and behaves like a disclosure one. Signing a zone with NSEC publishes a linked list of every name in it, walkable by anyone in seconds. NSEC3 hashes the names instead, which sounds better and only raises the price: the hashes are crackable offline and there are tools that do nothing else. Sign the zone if you want authenticated answers, and go in understanding that you are not hiding your subdomain list. You never were.

Where the zone is served is a separate decision from who registered the name, and splitting them across two companies in two countries is worth more than either choice alone. Running your own nameservers buys control and a small, distinctive fingerprint; using a large provider's buys anonymity in a crowd and a company that logs every query and will answer a request about it. There is no free option here, only a choice about which record you would rather exist. If the site behind the zone sits behind an edge, the origin-IP guide covers the rest of that chain.

The leaks that arrive after signup

Certificate transparency is the big one. Every publicly-trusted certificate is written to a public, append-only, permanently searchable log, so every name you have ever asked a CA to sign is discoverable — including the staging., vpn. and old- hosts you assumed nobody knew about, and including the internal name you issued by accident once and deleted the same afternoon. You cannot retract a log entry. The only control is upstream: request a wildcard over DNS-01 validation so individual hostnames never enter a log at all, and keep genuinely private names on an internal CA that logs nothing.

Mail publishes two more. An SPF record names the relay you send through. A DMARC record usually names a human, because rua= is where the reports go and people put their real mailbox there. And an MX pointing at the machine that also serves the site hands the origin address to anyone who runs one query — mail is the single most common way an origin escapes from behind an edge.

The last category is correlation, and it is what undoes otherwise careful work. The same nameserver set across two personas links them. So does one certificate covering both names, the same analytics identifier, the same favicon — internet-wide scanners index favicon hashes precisely because they fingerprint so well — the same unusual response header, the same registrar at the same hour of the same night. Any one of those is weak evidence. Three together are not. Steps four and six run the searches an adversary would run, against your own domain, which is the only honest way to learn what you actually published.

Renewal, transfer, and the year-three failure

Anonymous domains rarely die from a subpoena. They die from an expired registration. The alias inbox stopped being read, the renewal notice bounced, the balance ran dry, and a name that took a year to build dropped into the pool where a drop-catcher was waiting. Turn on auto-renew, keep enough credit at the registrar to cover several years, and put the expiry date into whatever alerting you actually look at — step seven pulls it straight from the registry, so the reminder does not depend on the mailbox most likely to fail.

Locks are the other half, and they are free. clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited take one click each and shut down the entire class of attack that begins with somebody getting into your registrar account. Some registries also offer a registry lock, which requires an out-of-band confirmation before anything changes and is worth paying for on a name you cannot afford to lose. Keep the transfer authorisation code encrypted and offline, and know that changing the registrant contact triggers a sixty-day transfer prohibition — so do that housekeeping when you are not in a hurry, never in the middle of an incident.

Then plan for the version of this where you are not available. A domain held on an anonymous identity has no probate, no support ladder and no proof of ownership beyond the credentials themselves, which makes an encrypted copy of the account details, the recovery codes and the auth code — stored where someone you trust can eventually reach it — the only thing standing between a long-lived project and a dead name. The same logic applies to the machine behind it: an off-site encrypted backup nobody can restore is a backup you do not have.

A realistic threat model

Be precise about what this defeats. Against scrapers, data brokers, competitors, open-source researchers and the opportunist who pivots from one of your names to all the others, a clean registrant identity with a leak-free zone works, and it works completely — there is nothing in the public record to pivot from. Against a civil claimant it raises the cost from a free lookup to a legal process, which is a real and often decisive difference. Against a UDRP filed by a trademark holder, the proxy model gives you very little, and the owner-of-record model gives you a company that has to decide how hard it wants to fight on your behalf.

Against a state with jurisdiction over your registry it does not win, and no arrangement of registrars does: the name can be suspended at the root regardless of who holds it. That is an argument for choosing the extension deliberately and for owning your content well enough to move it, not for a cleverer registrar. And against your own mistakes it offers nothing at all. One login from a personal browser profile, one support ticket written in your usual voice from your usual address, one certificate covering both personas, and the record you spent this guide keeping clean is stitched back together in an afternoon.

Build to the adversary you actually have. For most people the honest answer is brokers and opportunists, and closing the records in steps five and six is enough. If your exposure is higher, remember the domain is one layer of several: pair it with a host that never asked who you are, a machine hardened on day one, and payment that carries no name. Privacy is a chain, and every guide here describes a different link of the same one.

Step by step

1. 01

   Audit what the name already publishes

   Start with the domain you have, or with one you are about to buy from someone else. RDAP is the machine-readable registration service that replaced port-43 WHOIS for gTLDs, it speaks JSON over HTTPS, and rdap.org will bootstrap you to the right registry. Many ccTLDs still answer only on port 43, and several of them publish more than a gTLD would.

   # gTLDs: RDAP is the authoritative registration record
   curl -s https://rdap.org/domain/example.com | jq '{
     status,
     ns:     [.nameservers[]?.ldhName],
     events: [.events[] | {(.eventAction): .eventDate}],
     roles:  [.entities[]?.roles[]?]
   }'
   
   # the fields that are supposed to be blank -- read them, do not assume
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | select(has("vcardArray")) | .vcardArray[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr")
              | "\(.[0]): \(.[3])"'
   
   # ccTLDs: many are port-43 only, and less redacted than you expect
   whois example.de | grep -viE '^%|^$'

   If a real name, a real address or a personal email comes back, stop here: transferring the domain will not erase it, because the archives already have it. That name is burned for privacy purposes and the honest move is to register a fresh one and redirect.

2. 02

   Test the extension before you commit to it

   Compare candidate extensions empirically rather than from a blog post. Look up a domain you do not own in each one and read what the registry actually returns, then check who operates that registry and where. Output shapes differ between registries, which is exactly why this is worth running rather than assuming.

   # what does each registry publish about a registrant?
   for d in example.com example.de example.is example.nl; do
     printf '\n== %s\n' "$d"
     curl -s "https://rdap.org/domain/$d" \
       | jq -r '.entities[]? | "\(.roles|join(",")): \(
           [.vcardArray[1][]? | select(.[0]=="fn")][0][3] // "redacted")"' \
       2>/dev/null || whois "$d" | grep -iE '^(registrant|owner|admin-c)'
   done
   
   # who runs the registry, and under whose law does that company sit?
   curl -s https://www.iana.org/domains/root/db/is.html \
     | sed -n 's/.*Organisation:*//p;/Registry Information/,+6p' | head -20

   Three answers decide it. Does the registry publish a registrant name by default? Does it demand a verified local presence? And whose courts reach the registry operator? Anything requiring a local presence is out unless you can satisfy it truthfully, and anything whose operator sits in a jurisdiction you are specifically avoiding is out no matter how good the registrar looks.

3. 03

   Build the identity before you open the account

   Generate the identity in one sitting and write nothing down in plaintext. The handle should carry no history — not a nickname you have used elsewhere, not a word with meaning to you. The inbox should be an alias at a provider that does not require a phone number, and it needs to survive three years of neglect, because the registrar's verification mail and every renewal notice land there.

   # a handle with no history and no meaning
   head -c 10 /dev/urandom | base32 | tr -d '=' | tr 'A-Z' 'a-z'
   
   # a key for the secrets this account is about to hand you
   age-keygen -o registrar.key            # public key is printed on stderr
   
   # store profile details, recovery codes and (later) the auth code
   age -r age1... -o registrar.age registrar.txt && shred -u registrar.txt
   
   # read it back only when you need it
   age -d -i registrar.key registrar.age

   Use a browser profile that has never touched a personal account, and reach the registrar over the same network path every time — mixing a home connection and a VPN across sessions is more distinctive than consistently using either. Record the exact profile details you submit; you will need to repeat them verbatim in a support ticket two years from now.

4. 04

   Register, then look at yourself as a stranger

   Register the name, click the verification link the same day, and then wait for the record to propagate to the registry before you check it — the interesting output appears a few hours later, not immediately. What you are looking for is any field that did not get redacted, and the status codes that tell you the verification actually completed.

   # the public record, 24h in
   curl -s https://rdap.org/domain/example.com | jq '{status, events}'
   # expect: "active" -- NOT "pendingVerification" or "clientHold"
   
   # anything at all that survived redaction
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | .vcardArray? // empty | .[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr" or .[0]=="tel")
              | "\(.[0]): \(.[3])"'
   
   # and the archive view: does this name have a past you did not buy?
   curl -s 'https://crt.sh/?q=example.com&output=json' \
     | jq -r '.[] | "\(.not_before)  \(.name_value)"' | sort -u | head -20

   A clientHold or pendingVerification status a week later means the verification mail never arrived or never got clicked, and the domain is on a countdown to suspension. Fix that before anything else — it is the single most common way a correctly registered anonymous domain is lost in its first month.

5. 05

   Publish a zone that does not name you

   Now the part that leaks most and gets checked least. Read your own zone the way a stranger reads it: the SOA address, the nameserver names, the glue the registry publishes on your behalf, and whether anyone can simply download the whole thing.

   # SOA -- the second field is an email, first dot standing in for @
   dig +short SOA example.com
   # ns1.example.com. hostmaster.example.com. 2026090601 7200 3600 1209600 3600
   #                  ^-- must not be a personal address
   
   # glue: if your nameservers live inside the domain, the ROOT holds their IPs
   dig +norec +short NS example.com @a.gtld-servers.net
   dig +norec +short ns1.example.com A @a.gtld-servers.net
   
   # can anyone download the entire zone?
   dig AXFR example.com @ns1.example.com | head
   # want: "Transfer failed" -- anything else is your full host inventory
   
   # pin issuance to one CA, and give abuse somewhere impersonal to land
   dig +short CAA example.com
   # 0 issue "letsencrypt.org"
   # 0 iodef "mailto:abuse@example.com"

   Fix in this order: replace the SOA address with a role mailbox at the domain itself, move nameservers outside the domain (or off your own machine entirely) so no glue is required, refuse AXFR from anything but your secondaries, and add a CAA record. If you sign with DNSSEC, use NSEC3 and accept that your subdomain list is still enumerable by anyone willing to spend an hour on it.

6. 06

   Close the certificate and mail leaks

   Two public datasets know more about your infrastructure than your DNS does. Certificate transparency knows every hostname you have ever had signed; your own mail records name your relay, your reporting mailbox and frequently your origin. Enumerate both against yourself.

   # every name you have ever asked a CA to sign, including deleted ones
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | jq -r '.[].name_value' | tr ' ' '\n' | sort -u
   
   # the mail records, read for identity rather than deliverability
   dig +short TXT example.com          # SPF include: names your relay
   dig +short TXT _dmarc.example.com   # rua=mailto: usually names a human
   dig +short MX  example.com          # an MX on the origin IS the origin
   
   # does the site answer on its own address, ignoring the edge?
   curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1

   Move future issuance to a wildcard validated over DNS-01 so hostnames stop entering the logs, point rua= at an address on the domain rather than a personal mailbox, and move mail off the origin — a relay or a separate machine, never the box the site runs on. Names already in the logs cannot be withdrawn; retire them or accept that they are public forever.

7. 07

   Lock it, monitor it, and plan for your absence

   Last: make the registration hard to move and hard to forget. The three client locks are free and stop the whole class of attack that starts inside your registrar account. The expiry date belongs in your alerting rather than in an inbox you may stop reading.

   # what the registry says about locks and dates
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.status[], (.events[] | "\(.eventAction) \(.eventDate)")'
   # want: clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited
   
   # days until expiry, straight from the registry -- no email involved
   exp=$(curl -s https://rdap.org/domain/example.com \
         | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate')
   echo $(( ( $(date -d "$exp" +%s) - $(date +%s) ) / 86400 )) days left
   
   # keep the escape hatch encrypted and off the machine it protects
   age -r age1... -o auth-code.age auth-code.txt && shred -u auth-code.txt

   Run that expiry check from cron and alert at ninety days. Store the encrypted bundle — account details, recovery codes, transfer auth code — somewhere reachable by a person you trust, because an anonymous domain has no probate and no support ladder. Then re-run steps four through six once a year: zones drift, certificates get issued by people who forget, and the leak you closed in January is usually back by autumn.