PKARR

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!

Documentation

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

Crates and Packages

• 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.

Demo

Try the web app to resolve records in your browser.

How It Works

1. Generate a keypair — Your public key becomes your domain name
2. Sign DNS records — Standard A, AAAA, TXT, CNAME records, self-signed
3. Publish to the DHT — Records are stored on the Mainline DHT
4. 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.

The Network

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.

Key Points

• 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

FAQ

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.

License

MIT