Location-Independent Infrastructure Using NCC-02, NCC-05, and NCC-06
Most internet services still rely on DNS as the root of discovery and trust. Even systems that describe themselves as decentralised often fall back to domain names, certificate authorities, and fixed hostnames once you look closely at how clients actually connect.
This article explores how services can function without DNS at all, using patterns that emerged from the Nostr ecosystem and were formalised through NCC-02, NCC-05, and NCC-06. While these conventions originated alongside Nostr, they are not limited to relays or social protocols. The same approach applies to content systems such as IPFS, media services like Blossom, private APIs, admin panels, and self-hosted infrastructure operating in unreliable or hostile networks.
The shift is subtle but significant. Instead of asking which domain should I connect to, clients ask which service key am I trying to reach.
Why DNS Becomes a Liability
DNS was designed for a network where services were relatively static, operators were identifiable, and intermediaries were trusted by default. None of those assumptions reliably hold today.
A DNS-based service is tightly coupled to external authorities: registrars, certificate issuers, recursive resolvers, and often hosting providers. Blocking or interference at any of these layers is usually sufficient to disrupt access. Even when services use literal IP addresses, DNS frequently re-enters indirectly through TLS validation, discovery mechanisms, or bootstrap endpoints.
The problem is not that DNS fails occasionally. The problem is that DNS collapses naming, trust, and location into a single fragile abstraction.
Identity First, Location Second
NCC-02, NCC-05, and NCC-06 deliberately separate these concerns.
In this model, a service is defined by a cryptographic public key. That key represents identity and continuity. Where or how the service is reachable becomes contextual information rather than a defining property.
Endpoints are treated as descriptive hints, not authoritative truth. Resolution becomes a matter of retrieving signed data and applying deterministic rules, rather than trusting a global naming hierarchy.
This is the same conceptual shift Nostr made for users, applied consistently to services.
NCC-02: Service Records as Signed Intent
NCC-02 introduces the concept of a service record. A service record is a signed statement published by the service operator, asserting that a given public key represents a specific service and optionally describing how it may be reached.
Crucially, NCC-02 does not require a hostname, nor does it assume public reachability. A record may list multiple endpoints, a single endpoint, or none at all. It may change over time without breaking identity.
From the client’s perspective, a service record answers only one question. If this key is trusted, what does the operator currently claim about this service?
NCC-05: Reachability Without Exposure
NCC-05 extends the model by allowing endpoint information to be encrypted and scoped.
Many services should not expose their location publicly. Admin interfaces, private relays, region-restricted backends, and censorship-sensitive deployments all benefit from being discoverable without being globally reachable.
With NCC-05, a service can publish its existence openly while revealing connection details only to authorised clients. Onion addresses can be preferred without advertising them. IPv4 or IPv6 endpoints can exist purely as fallback. Endpoint ordering expresses operator intent rather than promise.
An observer may learn that a service exists without learning how to reach it. DNS has no way to express that distinction.
NCC-06: Resolution as Data Retrieval
NCC-06 describes how clients turn published records into an actual connection attempt.
Rather than querying a central resolver or directory, clients retrieve signed service records from relays. Multiple relays may carry the same records. Records may be stale, partial, or conflicting.
Instead of treating these conditions as errors, NCC-06 treats them as expected states. Clients verify signatures, discard expired data, apply deterministic conflict resolution, and select the best reachable endpoint they can see.
Resolution becomes a data problem, not a naming problem. If nothing is reachable, the service is considered unavailable rather than broken.
How This Differs From Existing Approaches
The distinction becomes clearer when compared to existing systems.
Traditional DNS and TLS rely on human-readable names backed by central authorities. ENS replaces registrars with a blockchain but still treats names as the primary abstraction, often routing users back to DNS-hosted endpoints. Tor onion services derive addresses from keys, but operate entirely within the Tor ecosystem and do not generalise cleanly across mixed transports.
IPFS excels at content addressing, but when services are layered on top, DNS-based gateways frequently reappear. Blossom media servers today typically rely on standard URLs and HTTPS, inheriting the same structural fragility as conventional web services.
NCC differs by identifying services themselves by keys, not content and not names, and resolving reachability using signed data rather than global lookup infrastructure.
What This Model Does Not Solve
Being explicit about limits matters.
This approach does not solve the first-contact trust problem. If a client is given the wrong service key, it will resolve the wrong service correctly. This is not unique to NCC. The same bootstrap problem exists with domain names, TLS certificates, ENS names, and onion addresses. Initial trust establishment remains a social or application-layer concern.
It does not eliminate traffic analysis. NCC-05 can hide endpoint details, but it does not make network traffic invisible. Timing and connection metadata remain observable, even when Tor is used. The goal is to reduce resolution visibility, not to defeat a global passive adversary.
It does not make denial-of-service attacks impossible. Relays can be flooded and endpoints can be exhausted. What NCC provides instead is graceful degradation through multiple resolution paths and cached records, without a single resolver whose failure breaks the system.
The model also deliberately avoids human-readable naming. Keys are not memorable, and that is a trade-off. Naming systems can exist on top, but NCC keeps naming out of the trust path to avoid reintroducing the same fragility.
Finally, this is not a universal replacement for DNS. DNS remains effective for public websites and mass-market discovery. NCC is intended for environments where mobility, privacy, and resistance to interference matter more than convenience.
The Structural Shift
What NCC-02, NCC-05, and NCC-06 describe is not a new protocol layer so much as a design pattern.
Services publish signed intent. Clients resolve by retrieving and validating data. Trust is anchored in keys, not names.
Once this separation is made explicit, DNS stops being foundational. It becomes optional infrastructure rather than an assumed root of trust.
That change is small in implementation, but significant in consequence.
Closing Note: A Pattern, Not a Platform
Although NCC-02, NCC-05, and NCC-06 emerged from the Nostr ecosystem, the ideas they encode are not tied to Nostr itself. They describe a general infrastructure pattern for service discovery and reachability in environments where DNS is fragile, politicised, or simply unavailable.
The pattern is portable. Any system that can sign data, publish it to a retrievable medium, and verify signatures can adopt the same approach. Nostr provides a convenient substrate today, but it is not a prerequisite.
Seen this way, the value of these conventions is not that they replace DNS everywhere, but that they demonstrate how services can function cleanly without it when required. They make explicit a separation that has long been implicit: identity does not need to imply location, and discovery does not need to depend on names.
That distinction is likely to become more important, not less, as services continue to become more mobile, more private, and more contested at the network edge.
References
NCC-02 – Service Records https://github.com/imattau/ncc-02
NCC-05 – Dynamic and Encrypted Locators https://github.com/imattau/ncc-05
NCC-06 – Service Resolution and Sidecar Publishing https://github.com/imattau/ncc-06
npm Libraries
Reference implementations of the NCC conventions are also available as JavaScript libraries on npm. These are intended for client applications, tooling, and sidecar services rather than for defining the specifications themselves.
ncc-02-js https://www.npmjs.com/package/ncc-02-js
ncc-05-js https://www.npmjs.com/package/ncc-05-js
ncc-06-js https://www.npmjs.com/package/ncc-06-js
The libraries provide typed helpers, validation logic, and record-handling utilities aligned with the conventions, and are suitable for use in browsers, Node.js clients, and service sidecars.
#Nostr #DecentralisedInfrastructure #ProtocolDesign #DistributedSystems #ServiceDiscovery #CryptographicIdentity #PrivacyEngineering #CensorshipResistance #IPFS #Tor #SelfHosted #EdgeInfrastructure #NetworkResilience #nostrdev
