What an “empty” WHOIS really means #

Since January 28, 2025, RDAP is the definitive source for registration data of generic domains, replacing WHOIS. A public result with “REDACTED” or nearly empty fields usually means publication was limited; it doesn't mean the data stopped existing.

ICANN's policy in effect since August 21, 2025 allows or requires redaction of personal data in certain situations, but it also provides for disclosure request and retention processes. The policy itself says registrars may process additional information, including payment data, and must consider properly formulated disclosure requests.

Threat model #

Before buying any service, define who you're protecting yourself against. The EFF recommends starting with assets, adversaries, impact, likelihood, acceptable cost and allies. The question “I want nobody to know” has to become a list you can check.

Step 1 — Create a separate operational identity #

The biggest leak is rarely cryptographic. It's reuse: the same username, avatar, recovery email, SSH key, Git account, bio style or posting schedule you already use under your real name.

· Pick a pseudonym and usernames that have never appeared in your personal accounts.

· Create an initial email that doesn't depend on the domain; that way, recovery doesn't hinge on a domain that can expire or be suspended.

· Use a long, unique password, kept in a password manager, and turn on TOTP or a hardware key. Avoid SMS when there's an alternative.

· Keep a separate browser profile or system. For web dashboards, use Tor Browser when the service allows it; never log in to personal accounts in the same session.

· Don't make up data where the contract requires correct data. Prefer a legitimate privacy/proxy service or a trustee model that publishes its own data by contract.

· Document the separation: email, accounts, keys, recovery method, renewal date and which companies know each piece of data.

Tor Browser reduces IP exposure, but doesn't guarantee perfect anonymity. It only protects applications correctly configured to use Tor; filling in a form with your name, phone or personal email hands your identity to the service anyway.

Step 2 — Choose the domain strategy #

There are three common models. The deciding difference isn't aesthetic: it's who shows up as the holder and who keeps legal and operational power over the domain.

Checklist before registering #

· Does the chosen extension allow privacy? Policies vary by TLD and can change.

· Is privacy included or optional? Is the country/state still public?

· Is there a relayed email channel that doesn't reveal your real address?

· Who is the formal registrant? How do transfer, unlocking and the authorization code work?

· In which cases does the service ask for identification, suspend the domain or disclose data?

· How do you recover the account without a personal phone? Does the contract require correct information?

A critical reading of privacy services #

The examples below aren't endorsements. They show why the sales page should be read alongside the Terms and the Privacy Policy.

Step 3 — Treat payment as an identifier #

Cards, PayPal, bank transfers and app stores create records with the payment processor, even when the host doesn't keep the card number. Cryptocurrency isn't a synonym for anonymity either. Bitcoin.org itself points out that transactions are public, traceable and permanent, and that addresses can be tied to identities when used to buy services.

· Use only payment methods that are legal and compatible with the provider's terms.

· Decide whether your threat is public exposure or correlation by the provider. For the first, an ordinary payment may be acceptable; for the second, it's a strong link.

· Don't reuse receiving addresses published on the site to pay for infrastructure.

· Keep receipts and renewal dates encrypted: losing the domain for lack of payment is more likely than a cryptographic break.

Step 4 — Prefer a static site and a quiet origin #

The fewer public components, the smaller the attack surface and the less operational data there is. For a blog, a lean stack covers almost everything without a database, an open admin panel or third-party plugins.

For DNS records marked as “proxied”, Cloudflare answers with an anycast IP instead of the origin IP. With Tunnel, the agent on the server creates outbound-only connections; the origin can block incoming traffic. That hides the origin's address from the public, but Cloudflare still knows which account and which origin are connected.

Step 5 — Set up the server in a safe order #

Use Debian stable or another distribution with predictable updates. The order matters: first make sure you have recovery access through the provider's console; then create and test an account without permanent privileges; only then close ports.

1. Update and create an admin user #

sudo apt update sudo apt full-upgrade sudo apt install nginx unattended-upgrades ufw sudo adduser publisher sudo usermod -aG sudo publisher

Copy a new SSH key — not reused in personal projects — to the publisher user. Open a second session and confirm the key works before touching the SSH configuration.

2. Turn off direct root login and passwords #

Create /etc/ssh/sshd_config.d/99-site.conf with the content below. Replace publisher if you use another name.

PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no AllowUsers publisher

Validate the syntax before reloading:

sudo sshd -t && sudo systemctl reload ssh

3. Serve the site on localhost only #

Build the site locally and upload only the output folder. A minimal Nginx block can listen on 127.0.0.1:8080:

server { listen 127.0.0.1:8080; server_name _; root /srv/private-site/output; index index.html;

location / { try_files $uri $uri/ =404; } add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy no-referrer always; add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always; add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'" always; }

4. Connect the tunnel and close the door #

Install the tunnel agent from the provider's repository and current documentation; publish the hostname to http://127.0.0.1:8080. Test the domain from an outside network. Then, with the emergency console confirmed, apply a firewall policy that denies incoming and allows outgoing. If you also carry SSH through the tunnel, protect it with strong authentication and a separate policy.

Step 6 — Don't reveal the origin before the proxy #

· Set up the proxy/tunnel before creating any public A or AAAA record pointing to the VPS. Historical DNS databases can keep mistakes for years.

· Don't create obvious subdomains like origin., direct., cpanel. or server. pointing straight at the machine.

· Don't run email on the same IP. MX, SPF, DKIM and sent messages can create an independent trail to the infrastructure.

· Don't use the origin IP in monitors, status pages, repositories, screenshots or public reports.

· Keep the web service bound to localhost when using a tunnel. If you only use a reverse proxy, limit the origin to the proxy's addresses and authenticate the connection.

· Don't use the same VPS, cloud account, SSH key or snapshot as a project tied to your real name.

Step 7 — Clean up code, images and habits #

A photo with no name in the file can still contain GPS, camera model, software, time and thumbnails. A repository can publish your real email in every commit. A reused analytics ID can link two sites that never mention each other.

Git #

Turn on “Keep my email addresses private” on GitHub and copy the noreply address the platform gives you. Set it only in the pseudonymous repository and audit the whole history before the first public push:

git config user.name "Your pseudonym" git config user.email "NOREPLY_ADDRESS_PROVIDED_BY_GITHUB" git log --all --format='%an <%ae>' | sort -u

GitHub's documentation warns that changing the setting affects future commits; old commits keep the previous email. If the history is compromised, recreate the repository before publishing it instead of relying only on the new setting.

Images and documents #

Inspect first, remove metadata into a new copy and inspect again. ExifTool warns that removing “everything” isn't an absolute guarantee for every format; re-exporting or re-encoding may be necessary.

exiftool -a -G1 -s original-image.jpg exiftool -all= -o public-image.jpg original-image.jpg exiftool -a -G1 -s public-image.jpg

Content and front end #

· Host fonts, CSS, JavaScript and images on your own domain. External resources expose your readers and create dependencies.

· Avoid third-party comments, marketing pixels and analytics IDs you already use on personal sites.

· Remove source maps, .env files, backups, build directories, local usernames and absolute paths.

· Don't publish new photos of your surroundings, receipts, screens showing a time zone, notifications or details of your routine.

· Assume vocabulary, schedules and topics can allow stylometric analysis. There's no simple tool that makes an author unrecognizable.

Step 8 — Remember that HTTPS also leaves public records #

HTTPS is mandatory to protect readers, but public certificates go into Certificate Transparency logs that anyone can search. That can reveal the domains and subdomains in the certificate, even when the origin server stays hidden.

· Use neutral subdomain names; don't put personal names, internal environments or providers in the hostname.

· Consider a wildcard certificate obtained via DNS-01 when many internal subdomains shouldn't show up individually. The base domain will still be public.

· Turn on DNSSEC when the registrar and the authoritative DNS support it and you know how to recover from a botched key rollover.

· Review MX and TXT: verification records, SPF and SaaS tools can reveal related services and accounts.

Step 9 — Audit it like a stranger #

Local queries #

dig +short A example.net dig +short AAAA example.net dig +short MX example.net dig +short TXT example.net dig +short NS example.net curl -sSIk https://example.net

External checks #

· Open ICANN Lookup/RDAP and confirm exactly which fields are public.

· Search the domain and each subdomain in certificate logs and DNS history services.

· Search the pseudonym, email, exact phrases from the text, favicon and file names in search engines.

· Open the site in a clean browser and on another network; look at external requests in the Network panel of the developer tools.

· Download every image and document from the site and run a metadata inspection on the published copy, not just on the source file.

· Ask someone you trust to repeat the investigation without knowing your architecture. What you know about yourself distorts the audit.

Step 10 — Keep the separation after launch #

Pseudonymity is a routine, not a purchase. A single login to a personal account, an old commit, a renewal paid with an identifiable method or a support reply signed with your name can tie together years of work.

· Turn on security updates and check the system, Nginx, the static generator and the tunnel agent every month.

· Keep two encrypted backups in different places and test restoring at least every quarter.

· Note domain and VPS renewals well in advance; use reminders outside the domain's own email.

· Review active sessions, API tokens, SSH keys and recovery methods. Revoke what isn't used.

· Audit RDAP, DNS, Certificate Transparency and the Git history every time you change provider or architecture.

· Have an incident plan: take the site down, revoke tokens, rotate keys, preserve evidence and tell readers without improvising.

What not to do #

Launch checklist #

A surface web site can look, and be, completely pseudonymous to the public. The most solid design combines a separate operational identity, registration with legitimate redaction, an origin with no public port, static content and recurring audits. Even so, every middleman keeps a piece of the puzzle.

The measure of success isn't “nobody will ever know”. It's this: a visitor or researcher doesn't find your name, address, personal accounts or origin IP; a failure in one layer doesn't automatically reveal all the others; and you know exactly which companies are still able to correlate the operation.