Own your identity. No registrars. No platforms. Just your keys.
PKARR turns Ed25519 public keys into domain names that you truly own. Publish DNS records to the Mainline DHT without relying on a registrar or platform.
Where we are going, this https://o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy resolves everywhere!
| Guide | Description |
|---|---|
| Introduction | Philosophy, concepts, and why PKARR exists |
| Quickstart | Get started in 5 minutes |
| Integration Guide | Embedding Pkarr in your application |
| Feature Reference | Cargo feature flags and configurations |
| API Reference | Full Rust API documentation |
| Examples | Code samples |
| Specifications | Protocol design documents |
pkarr— The Rust library for creating and verifying signed DNS packets, then publishing and resolving them over the DHT or HTTP relays. Its README covers installation, features, and a runnable example.pkarr-relay— An HTTP-to-DHT gateway that lets browsers and other UDP-restricted clients publish and resolve Pkarr packets. Its README covers installation and configuration.@synonymdev/pkarr— JavaScript/WASM bindings for using Pkarr in browsers and Node.js.
Try the web app to resolve records in your browser.
- Generate a keypair — Your public key becomes your domain name
- Sign DNS records — Standard A, AAAA, TXT, CNAME records, self-signed
- Publish to the DHT — Records are stored on the Mainline DHT
- Resolve anywhere — Anyone can query and verify your records
sequenceDiagram
participant Client
participant Relay
participant DHT
Client->>Relay: Publish signed packet
Relay->>DHT: Store (BEP44)
Client->>Relay: Resolve public key
Relay->>DHT: Query
DHT->>Relay: Signed packet
Relay->>Client: Verified response
The default native client configures both DHT and relay backends.
ClientBuilder can select DHT-only or relay-only operation, and ResolvePolicy
controls whether a lookup uses cached data or queries the configured
backends. See the integration
guide for configuration examples.
PKARR uses the Mainline DHT, the same peer-to-peer network that powers BitTorrent. Records are stored using BEP44 (mutable items). With 15 years of proven reliability and 10+ million active nodes, there's no need to bootstrap a new network.
- Records are ephemeral — The DHT drops records after hours; republish periodically
- 1000-byte limit — PKARR is for discovery, not storage
- Caching everywhere — Clients and relays cache aggressively for performance
- Relays for browsers — Web apps use HTTP relays since browsers cannot open UDP sockets
Why not blockchain domains (ENS, Handshake)?
Blockchain domains introduce artificial scarcity, transaction fees, and chain dependencies. PKARR uses public keys directly—infinite supply, zero fees, no chain lock-in.
Why not GNU Name System?
GNS is sophisticated but requires the full GNU net stack. PKARR takes a minimalist approach: leverage existing infrastructure (Mainline DHT) and leave advanced features to application layers. Both use Ed25519, so migration paths exist.
Why Mainline DHT specifically?
It already exists. 15 years of reliability, 10+ million nodes, implementations in most languages. No need to bootstrap a new network or convince people to join.
What about human-readable names?
Public keys are not memorable by design—memorable names require registries, and registries introduce centralization. Build petname systems, phonebooks, or DNS bridges on top of PKARR if you need human-friendly names.