Every other guide in this series opens with "point a subdomain at it", and none of them says where the domain comes from. It is the one part of a self-hosted stack that is published on purpose — a registry entry, a registrar account, a payment, and a public log listing every hostname you have ever requested a certificate for. Six steps to register and hold a name with none of that pointing back at you: the four records a registration really creates, the registries that will refuse you, paying in Monero, and the two leaks that undo the whole exercise weeks after you stopped looking.
Model
Four records, not one
Choose
The registry sets the floor
Register
Three ownership models
Pay
The exchange is the leak
Delegate
DNS, TLS, and the public log
Hold
Renewal, lock, rehearsed exit
The domain name system is a delegation system, and a delegation only works if somebody authoritative says who holds it. A registry keeps the list for its top-level domain; a registrar sells you an entry in that list and warrants that it knows who you are; the name then resolves because a chain of servers is willing to say, on the record, that this zone belongs to those nameservers. There is no version of this where nobody knows anything. What you can decide is how many parties know, what they know, and how easily a stranger gets it out of them.
That is a genuinely different problem from the one the rest of this series deals with. A server can be rented anonymously because a hosting relationship is bilateral: you and the host, and nobody else needs a copy. A domain is multilateral by construction — a registry, a registrar, often a reseller, a DNS operator, a certificate authority, and a set of public logs that exist precisely so that the issuance can be audited by people who are not you. Approaching it with the reflexes that work for a VPS produces a very confident mistake.
The good news is that the default has moved a long way in the reader's favour and most advice on this subject has not caught up. Since 2018 the public registration record for a generic top-level domain has been redacted: the contact fields that used to show a name, a street and a telephone number now show nothing, for everybody, without paying for anything. The policy that governs this — ICANN's Registration Data Policy, which replaced the emergency measure adopted when the GDPR took effect — also sets out the documented path by which someone with a legitimate interest can request the underlying data. The record is not gone. It is held rather than published, and knowing exactly who holds it is most of the work.
Three arrangements are compared below, and they differ in which party ends up holding what. The third is not a domain at all, which is the reason it appears here: for a meaningful set of projects it is the correct answer, and it is worth knowing that before spending forty-five minutes on the other two.
| Property | Your own name, redacted record | Proxy ownership | A version-3 onion address |
|---|---|---|---|
| Who is in the registry record | You — collected, held, not published | The provider, as the legal registrant | There is no registry |
| Who can be asked for your details | Registrar and registry, on a documented request | The provider alone, under its own policy | Nobody — there is no record to ask for |
| Who can take the name away | Registry, registrar, a dispute panel, a court | All of those, plus the provider itself | No one — the address is derived from your key |
| What it costs a year | Roughly $10 to $60, by extension | A multiple of that — the premium is the point | Nothing, ever, and it cannot expire |
| Reachable in a normal browser | Yes | Yes | Only through Tor |
One disclosure, since this is a page about who profits from a recommendation. NordBastion does not sell domain names. No registrar is linked from this guide, none is an affiliate, and there is no arrangement under which we are paid for anything you do after reading it. What is described below is what we would tell somebody who asked in the panel, which is also the standard the rest of the library is written to.
Registering a name does not create a record of you. It creates four, in four different places, held by four sets of people with four different reasons to keep them and four different thresholds for handing them over. Almost every failure in this area is somebody hardening one of the four and assuming the others followed.
The registration data. Name, postal address, email, telephone — collected by the registrar at purchase, escrowed with a third party as a condition of the registrar's accreditation, and passed to the registry in whole or in part depending on the extension. This is the one everybody thinks about and the one already redacted in public for generic domains. It is disclosed on request through a documented process, and inside the EU both registries and registration services are under a positive duty, from Article 28 of the NIS2 Directive, to hold it accurate and complete and to release it to legitimate requesters without undue delay.
The registrar account. Richer than the registration data and almost never discussed. It holds the login history with addresses and timestamps, the payment instrument, the support tickets you have opened, and — this is the part that matters — every other domain in the same account. One account holding a professional domain under your legal name and a project you would rather not be tied to has linked them permanently for anyone who can read that account, whatever the public record says about either.
The payment. A card is an identity document that settles money. A bank transfer is the same with a longer tail. A Bitcoin payment is a permanent public entry that becomes an identity document the moment any address in its history is attributed to you. Monero is the one rail on this list that does not leave a third-party-readable entry — but the account you acquired it from may hold a record of a withdrawal that matches the invoice in time and amount, and that correlation is the whole attack.
The exhaust. Everything the registration produces afterwards, which nobody budgets for because it accrues while you are not watching. Certificate transparency logs list every hostname you have ever requested a certificate for, permanently and searchably. Passive-DNS datasets record which names have resolved to which addresses, which is how two unrelated projects on one server become one project. Historical registration archives keep a snapshot of the record from before you turned privacy on, and they do not remove it afterwards. And the content itself leaks: a reused analytics identifier, a repeated favicon hash, a support address that appears on both sites.
Write down, in one sentence, who you are trying to be unreadable to. A competitor with a search box, a mass scraper building a marketing list, a litigant with a lawyer, or a state with legal process — those are four different problems and the first two are solved by defaults you already have. Most people asking this question need the second; almost nobody needs the fourth, and the measures that would address it start well before the domain.
Read the current public record for a name you already own before doing anything else. The registry-side interface that replaced the old text protocol returns structured data, and it will show you exactly which fields your extension publishes rather than what a blog post from 2017 says it publishes:
whois example.com | sed -n '1,40p' # the legacy view, still served by many registries
curl -s https://rdap.org/domain/example.com | jq '.entities[].roles, .status'
# the structured view — roles, status codes, redaction
Two things in that output decide more than the contact fields. The status array tells you whether the name is locked against transfer and whether any registry-level hold is in place. And the absence of a contact entity is the redaction working — if you see a full postal address for a generic domain in 2026, it is because the registrant published it deliberately, which a surprising number of organisations still do.
A registrar can only sell you what its registry permits. If the registry requires a local presence, no amount of privacy service makes that requirement go away; if the registry publishes the registrant name in full, no add-on suppresses it. This is the reverse of how the purchase is usually made — people pick a name, then a registrar, then discover the registry's rules at the point of failure. Pick the family of extension first.
Rather than a list of individual extensions, which would be stale within a year because registries change their own terms without announcing them to anyone outside the industry, the useful division is by what the registry demands. There are five families and one non-domain, and almost every extension you will consider falls cleanly into one of them.
| Family | What the registry demands | Verdict |
|---|---|---|
| Legacy generic — .com, .net, .org | Accurate data collected by the registrar, redacted in the public record, disclosed on a documented request. No eligibility test. | The default answer. Boring, portable, universally accepted. |
| Newer generic — .dev, .app, .xyz, .site | The same central policy, plus whatever the individual registry adds in its own terms. Some are permanently HTTPS-only by design. | Fine, once you have read that registry's own terms rather than assuming. |
| Eligibility country-code — .eu, .us, .ca, .fr | Residency, citizenship or a local establishment, declared at purchase and verifiable afterwards. A false declaration is a revocation ground, not a loophole. | Only if you genuinely satisfy the condition. |
| Verified country-code | An identity check, a national identifier or a local administrative contact, often with the registrant name published in full whatever the registrar sells you. | Avoid for this purpose. The registry, not the registrar, decides. |
| Open country-code sold as generic | No residency test, but the registry's own policy is the entire contract — and some publish everything, or suspend on an informal request from a national body. | Case by case. Read the registry policy page, not the reseller. |
| A version-3 onion address | Nothing. It is derived from a key pair you generate, so there is no registry, no registrar, no payment and no expiry date. | Unbeatable, if Tor-only reach is acceptable. |
Three questions settle the choice, and all three are answered on the registry's own policy page rather than at the shop. Is there an eligibility condition? If yes, either you satisfy it or you pick a different extension — asserting a residence you do not have converts a privacy measure into a cancellation clause that activates at the first complaint. What does the registry itself publish? Redaction for generic domains is centrally mandated; country-code registries write their own rules and several publish the registrant name regardless of what your registrar charges you for privacy. What is the record on suspension? A registry that operates a published dispute process is one you can argue with; a registry with a history of acting on an informal phone call is not.
There is a fourth question that almost nobody asks at purchase and everybody meets in month thirteen: what does renewal cost? A promotional first year on an unusual extension followed by a standard renewal several times larger is a decision you have to keep making every year, and a name you cannot comfortably afford to renew is a name that will eventually drop to somebody who has been watching for exactly that. Price the tenth year, not the first.
For nearly everybody reading this, a legacy generic extension registered through a registrar that takes crypto is the correct answer, and the exotic country-code with the clever pun is the one that generates the support ticket in three years. The privacy you get from a familiar extension is identical; what changes is how many parties can take it away from you, and how many of them you have ever heard of.
Model one — your own details, behind the default redaction. You are the registrant, the data is accurate, and the public record shows none of it. The name is legally yours, it transfers like any other asset, and nobody can decide on a Tuesday that they would rather you did not have it. What you are accepting is that the registrar holds a true record of you, and that a documented request can extract it. For the overwhelming majority of projects this is both sufficient and correct, and the people who dismiss it are usually comparing it against an imagined alternative rather than a real one.
Model two — a pseudonymous registrant who is genuinely reachable. A working name and a working address that route to you, without your legal identity written on them. This is lawful in itself and it is what a great many people mean by "anonymous registration"; the thing that makes it durable rather than fragile is that it must be reachable. A registrar is required to act on a report that registration data is inaccurate, and the first step of acting is sending a message to the address on file. If that message lands, the process usually ends there. If it does not, the name is suspended while you are asleep, and it is suspended for exactly the reason you cannot easily fix — you are not the person on the record.
Model three — proxy ownership. A provider registers the name in its own legal name and grants you the use of it. You are nowhere in the registry, because you are not the registrant; what you hold is a contract. It is the strongest available protection against the registration data being about you at all, and it is a single point of failure with a company attached. Everything now depends on that provider staying solvent, keeping its policies, and agreeing to act on your instructions — including the instruction to hand the registration over if you later want to leave. We compare one long-standing operator of this model on our Njalla comparison page; the assessment there is the same as here, which is that it is a real product with a real trade-off rather than a free upgrade.
| Model | Fails when | Pick it when |
|---|---|---|
| Own details, redacted | Somebody with standing makes a documented disclosure request. | You want the name to be unambiguously yours and unreadable to the public. |
| Pseudonymous, reachable | The address on file stops working and an accuracy complaint arrives. | The project is not your legal person and you will actually read that mailbox. |
| Proxy ownership | The provider is acquired, changes policy, or simply stops replying. | The name can be changed if it must be, and the registry record matters more than portability. |
Whichever model you choose, the account around it is the part that decides how the story ends, and it is built in five minutes before you register anything. A dedicated email address that exists for this account and nothing else — not the one in your commit history, not the one in a breach corpus from 2019, and not one hosted on the domain you are about to register, because a name whose recovery address lives on the name itself cannot be recovered once it lapses. A password that exists nowhere else. A time-based one-time-password second factor, with the recovery codes stored somewhere other than the mailbox they protect. And no telephone number if the registrar will let you omit it, because a number is a stronger identifier than anything else on the form.
For generic domains the registrar must verify the registrant email address, and it does this by sending exactly one message with a link in it. If that link is not followed inside fifteen days, the registrar is required to suspend the name — the site goes dark, the mail stops, and the certificates fail to renew. It arrives within minutes of the purchase, it looks like every other transactional message from a registrar, and it is the single most common way a carefully planned anonymous registration is dead within a fortnight. Follow the link before you close the tab, then confirm in the account that the address shows as verified.
One more habit that costs nothing and prevents the most irreversible mistake in this area: one compartment, one account. If a project needs to be unlinkable from another project, the two names do not share a registrar account, a payment source, a nameserver set or a server address. Splitting them later is impossible, because the link was recorded on the day they were created and the datasets that recorded it do not forget.
A registrar that takes cryptocurrency solves the obvious problem: no card number, no billing address, no bank that files a report about a small foreign payment. It does not solve the problem that actually breaks anonymity, which sits one step upstream at the place the coin came from. Almost every chain of reasoning that ends at somebody's identity started at a verified exchange account and walked forwards, not at a registrar and walked back.
Monero is the rail with the fewest moving parts here, because amounts, senders and recipients are not published. There is no ledger entry for a third party to correlate against later, which removes the entire class of problems that Bitcoin creates over a ten-year horizon. Our step-by-step Monero guide covers wallets and confirmations, and the mechanics are identical whether the invoice is for a server or a domain.
Bitcoin, on-chain or over Lightning, is far more widely accepted and leaves a permanent, public, searchable entry. That is not automatically a problem — it is a problem if any address in the history of those coins is ever attributed to you, and attribution is a service that several firms sell. Lightning is better than on-chain for this because the payment itself is not a ledger entry, but the channel funding was, and the coins arrived from somewhere. The Lightning guide covers both rails.
Three habits do more than the choice of coin. Put distance between acquisition and spending — time, and at least one hop that is not a direct withdrawal from a verified account straight to the merchant. Break the amount correlation by funding a prepaid balance in a round figure rather than paying each invoice for its exact and unusual price, since "a withdrawal of 0.0413 XMR at 14:07" and "an invoice for 0.0413 XMR at 14:09" is a match anybody can make. And do not let the registrar keep a payment method on file for automatic renewal: a stored card is the identity document you removed from the purchase reappearing in year two, and a stored crypto balance is the better answer to the same need.
Budget the renewal at the same time you pay for the registration, because this is where the largest number of anonymous names quietly die. Register for as many years as the registry permits in a single transaction — most generic extensions allow up to ten — and you have converted a recurring exposure into one payment and removed nine opportunities for a failed renewal to take the name from you. It is the cheapest risk reduction on this page and it is usually declined because the first year looks like enough.
The machine the name points at is the easier half of this problem, because a hosting relationship is bilateral and nothing has to be published. On NordBastion there is no email verification at signup, no identity document, no card and no legal name on the account; the balance is funded in Monero, Bitcoin or several other assets, and the server is ordered from that balance. The domain remains the exposed surface. The host does not have to be a second one.
Delegation itself is two records and five minutes. Set the nameservers at the registrar, create an address record for the host, wait for the change to propagate to the registry, and confirm it from outside your own network rather than from the machine that already knows the answer. What deserves the remaining forty minutes is everything the delegation makes visible afterwards.
dig +short NS example.com @1.1.1.1 # the delegation as the world sees it, not your cache
dig +short A app.example.com # must return the VPS address before you deploy anything
dig +short CAA example.com # empty today; step 05 fills it in
dig +short DS example.com # non-empty only if DNSSEC is actually signed
On who runs the authoritative servers, the honest answer is not the one the rest of this series usually gives. Self-hosting authoritative DNS is the one component where doing it yourself is generally worse: it wants two or more servers on separate networks, it has to keep working during exactly the outage that has taken your main box down, it needs ongoing care to avoid being abused for amplification, and when it fails everything fails with it — including the certificate renewal that would have let you repair the situation. It also creates a correlation you were trying to avoid, because a self-run nameserver shared between two projects publicly ties them together in datasets anybody can query. Use a DNS operator with an anycast network, choose it on whether it demands an identity document rather than on its feature list, and keep an exported zone file so moving is a paste rather than an excavation. This is a different job from the private recursive resolver in the series, which moves the log of what you look up onto your own machine and is worth doing.
Now the leak that undoes more careful setups than anything else on this page, because it operates silently and after you have stopped paying attention. Every certificate issued by a publicly trusted authority is submitted to append-only public logs, and browsers reject certificates that are not. The logs exist so that mis-issuance is detectable, which is a genuinely good thing, and they are indexed by free search interfaces. The consequence is that every hostname you have ever requested a certificate for is a keyword search away, for anybody, permanently — including staging., vpn., backup. and the administrative name you assumed nobody would guess.
# every certificate ever issued under the zone, and every hostname inside each one
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -u
The mitigation is a single wildcard certificate for the zone, served for every internal hostname underneath it. The log entry then records that a certificate exists for the zone and nothing about what lives inside it. The cost is that a wildcard requires the DNS-based challenge rather than the simpler file-based one, which means an API token for your DNS operator on the box — ten minutes of setup, weighed against a permanent public list of your internal naming scheme. Issue one wildcard, keep it on the reverse proxy, and stop requesting per-hostname certificates.
Two records finish the job. A CAA record states which certificate authorities are permitted to issue for the name, so a mis-issuance by any other authority is refused at source rather than detected afterwards. And DNSSEC, if both your registry and your DNS operator support it, signs the delegation so a resolver can tell a forged answer from a real one — it is one switch at most operators and one record at the registrar, and the only thing to be careful about is that a signed zone whose keys are mishandled fails closed, which is to say completely.
; in the zone — only this authority may issue, and tell us if anyone tries
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:abuse@example.com"
Finally, the correlation layer, which is where two compartments become one without anybody making a mistake. Passive-DNS datasets record which names resolved to which addresses and when; a shared address, a shared nameserver set or a shared mail exchanger is enough to join two projects that have nothing else in common. If two names must stay unlinked, they need separate servers, separate nameserver sets and separate mail routing — and the same goes for the small things nobody counts, like an analytics identifier reused across both sites or an identical favicon, both of which are searchable at internet scale by anybody who cares to.
A domain is the only component in this series with an expiry date, and losing it is the only failure here that is genuinely irreversible. When a name lapses the site goes down, the mail stops, the certificates fail to renew, every account anchored to an address at that domain becomes unrecoverable, and after a fixed window anybody at all may register it — including somebody who watched it drop precisely because it had traffic. There is no backup that restores this.
The timeline is worth knowing exactly, because each stage has a different price and the last one has no price at all. At expiry the name usually stops resolving immediately while a grace period runs, during which renewing costs the ordinary fee. Then it enters a redemption period of about thirty days, during which it can still be recovered but at a punitive fee set by the registry rather than the registrar. Then a short pending-delete phase in which nothing can be done by anyone. Then it drops, and the first party to reach it owns it. The intervals vary by registry; the shape does not.
| Stage | The name is | Recovery |
|---|---|---|
| Grace, after expiry | Usually already not resolving | Renew at the normal price |
| Redemption, about 30 days | Held by the registry, dark | Possible, at a punitive registry fee |
| Pending delete, about 5 days | Queued for release | None, for anybody |
| Dropped | Available to the world | Buy it back from whoever was faster |
Four things hold a name against all of that. Register long — ten years where the registry allows it, which removes nine chances for a renewal to fail. Keep the transfer lock on, the status code that stops a transfer being initiated without you unlocking it first, and add the registry-level lock if your extension offers one and the name matters. Store the authorisation code offline, in the same place as the second-factor recovery codes and the exported zone file, because the day you need it is the day the account is not answering. And keep the expiry in a calendar you actually read, not only in the registrar's notification system — a registrar that has closed your account has also stopped emailing you about it.
Rehearse the exit once, while nothing is wrong. Unlock, request the authorisation code, confirm you can receive the transfer message at the address on file, then lock it again — twenty minutes that turn an emergency into a procedure. Be aware that a transfer is not available in the first sixty days after a registration or a previous transfer, which is exactly the window in which a new registrar most often turns out to be the wrong one.
Last, the thing that is genuinely resilient in a way no registered name can be. A version-3 onion address has no registry, no registrar, no renewal, no payment and nothing anybody can revoke, because the address is derived from a key pair you hold. Running one alongside the clearnet site costs two lines of configuration and gives you an address that keeps working on the day the registrar closes the account — publish it on the site, add the Onion-Location header so a Tor user is offered it automatically, and it becomes the fallback that survives the failure this whole step is about. The hidden service guide is twenty minutes end to end.
One message, sent minutes after purchase, indistinguishable from the receipt beside it. Fifteen days later the registrar is required to suspend the name: the site goes dark, the mail stops, the certificates fail to renew. Follow it before closing the tab, then confirm the address shows as verified in the account.
An exhausted crypto balance, a notification to a mailbox on the domain itself, a registrar whose reminders were filed as marketing. After redemption anyone may register it, and someone watches for exactly this. Register for ten years, keep the date in your own calendar, and never anchor recovery to the name it protects.
An extension that requires residence, citizenship or a local establishment does not stop asking after checkout. Declaring one you do not have turns the registration into a cancellation clause that activates at the first complaint — and the name is gone with no process worth joining.
Every publicly trusted certificate is entered into an append-only log that anyone can search by domain. There is no opt-out, and there should not be. One wildcard certificate for the zone publishes the zone and nothing beneath it; per-hostname certificates publish your entire internal naming scheme, permanently.
Commercial archives snapshot registration records continuously and keep them. A name once registered with your details in the open stays that way in their history no matter what today's record says. Check what is already stored before assuming a name is clean — and prefer a fresh registration to a transfer for anything that matters.
A professional domain and a project you would rather not be tied to, in the same registrar account, on the same payment source, behind the same nameservers. The public record can say nothing at all and they are still joined — for anyone who can read that account, and in passive-DNS datasets for everybody else.
Eleven questions that come up while doing this — beginning with the one that decides whether any of it holds up.
Registering a domain without publishing your identity is legal and ordinary; registering one with details that are false is a different thing, and it is the distinction the whole subject turns on. Since the 2018 change in how registration data is handled, the public record for a generic top-level domain is redacted by default — your details are collected and held, they are simply not published to anyone who asks. That is the normal state of a domain in 2026, not a privacy trick, and it is why the market for "WHOIS privacy" as an add-on has largely become a market for something you already have. What remains genuinely optional is whether the accurate details sit with a registrar under your legal name, or whether a third party holds the registration and you hold a contract with them. Both are lawful. What is not lawful, or at least not durable, is supplying details that are knowingly false: under ICANN's accreditation agreement a registrar must act on a report of inaccurate data, and inside the EU, Article 28 of the NIS2 Directive puts registries and registration services under a positive duty to hold accurate and complete data and to verify it. A registration built on a fabricated identity is a registration that can be cancelled at the moment somebody complains, which is the moment you would least like to lose it. The workable position is accurate data, held by as few parties as possible, published to none. Nothing here is legal advice.
Less than it used to, and the difference is worth understanding before paying for it. For a generic top-level domain the public record already shows redacted contact fields, so a paid privacy service adds nothing to what a stranger can read. It still does two useful things. It substitutes a forwarding address for yours in the places redaction does not reach — the registrar's own directory pages, the data some registries still publish in full, the bulk feeds, and the transfer confirmation emails. And it puts a party between you and the volume of automated abuse aimed at whatever address is on the record. The three things it does not do are more important. It does not affect the details your registrar holds, which are the ones that get disclosed on a documented request. It does not apply retroactively: if the name was ever registered with your details in the open, that snapshot is in half a dozen commercial historical archives permanently, and switching privacy on today does not remove it. And on many country-code domains it is simply unavailable, because the registry, not the registrar, decides what is published. Judge it as spam control plus a thin layer, not as anonymity.
It matters less than where the coin came from, and that is the part people get backwards. A Bitcoin payment is a permanent public entry linking an amount and a time to an address, and if that address can ever be tied to you — because you withdrew it from an account opened with an identity document, because you reused it, because a chain-analysis firm clustered it with one that was — then the payment is a durable link between your name and that registrar on that day. Monero does not publish amounts, senders or recipients, so the same payment leaves no equivalent entry. But if the Monero was bought minutes earlier on an exchange that verified your identity and withdrawn straight to the registrar, the exchange holds a record of a withdrawal of very nearly the invoice amount at very nearly the invoice time, and that correlation is not hard to make. The rule that actually helps is about distance rather than coin: put time, amount-shape and at least one non-attributed hop between where you acquired the value and where you spent it, and prefer funding a prepaid balance in a round amount to paying each invoice for its exact price. Our Monero guide and Lightning guide cover the mechanics on both rails.
No, and a good provider of this model says so plainly. In proxy ownership the provider registers the name in its own legal name and grants you the right to use and direct it; you hold a contract, not a registration. That is exactly what makes it effective — there is no record of you anywhere in the registry, because you are not the registrant — and it is exactly what makes it a concentration of risk. Everything now depends on one company's solvency, its policies and its willingness to act on your instructions, including its willingness to transfer the registration to you if you later want to leave. Providers who do this well publish a stated commitment to transfer on request and have a visible record of honouring it, and that record is the only real diligence available to you. Weigh it against the failure mode: the day the provider is acquired, changes its terms, decides your content is outside its policy, or simply stops answering, you have a name you cannot move. For a project that can be renamed, the trade is often worth it. For anything whose address is its identity — a published software repository, a mail domain, a shop with customers — it is a bet on a third party that a plain registration behind a privacy service does not require you to make. We compare one provider of this model on our Njalla comparison page.
Rather than a list that will be stale within a year, use three questions against the registry's own policy page. First: does it impose an eligibility condition — residency, citizenship, a local company, a local administrative contact? If it does, satisfying that condition means either being that thing or asserting that you are, and the second option is a revocation ground rather than a workaround. Second: what does the registry itself publish? Registration data policy for generic domains is set centrally and redacts contact fields, but country-code registries set their own rules and several publish the registrant name in full regardless of what your registrar sells you. Third: who is behind the registry and what is its record of suspending names? Some registries operate on a documented dispute process; others have taken names down on an informal request from a national body, and a domain seized without a process you can join is a domain you cannot defend. There is a fourth question nobody asks and everybody should: what does renewal cost in year two? A promotional first year on an unusual extension followed by a large standard renewal is a recurring decision you have to keep making, and a name you cannot afford to renew is a name you will eventually lose to somebody watching for it to drop.
For a real class of projects, yes, and it is the only arrangement on this page with no registrar, no registry, no renewal date and no payment. A version-3 onion address is not allocated by anybody: it is a 56-character encoding derived from a key pair you generate, which makes the address self-authenticating and unrevokable — nobody can transfer it, suspend it or let it expire, because there is no record of it anywhere to act on. What you give up is everybody who will not install Tor Browser, which for most public-facing projects is nearly everybody, plus search visibility, plus mail, plus every integration that assumes a normal hostname. The arrangement that works in practice is both: a clearnet domain registered as this guide describes for reach, an onion service for the people who want it, and the Onion-Location header on the clearnet site so a Tor user is offered the onion automatically. That also gives you a fallback that survives losing the domain — the onion address keeps working on the day the registrar closes your account, which is the day you will wish you had one. Our Tor hidden service guide is the walk-through.
Yes, and this is the leak that most often undoes an otherwise careful setup, because it operates after you have finished and stopped paying attention. Every certificate a publicly trusted authority issues is submitted to append-only public logs, and browsers refuse certificates that are not. The logs are mirrored and indexed by free search interfaces, so the full hostname of anything you requested a certificate for is a keyword search away — for anyone, forever, including the staging., backup., vpn. and admin- names you assumed nobody would guess. There is no opt-out and there should not be one; the logs are what makes mis-issuance detectable. There is a clean mitigation: request a single wildcard certificate for the whole zone and serve every internal hostname from it, and the log entry says only that a certificate exists for the zone. It costs you the DNS-01 challenge instead of the simpler HTTP one, which is ten minutes of setup against a permanent disclosure. Do the search on your own domain before you go further — it takes one command, and people are routinely surprised by what is already in there from a certificate they issued once and forgot.
Plan for it as a certainty at some point over a decade rather than as an accident, because the trigger is usually mundane: an automated fraud rule on a crypto payment, a complaint about something on the domain, a change of ownership at the registrar, or a jurisdiction the company decides it no longer wants exposure to. Four preparations make it survivable and all four are free. Keep the transfer lock on but keep a current authorisation code stored offline, because a registrar that has closed your account is not going to generate one for you. Know your own registration data by heart — the creation date, the registrant email on file, the last transfer date — since that is what any recovery process will ask for. Keep the zone file exported somewhere outside the registrar, so rebuilding at a new one is a fifteen-minute paste instead of an archaeology project. And do not let the registrar be the same company as your DNS operator, your host and your mail provider, because one closed account then takes all four at once. If it happens anyway, the registrar is required under the transfer policy to have a documented process and a point of escalation, and the registry above it is a separate party with its own complaints path. The answer is slow, procedural and usually successful — provided you did not also lose the mailbox the whole account is anchored to.
Usually not, and this is one of the few places in the series where self-hosting is the weaker answer. Authoritative DNS wants two or more servers on separate networks, correct operation during exactly the incident that has taken your main server down, and a resistance to amplification abuse that is an ongoing job rather than a configuration step — and if it fails, everything that resolves through that name fails with it, including the certificate renewal that would have let you fix it. There is also a privacy argument against it that runs opposite to the usual one: a self-run authoritative server on the same address block as everything else you operate is a direct link between all of them, visible in passive-DNS datasets that anybody can query. The pragmatic arrangement is a DNS operator with an anycast network, chosen for whether it requires an identity document rather than for its feature list, and a zone you can export in one command. Note that this is a different job from the private resolver covered elsewhere in the series: that one moves the log of what you look up onto your own machine, which is a clear win. This one would publish what everyone else looks up about you, which is a different risk profile entirely.
Yes, and it is the single highest-value five minutes on this page. The address on a registrar account is not a contact detail, it is the master key: it receives the verification message whose expiry can suspend the name, it approves transfers, it resets the password, and it is the anchor of every recovery process. Three properties matter. It must be dedicated, so it is not the address in your commit history, your forum profile and a 2019 breach corpus — reuse is the most common way a carefully anonymous registration gets tied to a person, and it costs nothing to avoid. It must be durable: a disposable inbox that stops existing is how people discover their verification email nine months late, and free providers close inactive accounts. And it must be one you genuinely read, because the messages that matter arrive rarely and look exactly like the ones that do not. Either your own domain at a mail provider, or a paid mailbox at a provider outside the chain, but not the same domain you are registering — a name whose recovery email lives on the name itself cannot be recovered once it lapses. Add a time-based one-time-password second factor on the account in the same sitting, and store the recovery codes with the authorisation code rather than in the mailbox they protect.
Because they expose different things and an adversary with one will go looking for the other. The domain record answers "who registered this name"; the hosting account answers "who pays for the machine, from which address, with which card, and what else do they run" — and that second file is usually far richer. It is also the one that is asked for by legal process rather than read from a public interface, which means the jurisdiction it sits in is part of your actual exposure. Two properties follow. Where the machine sits decides what process reaches it: Stockholm, Helsinki, Oslo and Reykjavík are four constitutional regimes with strong press-freedom traditions, all inside the EEA, which also removes the international-transfer question from anything you have to write down. And whose name is on the account decides what the account itself reveals — on NordBastion there is no identity document, no legal name and no card, the invoice settles in Monero or Bitcoin, and the customer record simply does not contain the thing somebody would be asking for. It does not make the domain private; nothing makes a domain private. It stops the domain from being the first link in a chain that ends at a hosting file with your passport in it. The jurisdiction guide covers the legal floor of each of the four.
Sentinel — 2 vCPU, 4 GB and 120 GB of NVMe for $3.90 a month, in Helsinki, Stockholm, Oslo or Reykjavík — is enough for the site the name points at, and it is ordered with no email verification, no identity document and no card. The balance is funded in Monero or Bitcoin. Whatever the registry publishes about the domain, the hosting file behind it holds nothing worth asking for.
Last reviewed · 2026-10-12 · Sources · ICANN Registration Data Policy; ICANN Transfer Policy; ICANN Expired Registration Recovery Policy; the 2013 Registrar Accreditation Agreement and its Whois Accuracy Program Specification; Directive (EU) 2022/2555 (NIS2) Article 28; Regulation (EU) 2019/517 on the .eu top-level domain; RFC 9082 and RFC 9083 (RDAP); RFC 9162 (Certificate Transparency); RFC 8659 (CAA); RFC 3915 (Redemption Grace Period) · Cadence · yearly
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
What “no KYC” actually means — and what it does not.
Why Sweden, Finland, Norway and Iceland — the legal floor of each.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Private hosting, built in the North.