Nomulus: a shared registry system for running top-level domains

The authoritative source, not a registrar

Nomulus is an open source, scalable, cloud-based service for operating top-level domains. The definition of its role is precise and worth holding onto. It is the authoritative source for the TLDs it runs, responsible for tracking domain name ownership and handling registrations, renewals, availability checks and RDAP requests. End-user registrants, meaning people or companies that want to register a domain, use an intermediate domain name registrar acting on their behalf to interact with the registry. So there are two audiences in that sentence and only one of them is the customer. A registrar is a reseller of names, and a registry is the body that owns the namespace. Nomulus is the second, and the software it runs is what a registry operator, a brand owner or a registry backer deploys. The primary language is Java, the licence is Apache-2.0, and the homepage is registry.google.

One system, many TLDs

The scaling claim is about namespaces rather than traffic. Nomulus can run any number of TLDs in a single shared registry system using horizontal scaling, and it is the software Google Registry uses to operate TLDs such as .google, .app, .how, .soy and .みんな. That is a meaningful piece of evidence, because running .google and .app are very different businesses with different registry agreements, different premium pricing strategies and different launch timelines in one codebase. The architectural consequence is that the TLD is a configuration object rather than a deployment, and the administrative tool is described as performing the full range of administrative tasks needed to manage a running registry system, including creating and configuring new TLDs. That is the piece a sponsor or a registry operator would care about most, since the difference between launching a second TLD and launching a first one is usually the difference between a configuration change and a new system.

EPP, RDAP and the DNS interface

Three interfaces carry the traffic. EPP, the Extensible Provisioning Protocol, is the XML protocol that is the standard format for communication between registrars and registries, and it includes operations for registering, renewing, checking, updating and transferring domain names. RDAP is a JSON API that returns structured, machine-readable information about domain name ownership, and the description is that it is essentially a newer version of WHOIS, which is the whole argument for its existence, since WHOIS returns unstructured text. The DNS interface is a pluggable interface that can be implemented to handle different DNS providers, with a sample implementation using Google Cloud DNS and an RFC 2136 compliant implementation that works with BIND. The caveat on Google Cloud DNS is specific and worth noting: if you use it, you may need to understand its capabilities and provide your own multi-AS solution, because a registry zone is not an ordinary zone.

The obligations a registry carries

Several of the capabilities exist because ICANN requires them, and that shapes what a deployment involves. Registry Data Escrow is a daily export of all ownership information for a TLD to a third-party escrow provider, to allow a take-over by another registry operator in the event of serious failure, and it is required by ICANN for all new gTLDs. Brand protection for trademark holders via TMCH allows rights-holders to block registration of domains using their trademark, and that too is required for all new gTLDs. Reporting covers the required external reporting such as ICANN monthly registry reports, CZDS, billing and registration activity, as well as internal reporting using BigQuery. Premium pricing communicates prices for highly desirable domain names with configurable registration and renewal prices, and an extensible interface allows fully programmatic pricing. Registration periods covers the standard gTLD lifecycle, with Qualified Launch Partner, Sunrise, Landrush, Claims and General Availability periods all supported.

Billing history and the registrar console

Two features exist for the registrars rather than for the registry operator, and they are what a TLD actually sells. Billing history records a full history of all billable events, suitable for ingestion into an invoicing system, which matters because a registry's revenue is a stream of per-domain charges against a schedule that changes with the launch phase. The registrar support console is a self-service web console that registrars use to manage their accounts in the registry system, which includes the credential and contact management that a registry has to expose without becoming a support burden. The project description also says end-user registrants interact through an intermediate registrar, and the repository root shows where that console lives, with a `console-webapp/` directory alongside the `core/` HTTP server, the `proxy/` for the EPP proxy, and a `prober/` for monitoring.

The EPP proxy, and why a servlet container cannot speak EPP

The TCP proxy is the piece of the architecture that explains a lot of the repository layout. Nomulus is built on top of the Jetty container implementing the Jakarta Servlet specification, and it only serves HTTP/S traffic. EPP, however, is raw TCP, so a proxy is provided to translate raw TCP traffic to and from HTTP. The deployment options are given and they are a real design decision. The proxy can run in a separate cluster and communicate to Nomulus public HTTP endpoints via the Internet, or it can run as a sidecar with the Nomulus image in the same pod and communicate via loopback. The second is the tighter option, since the traffic never leaves the host, while the first lets you scale the two independently and reuse the proxy across several registry deployments. The separate release tag naming in the recent versions, with proxy releases appearing alongside nomulus releases, reflects that the proxy is released as its own artefact.

What it takes to actually run it

The README is short on setup and points to the install guide in `docs/install.md`, and the honest summary is that this is infrastructure rather than a library. Nomulus runs on Google Kubernetes Engine, so a deployment is a Kubernetes cluster, a build pipeline and a set of credentials for the surrounding Google services. The repository layout confirms the shape of the work. There is `core/` for the main HTTP server, `proxy/` for the EPP proxy, `common/`, `util/`, `processor/` for the registrar flows, `jetty/`, `networking/`, `db/` for the schema, `integration/` for the end-to-end tests, `load-testing/`, `testing/`, `eppbindings/` for the EPP protocol bindings, `config/` and a `vnames.json`, and the build is Gradle with `gradlew`, `gradlew.bat`, `gradle.lockfile` and `buildscript-gradle.lockfile` for reproducible dependency resolution. The `release/` directory and the dated release tags, nomulus-20261015-RC00 and nomulus-20261014-RC00, show a continuous release train rather than versioned milestones. The two source trees the README points at are the main HTTP server and the EPP proxy, both under the same Java package:

core/src/main/java/google/registry
proxy/src/main/java/google/registry

Editorial conclusion

Adopt Nomulus if you are an ICANN-accredited registry operator or a sponsor building a new gTLD, since it implements the launch lifecycle, RDE, TMCH and reporting that the ICANN agreement requires rather than just a domain API. Skip it if you want to run a domain reseller, because registrars talk to the registry through EPP and do not need this system. Before you plan a deployment, confirm you can live inside Google Cloud, since Nomulus runs on Google Kubernetes Engine and uses Google Cloud DNS, Cloud Secret Manager and BigQuery, and read the install guide in the `docs/` directory, then introduce yourself on the nomulus-discuss group, which the README asks anyone intending to run a production registry to do.

Frequently asked questions

Official sources

1. google/nomulus on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases