Summary

  • RFC 3375 described a shared registration system in which registrars could create and manage sponsored domain objects, while one registry remained authoritative for each namespace and zone.
  • It also separated identifier continuity, sponsorship, shared-resource association, transfer, registry transaction status and DNS publication. Success at one layer was not proof of authority or completion at the next.

Imagine a registrant asking a retail registrar to create a domain. The registrar accepts the instruction, authenticates to a registry and submits a command. The registry creates an object. Later, the domain may move to a different registrar while its identity persists. A name server controlled through the first registrar may also serve a domain sponsored by the second. Eventually, selected registry data becomes an authoritative DNS zone. These actions belong to one service, but they are not one fact.

RFC 3375, published in September 2002 as an Informational document, turned that institutional separation into requirements for a generic registry–registrar protocol. It did not define an Internet Standard, certify an implementation or prove adoption. Its historical importance lies in the boundaries it made explicit just as shared domain registration was becoming infrastructure rather than an administrative exception.

The document named three roles. A registrant registers names through a registrar. A registrar presents services to registrants and accesses a registry. A registry maintains the central repository associated with delegations and is typically responsible for producing and distributing zone files. In a shared system, multiple independent registrars use the same registry service through a loose coupling.

That loose coupling redistributed commercial access without dissolving technical authority. RFC 3375 said there was one and only one registry authoritative for a given namespace and zone, although one registry could serve several namespaces. The registrar therefore possessed a management channel, not a fragment of the namespace’s ultimate authority. Competition could exist at the customer interface while the coherence of the namespace remained centralized.

The protocol had to support sessions, queries, creation, updating, renewal, deletion and transfer. It also needed authentication, authorization, status reporting and transaction identifiers. An identifier attached to a modifying operation made the exchange traceable. A success response showed that the registry had accepted or performed a registry operation. It did not demonstrate why the registrant wanted the change, whether a zone-file projection had occurred, whether every authoritative server had loaded it, or what a remote resolver could observe.

RFC 3375 treated objects as durable things rather than disposable rows. Every object needed a globally unique identifier. That identifier was to remain unchanged for the object’s lifetime in a repository even if administrative control changed. The rule separated identity from custody: a transfer could change the sponsoring registrar without pretending that an entirely new domain, contact or server object had been born.

That distinction mattered especially for shared resources. A name-server object might be useful to domains sponsored by different registrars. The RFC’s example allowed a registrar to associate an existing server object with its own domain even when another registrar administered that server object. Reference did not grant control. Otherwise, a registrar that merely used a shared server could alter a resource on which other registrants depended.

Transfers were therefore a controlled change of sponsorship, not a casual rewrite. The prospective new administrator initiated the request; the system needed to confirm authorization, describe associated objects, report transfer state, allow cancellation before a decision and notify the parties of approval or rejection. When in-zone name servers moved with a domain, the protocol had to make those consequences legible. A stable identifier could cross the change while the audit trail recorded who obtained which powers.

The document also accommodated thick and thin registries. A thick registry stored both delegation data and the social or contact information associated with registrations. A thin model divided some of that information between registry and registrars. The requirements were meant to support both. They supplied a minimum common grammar without asserting that every operator had to converge on the same repository design.

The DNS boundary is the most easily blurred. RFC 3375 assigned registries the production of zone files for namespaces they served. RFC 1034 and RFC 1035 describe authoritative DNS data, servers, caches and resolution. RFC 2136 describes dynamic update to DNS zones. Those mechanisms connect, but a registry object and a DNS resource record are not interchangeable receipts. An accepted renewal, contact change or transfer can be real even when it has no immediate zone effect; a delegation change can require a later publication and loading sequence before it is visible through resolution.

Earlier work such as RFC 2832 had already specified the Registry Registrar Protocol. RFC 3375 abstracted the functional requirements. RFC 3730 then specified the Extensible Provisioning Protocol, and RFC 5730 later replaced that base specification while RFC 5731, RFC 5732 and RFC 5733 defined mappings for domains, hosts and contacts. This chronology shows specification work refining a shared interface. It does not establish that every registry implemented every feature, used the same data model or delivered the same operational timing.

The normative vocabulary of RFC 2119 helps read the document without inflating it: MUST and SHOULD express requirements inside the proposed protocol design, not proof about the outside world. RFC 2277’s internationalization policy is another period constraint. A global registration protocol had to encounter language and character questions without converting human names, legal relationships and DNS identifiers into a single undifferentiated field.

Lu Heng’s “Minimum Initial Specification” offers a useful lens. A shared protocol can define the smallest interoperable action while leaving local policy and later decisions to the responsible institutions. “On Reality Layers” sharpens the audit: registrant request, registrar authorization, object sponsorship, registry acceptance, repository state, zone generation, authoritative service and resolver observation are linked claims, but none can substitute for all the others.

That is the durable lesson of RFC 3375. The Internet’s domain market could decentralize the storefront while retaining a singular authoritative ledger for a namespace. It could let an object change custodians without changing identity, and let another registrar reference a shared object without inheriting control. The resulting system scaled because it divided authority precisely. Its evidence must be divided with equal care.

Sources