Glossary

Long form

ACME is the protocol that automates TLS certificate issuance. The flow:

1. Client requests a certificate for a domain.
2. CA issues a challenge (e.g. “put this token at /.well-known/acme-challenge/xyz” — HTTP-01 — or “publish this TXT record” — DNS-01).
3. Client completes the challenge.
4. CA verifies, issues the certificate.
5. Client installs the certificate.

For privacy-focused hosting:

• All major free CAs (Let’s Encrypt, ZeroSSL, Buypass) use ACME.
• All major web servers (Caddy, nginx with certbot, Traefik) implement ACME clients.
• DNS-01 challenge enables wildcard certificates and works without exposing port 80/443 publicly — useful for Tor onion services that also need clearnet certs.

Recommended 2026 ACME clients:

• Caddy — automatic, no configuration needed for most cases.
• acme.sh — shell-script client with broad DNS provider plugin support.
• certbot — Let’s Encrypt’s official client.
• lego — Go-based, popular for embedded use.

ACME makes “free, automated, anonymous TLS” the default. There is no remaining business reason to pay a commercial CA for standard TLS certificates as of 2026.

Long form

ActivityPub is the W3C standard for decentralized social networking. It defines two protocols:

• Server-to-server federation: how Mastodon talks to Pleroma talks to Misskey, etc.
• Client-to-server: how a client app talks to a single server.

The combined system is the Fediverse — a network of independently-operated servers that interoperate. A user on mastodon.social can follow accounts on pixelfed.social (photos), peertube.example (video), or any other ActivityPub-speaking server.

For DMCA-ignored hosting purposes, ActivityPub is relevant because:

• Self-hosting a Mastodon / Pleroma / Pixelfed / PeerTube instance is the canonical alternative to centralized social platforms.
• The federation model means you keep your audience even if any one server goes down.
• Privacy-positioned offshore hosts (FlokiNET, 1984 Hosting, HostHatch) are increasingly common homes for Fediverse instances.

See /guides/anonymous-mastodon-fediverse for the operational guide.

Long form

The term originated to describe hosts used by spam, phishing and malware operators in the 2000s. It refers specifically to providers that accept content that is illegal where they operate and that take active measures to evade law enforcement (registering shell companies, using fraudulent infrastructure, jumping jurisdictions when raided, etc.).

Bulletproof hosting is not the same as DMCA-ignored hosting. A host that operates legally in Iceland, declines to act on US DMCA notices because the DMCA does not apply to it, and pulls anything illegal under Icelandic law is not bulletproof — it is a normal host operating under a different legal regime. This directory covers only the latter category.

Operators of true bulletproof hosting services have been prosecuted in multiple jurisdictions including Russia, Estonia, Ukraine, the Netherlands and the United States.

Long form

Colocation is the deepest level of “self-hosting in someone else’s facility”. You buy or build your own server, ship it to a colo provider, and rent the rack space + power + cooling + network connectivity. The colo provider doesn’t touch your hardware operationally.

For DMCA-ignored hosting purposes, colocation is relevant when:

• You want hardware-level control beyond what dedicated servers provide (custom firmware, weird hardware, HSM-backed key storage).
• You want to physically own the device that holds your encryption keys.
• You operate at a scale where buying hardware + colo costs less than renting.

In this directory:

• Bahnhof — Pionen datacenter in Stockholm; offers colo.
• 1984 Hosting — colo in Iceland.
• FlokiNET — colo in some locations.
• TerraHost — colo in Norway.

Trade-offs vs dedicated servers:

• Higher upfront cost: hardware + shipping + setup vs zero-deposit dedicated rental.
• Hardware failure is your problem: a dedicated server provider replaces failed disks; with colo, you ship replacements.
• Physical access is harder: shipping hardware to Iceland for replacement is slower than tickets-to-the-DC.

For most personal / small-business privacy use cases, dedicated servers or VPS suffice and are operationally simpler. Colo is for operators with specific hardware-control or cost-at-scale needs.

Long form

DDoS (distributed denial-of-service) attacks attempt to overwhelm a server with traffic from many sources, making it unavailable to legitimate users. Defenses operate at the network edge — the provider absorbs or filters attack traffic before it reaches your VPS.

For privacy-focused hosting in 2026:

• Most providers in this directory include some level of DDoS protection. The depth varies — entry tiers may handle 1-10 Gbps attacks; premium tiers go to 100+ Gbps.
• Anti-DDoS is particularly important for high-controversy workloads (free-speech sites, controversial-political content, popular Mastodon instances) which attract attacks more often.
• Cloudflare is widely used as a DDoS-mitigation edge layer, but for the reasons in our Cloudflare FAQ, it is a content-policy actor and should not be the only line of defense.

For high-DDoS-risk workloads, look for providers with explicit per-server DDoS quotas in their plan tiers (FlokiNET, AbeloHost, BuyVM, OrangeWebsite all have this) rather than relying on generic upstream protection.

For the providers in this directory, DDoS-protection status is in each provider’s frontmatter.

Long form

The Digital Services Act is the EU’s modernized framework for regulating online intermediaries. Compared to the older E-Commerce Directive it replaces, the DSA imposes more concrete obligations: a structured notice-and-action procedure, transparency reporting, internal complaint handling, and special rules for “very large online platforms.”

For DMCA-ignored hosting purposes, the DSA matters in two ways:

1. EU hosts are now subject to a notice-and-action regime that is structurally similar to DMCA safe harbor (notify → host evaluates → host can take action while preserving liability shield). It is not the same as DMCA — the procedural requirements are different, and Member State implementation varies — but EU hosts can no longer treat takedown notices as advisory.
2. Non-EU hosts serving EU users can fall within scope above certain size thresholds, blunting the “operate from Iceland, ignore EU notices” strategy for very large operations.

For typical small / medium operations using providers like FlokiNET, OrangeWebsite or Njalla, DSA exposure is limited but not zero. For larger operations the analysis is more nuanced; consult counsel familiar with EU intermediary liability.

Long form

The DMCA is the principal US copyright statute governing online intermediaries. Section 512 (“safe harbor”) protects service providers from liability for user-uploaded content if they act on validly-formatted infringement notices. The system is widely abused — automated takedown bots issue tens of millions of notices per year, many invalid — which is why providers in jurisdictions not bound by the DMCA often choose to evaluate complaints under their own local law instead of acting on every notice.

Important: the DMCA does not bind providers outside the US. A US rightsholder can send a DMCA notice to an Icelandic host, but the host has no statutory obligation to act on it. They may choose to comply, ignore, forward, or evaluate under Icelandic law.

Long form

DNSSEC adds cryptographic signatures to DNS responses. Without DNSSEC, an attacker on the network path can forge DNS responses pointing your domain at their server; with DNSSEC, the resolver can verify that the response actually came from the legitimate authoritative DNS server.

For privacy-focused hosting:

• Recommended for any production use. Catches DNS-level interference.
• Requires support at both layers: the registrar must publish DS (Delegation Signer) records, and your DNS host must sign your zone with DNSSEC keys.
• Can break things if misconfigured: DNSSEC failures cause your domain to become unresolvable for resolvers that validate. Test thoroughly.

In this directory:

• Njalla — supports DNSSEC at both registrar and DNS-host layers.
• 1984 Hosting — supports DNSSEC.
• deSEC (third-party DNS host) — DNSSEC-by-default; recommended pairing with any registrar.

Pair DNSSEC with DANE / TLSA records for cryptographically-verified TLS certificate pinning at the DNS layer. Niche but powerful for high-stakes operations.

Long form

Full-disk encryption (FDE) is the encryption of a storage device at the block level, typically using a symmetric cipher (AES-XTS) with a key derived from a passphrase or key file. On Linux, the standard tooling is LUKS (Linux Unified Key Setup) on top of dm-crypt.

For privacy-focused VPS use, FDE matters because:

• A hosting provider can be compelled (or choose) to image your disk. If the disk is unencrypted, they (or whoever they hand the image to) can read every file.
• If the disk is encrypted with a passphrase only you know, the imaged disk is opaque ciphertext.
• The catch: the passphrase has to live in RAM while the system is running. A live host with hypervisor access can read RAM and recover the key. So FDE protects against disk-imaging-from-power-off, not live-snapshot.

Practical FDE on a remote VPS requires a way to enter the passphrase at boot. Common options:

• Dropbear-initramfs: SSH into a minimal pre-boot environment, type the passphrase, system continues booting.
• Mandos: passphrase stored on a network server you control.
• Tang/Clevis: network-bound disk encryption — the key is recovered from a network service that must be reachable.

For maximum privacy: combine FDE with no-KYC signup, Monero payment and Tor-only management — see the anonymous VPS guide.

Long form

IPv6 is the modern Internet Protocol replacing IPv4’s exhausted 32-bit address space. For hosting purposes in 2026:

• Most providers in this directory offer dual-stack (IPv4 + IPv6) on every VPS.
• Some workloads — particularly those serving IPv6-preferred mobile networks, certain CDN integrations, or Tor relay operation — benefit from IPv6.
• Pure-IPv6 hosting is cheaper at some providers (a /64 IPv6 block costs nothing; a single IPv4 address is ~$1-2/mo extra).

When evaluating a hosting provider:

• Check whether IPv6 is included by default or extra.
• Check whether reverse DNS can be set on IPv6 (important for self-hosted mail).
• Check whether firewall and DDoS protection apply to IPv6 traffic — some providers’ DDoS protection is IPv4-only.

For the providers in this directory, IPv6 status is in each provider’s frontmatter and shown in the Quick Facts panel.

Long form

KVM is a Linux kernel module that turns a Linux host into a hypervisor capable of running fully-virtualized guest VMs. Each KVM guest has its own kernel, can run any OS (not just Linux), and is isolated from other guests at the hardware-virtualization level.

For VPS hosting, KVM is the default in 2026 because:

• Full kernel access: you can install custom kernels, run nested virtualization, use any sysctl. Required for many self-hosted workloads (Tor relays, VPN servers, container hosts).
• Better isolation than container-style virtualization (OpenVZ, etc.). Side-channel attacks from co-tenant guests are much harder.
• Custom OS / image upload: most KVM providers let you upload your own ISO and install from scratch. This is essential for full-disk encryption and minimal hardened OSes.

When evaluating a VPS provider, “KVM” is the right answer. “OpenVZ” or “LXC” providers are cheaper but offer less privacy and less flexibility, and are increasingly rare.

All providers in this directory that offer VPS use KVM (or another full-hardware-virtualization hypervisor like Xen).

Long form

KYC originated in banking anti-money-laundering law and has spread to crypto exchanges, payment processors, and some VPS / hosting providers (especially those in heavily-regulated jurisdictions or those that accept fiat-rail payments). A provider that requires KYC will typically ask for: government-issued photo ID, proof of address (utility bill), and sometimes a live selfie or video.

No-KYC providers accept signup with only an email address and payment. They may still collect IP, payment metadata and other technical signals — “no KYC” is not the same as “no logs.” For full anonymity, combine no-KYC signup with a no-logs payment method (Monero, cash) and an opsec-clean signup environment (Tor or trusted VPN, throw-away email).

Long form

Let’s Encrypt is a non-profit certificate authority operated by the Internet Security Research Group (ISRG). It launched in 2015 and is now the largest CA on the internet by certificates issued.

For self-hosted infrastructure:

• Free: no cost ever; no credit-card-required signup.
• Automated: certificates issued and renewed via the ACME protocol. No manual CSR process.
• 90-day validity: short by design to encourage automation.
• Wildcard support: *.yourdomain.com requires DNS-01 challenge; HTTP-01 works for individual subdomains.

For DMCA-ignored hosting: Let’s Encrypt eliminates one of the few remaining “you must give us your real identity” requirements in the hosting stack. Free certs, no KYC, no commercial CA relationship.

Common 2026 ACME clients:

• Caddy — built-in; zero config.
• certbot — official Let’s Encrypt client.
• acme.sh — pure-shell client; broad DNS provider support for wildcards.

Note: Let’s Encrypt logs all issuance to public Certificate Transparency logs. Anyone can search and discover that certificates were issued for a given domain (this includes subdomains). Doesn’t reveal traffic content but does reveal that subdomains exist.

Long form

Monero is the most widely accepted privacy-by-default cryptocurrency. Unlike Bitcoin (where every transaction is permanently traceable through the public ledger), Monero hides:

• Sender: ring signatures sign the transaction with a group of decoy keys, so the actual signer cannot be identified.
• Receiver: stealth addresses generate a one-time public key for each transaction; nobody (including the recipient) can correlate transactions to a single address.
• Amount: Ring Confidential Transactions hide the transaction amount via Pedersen commitments.

For privacy-preserving payment to infrastructure providers (VPS, domain registrars, hosting), Monero is the recommended option when the provider supports it. See hosts that accept Monero for the directory’s filter view.

Long form

Notice and takedown is the procedural mechanism connecting rightsholder notice to provider action:

1. Rightsholder identifies allegedly-infringing content.
2. Rightsholder sends a formally-compliant notice to the service provider’s designated agent.
3. Provider removes (or disables access to) the content.
4. Provider notifies the user.
5. (Optional) User submits a counter-notice; provider may restore content.
6. (Optional) Rightsholder files a court action.

The mechanism’s force comes from the safe-harbor incentive: providers act on notices because failing to do so risks losing the legal protection that lets them host user-uploaded content at all.

Key variants in 2026:

• DMCA Section 512 (US): the prototype. Bare-bones procedural requirements, low evidentiary bar, automated bots send millions of notices per year.
• EU Digital Services Act (2024): notice-and-action with formal procedure, requires a structured complaint, gives the user a meaningful opportunity to respond, requires court adjudication for contested cases. Procedurally heavier than DMCA.
• Country-specific implementations: vary widely. Some EU members (Romania, Sweden) have historically been slower to enforce than others (Germany, France).

For DMCA-ignored hosts, the practical question is: does this notice-and-takedown framework legally bind us, and if so, what’s the procedural bar? For Iceland-based hosts, the US DMCA does not bind; for EU-based hosts, the DSA does. See /jurisdictions for per-country analysis.

Long form

Object storage stores files as discrete “objects” in flat namespaces called “buckets”, accessed via HTTP API (PUT to upload, GET to retrieve). Different from:

• Block storage: presents as a disk; mounted to a VM.
• Filesystem storage: hierarchical directories; standard POSIX semantics.

Object storage is well-suited for:

• Static asset hosting (images, video, downloadable files).
• Backup destinations (Restic, Borg, Duplicacy all support S3 backends).
• Application file storage that scales beyond a single VPS disk.
• Cold archive: write-once, read-rarely data.

In this directory:

• BuyVM Block Storage Slabs — not strictly object storage but cheap per-GB block storage. With MinIO on top, you get an S3-compatible interface.
• Self-hosted MinIO, SeaweedFS, Garage on any provider — fully self-controlled S3-compatible object storage.
• Storj (out of directory) — decentralized S3-compatible storage. Privacy-friendly third party.

For DMCA-ignored hosting, object storage matters as the cheap-per-GB backup layer. You don’t want to pay VPS-tier prices for terabytes of cold storage; offload to S3-compatible storage and keep the VPS lean.

Long form

“Offshore” in this context inherits the meaning from offshore banking — infrastructure deliberately placed in a jurisdiction other than where the customer (or the customer’s adversaries) sits, in order to gain a legal-distance advantage. Common motivations: free-speech protection, distance from US-style copyright enforcement, distance from a politically hostile home government, corporate secrecy, sanctions evasion (which is generally illegal).

Note that “offshore” is jurisdiction-specific: a US-resident customer using an Icelandic host is offshore; an Icelandic customer using the same host is on-shore. The privacy advantage flows from the legal gap between your jurisdiction and your host’s, not from any inherent property of “offshoreness.”

Long form

A Tor onion service (formerly called “hidden service”) is a network service whose location is concealed by the Tor network. Clients connect to the service via a .onion address (e.g. expyuzz4wqqyqhjn.onion), which resolves through Tor’s distributed hidden-service directory rather than DNS.

Key properties:

• Operator IP is concealed from clients. The host knows the IP (it’s their datacenter), but the public does not.
• End-to-end encrypted by construction. Traffic between client and onion service is encrypted at each Tor hop.
• No certificate authority involved for v3 onion addresses — the address itself is a long-form public key.

Onion services are used for whistleblowing platforms (SecureDrop), censorship-resistant publishing, anonymous chat (Ricochet Refresh), and any application where the operator does not want their server location publicly knowable.

For the operational guide to hosting one, see How to host a Tor hidden service.

Long form

A PTR (pointer) record provides the reverse lookup for an IP address. Where a forward A record maps mail.example.com → 1.2.3.4, the reverse PTR maps 1.2.3.4 → mail.example.com. For most hosting workloads PTR is irrelevant — but for outbound email it is essential.

Major mailbox providers (Gmail, Outlook/Office 365, Apple iCloud Mail) check that:

1. The PTR for the sending IP matches a hostname.
2. That hostname has a forward A record pointing back to the same IP.
3. The hostname matches (or aligns with) the SMTP HELO/EHLO greeting.

A VPS without a customized PTR will have a default like host-1-2-3-4.dc.provider.net. Mail from that IP will fail or land in spam. Most VPS providers, including the privacy-focused ones in this directory, expose a PTR-edit field in their control panel — set it before sending mail.

For self-hosted email playbook, see Anonymous email hosting.

Long form

A reverse proxy is the inverse of a forward proxy: clients connect to the proxy, which forwards to the actual application server (the origin). For privacy-focused hosting use cases, reverse proxies provide:

• TLS termination: the proxy holds the SSL certificate; the origin can run HTTP-only on localhost.
• Origin IP hiding: from the public internet, only the proxy’s IP is visible.
• Caching: edge cache for static assets reduces origin load.
• Rate limiting: blocks abusive clients before they reach the application.
• Authentication: pre-authenticate requests at the edge.

Common 2026 choices:

• Caddy — easiest config; auto-Let’s-Encrypt by default. Recommended for most self-hosted setups.
• Nginx — battle-tested, infinite configurability, used at scale.
• Traefik — auto-discovery for Docker / Kubernetes deployments.
• HAProxy — TCP-level load balancing, less common for HTTP-only workloads.

For DMCA-ignored hosting: a self-hosted reverse proxy on a separate offshore VPS is the privacy-aligned replacement for Cloudflare. See /guides/migrate-from-cloudflare.

Long form

Safe harbor under DMCA Section 512 is the legal mechanism that allows US-based online service providers (hosts, social networks, cloud platforms) to host user-generated content without being treated as primary infringers themselves. The protection is conditional: the provider must implement a notice-and-takedown procedure, designate a DMCA agent, and act expeditiously on properly-formatted notices.

This regime is the reason DMCA notices have practical force in the US: providers act on them not because they have to in any specific case, but because failing to do so risks losing safe-harbor status across all their hosted content.

Outside the US, safe harbor does not apply. Providers in Iceland, Sweden, Romania, the Netherlands, Malaysia, etc. are not eligible for DMCA safe harbor (they have no US copyright claim against them in the first place) and therefore have no statutory incentive to act on US-issued notices. They operate under their own jurisdiction’s equivalent law (or absence thereof) and evaluate complaints accordingly. This is the structural reason “DMCA-ignored” hosting exists.

Long form

The three pillars of modern email authentication:

• SPF (Sender Policy Framework): a TXT record on your domain listing the IPs / hostnames authorized to send mail for it. Receiving servers check this against the connecting IP.
• DKIM (DomainKeys Identified Mail): cryptographically signs each outgoing message; the signature is verifiable via a TXT record under selector._domainkey.yourdomain.com.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): a policy TXT record telling receiving servers what to do when SPF / DKIM fail (none / quarantine / reject). Also enables reports back to you.

For self-hosted email on a no-KYC offshore VPS:

• All three are mandatory in 2026. Gmail, Outlook, Apple Mail aggressively reject mail without proper authentication.
• rDNS / PTR is required in addition (see /glossary#rdns—ptr-record).
• MTA-STS and TLS-RPT are increasingly required (DNS-published TLS policy and reporting).

Setup is automated by modern self-hosted mail stacks (Mail-in-a-Box, Mailcow, Stalwart, Mailu). Manual setup possible but error-prone.

For the operational guide see /guides/anonymous-email-hosting.

Long form

Tor is the most widely-used anonymity network. Client traffic enters at a guard relay, transits a middle relay, and exits at an exit relay (clearnet) or stays inside Tor (onion service). At each hop, only one layer of encryption is removed, so no single relay knows both the source and destination of any given circuit.

For privacy-focused hosting use cases, Tor matters in three ways:

1. Client-side anonymity at signup: signing up for a hosting account over Tor prevents the provider from learning your real IP at the signup-time interaction.
2. Management anonymity: SSHing to your VPS via Tor prevents your home IP from appearing in the provider’s access logs.
3. Server-side anonymity via onion services: a service can be reachable only through .onion addresses, with no clearnet exposure.

For the operational guide to running services over Tor, see How to host a Tor hidden service.

Long form

A Tor relay is a server that participates in the Tor network. There are three relay roles:

• Guard relay: clients connect into the network here. Sees client IP but not destination.
• Middle relay: relays traffic between guard and exit. Sees nothing useful.
• Exit relay: traffic exits from Tor to the clearnet here. Sees destination but not client. Receives all the abuse complaints (DMCA notices, spam complaints, etc.) for clearnet traffic.

For DMCA-ignored hosting purposes, exit relays are the most relevant. Operators who want to contribute exit-relay capacity to the Tor network need:

• A host that permits Tor exit operation in its AUP. Many mainstream hosts forbid it.
• A jurisdiction that doesn’t auto-act on every DMCA notice. Iceland, Romania, Netherlands, Sweden are common picks.
• Bandwidth allowance suitable for sustained traffic (typically 100GB-1TB+ per month).

In this directory, FlokiNET, Privex, BuyVM Luxembourg, and HostHatch’s non-US locations are all known to permit Tor exit relays per their AUPs (verify at signup).

The Tor Project maintains a list of recommended exit-relay-friendly hosts which substantially overlaps with this directory.

For running a hidden service rather than an exit relay, see How to host a Tor hidden service.

Long form

A WAF inspects HTTP requests and responses for application-layer attacks that traditional network firewalls miss. Common WAF detections:

• SQL injection attempts.
• Cross-site scripting (XSS).
• Path traversal (../ patterns).
• Known CVEs against popular CMS / framework versions.
• Bot traffic / scrapers.

For DMCA-ignored hosting purposes, the choice is:

• Cloudflare WAF — easy but ties you to Cloudflare’s content policies. See /faq#cloudflare-and-dmca.
• Self-hosted ModSecurity — open-source, runs in nginx / Apache; OWASP Core Rule Set is the standard.
• Coraza — newer Go-based ModSecurity-compatible WAF; cleaner architecture.
• BunnyCDN WAF — commercial alternative to Cloudflare with more permissive AUP.

For most self-hosted setups, Caddy with a few rate-limiting rules + good application-side input validation suffices. WAFs catch some attacks but aren’t a substitute for secure application code.

For high-traffic / high-attack workloads, a self-hosted Coraza in front of the application provides Cloudflare-WAF-equivalent protection without third-party content-policy exposure.

Long form

Warrant canaries emerged in response to US legal regimes that prohibit a service provider from disclosing the receipt of certain kinds of legal process (notably National Security Letters with non-disclosure provisions). The mechanism: the provider publishes a periodic statement saying “we have not received any such order as of [date].” If they ever do receive one, they cease updating the statement; users notice the omission and infer.

In practice, warrant canaries have:

• Mixed legal standing: courts have not definitively ruled whether removal of a canary constitutes the prohibited “disclosure.” US providers have adopted different positions.
• Mostly fallen out of fashion: the legal uncertainty plus the surveillance-focused use case (NSLs are US-specific) has made them less common in 2026 than in the 2014-2018 peak.
• Limited applicability outside the US: most non-US jurisdictions don’t have the gag-order regime that motivates the canary in the first place.

For DMCA-ignored hosting purposes, warrant canaries are not the most useful signal. More important:

• Published transparency reports (Infomaniak, Njalla and others publish quantified takedown data).
• Operator track record (does the host have a public history of pushback?).
• Jurisdiction (does the host’s jurisdiction even allow the kind of legal process you’re worried about?).

A few non-US providers do publish canary-like statements; treat them as a low-priority signal compared to the structural factors above.

Long form

When you register a domain, the registry stores contact information (name, address, email, phone) for the registrant. By default this data is queryable by anyone via WHOIS / RDAP. WHOIS privacy is a paid (or free) service from your registrar that substitutes the registrar’s own proxy address for yours in the public record.

Limits of WHOIS privacy:

• Your real data is still on file with the registrar.
• It is disclosable under court order, ICANN dispute proceedings, or law-enforcement request.
• Some ccTLDs (.us, .fr, .de, etc.) prohibit privacy services and require real registrant data to be public.

For a stronger model, see Njalla’s owns-on-behalf approach, where the registrant of record is the registrar itself rather than you.

Long form

WireGuard is a VPN protocol developed by Jason Donenfeld and merged into the Linux kernel in 2020. Compared to predecessors (OpenVPN, IPsec):

• Simpler: smaller codebase = fewer bugs = easier to audit.
• Faster: better throughput, lower latency, less CPU.
• Modern crypto: uses Curve25519, ChaCha20, Poly1305 — current-generation primitives.
• Smaller config: a working WireGuard setup is a 10-line file.

For DMCA-ignored hosting, WireGuard is useful in several places:

• Manage VPS over WireGuard instead of SSH-over-Tor when latency matters more than maximum anonymity.
• Connect personal devices to a self-hosted “private LAN” (Tailscale uses WireGuard underneath; Headscale is the open-source self-hosted Tailscale equivalent).
• VPN provider implementation (Mullvad, IVPN, ProtonVPN all support WireGuard).
• Site-to-site mesh between multiple offshore VPS for cross-jurisdiction private networking.

Setup is straightforward: apt install wireguard-tools, generate keys with wg genkey, write a wg0.conf, wg-quick up wg0. Done.

For self-hosted private LAN use cases, Tailscale (managed) or Headscale (self-hosted) sit on top of WireGuard with auto-mesh and key-distribution. Both work well at no-KYC offshore VPS providers.