Top-level domain name registry service on Google Cloud Platform
Find a file
weiminyu 7c64992c73 Cloned from CL 251456914 by 'g4 patch'.
Original change by cpovirk@cpovirk:rosie251284456-0055_Rosie:31511:citc on 2019/06/04 09:48:27.

Update to Truth 0.45, and address deprecations.

Renames may include:
- containsAllOf => containsAtLeast
- containsAllIn => containsAtLeastElementsIn
- isSameAs => isSameInstanceAs
- isOrdered => isInOrder
- isStrictlyOrdered => isInStrictOrder

The other major change is to change custom subjects to extend raw Subject instead of supplying type parameters. The type parameters are being removed from Subject. This CL will temporarily produce rawtypes warnings, which will go away when I remove the type parameters (as soon as this batch of CLs is submitted).

Some CLs in this batch also migrate calls away from actualAsString(). Its literal replacement is `"<" + actual + ">"` (unless an object overrides actualCustomStringRepresentation()), but usually I've made a larger change, such as switching from an old-style "Not true that..." failure message to one generated with the Fact API. In that case, the new code usually contains a direct reference to this.actual (a field that I occasionally had to create). Another larger change I sometimes made is to switch from a manual check-and-fail approach to instead use check(...). And sometimes I just remove a withMessage() call that's no longer necessary now that the code uses check(...), or I introduce a check(...) call. (An assertion made with check(...) automatically includes the actual value from the original subject, so there's no need to set it again with withMessage().)

Finally, there's one CL in this batch in which I migrate a Correspondence subclass to instead use Correspondence.from.

END_PUBLIC

If this is too many changes at once, let me know, and I can split it up and/or explain further. In the past, I've erred on the side of sending separate CLs for each change, which has required some owners to manually reapply each one, so now I'm trying this way.

Thanks again for your patience. There is an outside chance that this will be the last CL I send you before Truth 1.0 -- but certainly no promises :)

More information:
  Renames:
    []
    []
    []
  Removing type parameters: []
  Migration from old fail*(...) methods to new ones and to check(...): []
  Changes that replace assert*(...) with introduce check(...): []
  Correspondence subclass to Correspondence.from: []

Tested:
    TAP --sample ran all affected tests and none failed
    []

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=251921007
2019-06-07 11:46:44 -04:00
docs De-duplicate flow documentation error reasons on a per-code basis 2019-06-06 10:51:43 -04:00
gradle Cloned from CL 251456914 by 'g4 patch'. 2019-06-07 11:46:44 -04:00
java Cloned from CL 251456914 by 'g4 patch'. 2019-06-07 11:46:44 -04:00
javatests/google/registry Cloned from CL 251456914 by 'g4 patch'. 2019-06-07 11:46:44 -04:00
python LSC: Mark Python binaries with explicit python_version. 2019-04-26 23:51:31 -04:00
release Fix builder error 2019-06-07 11:44:57 -04:00
third_party Update Nomulus to build with bazel 0.16.0 2018-08-10 13:46:48 -04:00
.gcloudignore Do not track IntelliJ files in SCM 2019-05-13 12:33:15 -04:00
.gitignore Do not track IntelliJ files in SCM 2019-05-13 12:33:15 -04:00
.travis.yml Use the GCS repository when pulling dependencies in CI 2019-04-26 23:56:20 -04:00
AUTHORS Change all references to Domain Registry to Nomulus 2016-10-14 16:58:07 -04:00
CONTRIBUTING.md Add Google Java Style Guide info and link to CONTRIBUTING.md 2016-11-15 11:01:16 -05:00
CONTRIBUTORS Export Weimin as author of commits to GitHub 2018-07-14 01:37:03 -04:00
LICENSE Rename LICENSE.txt to LICENSE 2016-07-13 15:26:51 -04:00
nomulus-logo.png Update Nomulus logo 2017-05-23 17:22:49 -04:00
README.md Fix travis build badge link 2019-01-08 11:03:28 -05:00
WORKSPACE Update to bazel 0.25.0 2019-05-06 16:36:04 -04:00

Nomulus

Bazel Gradle
Build Status Build Status

Nomulus logo

Overview

Nomulus is an open source, scalable, cloud-based service for operating top-level domains (TLDs). It is the authoritative source for the TLDs that it runs, meaning that it is responsible for tracking domain name ownership and handling registrations, renewals, availability checks, and WHOIS requests. End-user registrants (i.e. people or companies that want to register a domain name) use an intermediate domain name registrar acting on their behalf to interact with the registry.

Nomulus runs on Google App Engine and is written primarily in Java. It is the software that Google Registry uses to operate TLDs such as .google, .app, .how, .soy, and .みんな. It can run any number of TLDs in a single shared registry system using horizontal scaling. Its source code is publicly available in this repository under the Apache 2.0 free and open source license.

Getting started

The following resources provide information on getting the code and setting up a running system:

If you are thinking about running a production registry service using our platform, please drop by the user group and introduce yourself and your use case. To report issues or make contributions, use GitHub issues and pull requests.

Capabilities

Nomulus has the following capabilities:

  • Extensible Provisioning Protocol (EPP): An XML protocol that is the standard format for communication between registrars and registries. It includes operations for registering, renewing, checking, updating, and transferring domain names.
  • DNS interface: The registry provides a pluggable interface that can be implemented to handle different DNS providers. It includes a sample implementation using Google Cloud DNS as well as an RFC 2136 compliant implementation that works with BIND.
  • WHOIS: A text-based protocol that returns ownership and contact information on registered domain names.
  • Registration Data Access Protocol (RDAP): A JSON API that returns structured, machine-readable information about domain name ownership. It is essentially a newer version of WHOIS.
  • Registry Data Escrow (RDE): A daily export of all ownership information for a TLD to a third party escrow provider to allow take-over by another registry operator in the event of serious failure. This is required by ICANN for all new gTLDs.
  • Premium pricing: Communicates prices for premium domain names (i.e. those that are highly desirable) and supports configurable premium registration and renewal prices. An extensible interface allows fully programmatic pricing.
  • Billing history: A full history of all billable events is recorded, suitable for ingestion into an invoicing system.
  • Registration periods: Qualified Launch Partner, Sunrise, Landrush, Claims, and General Availability periods of the standard gTLD lifecycle are all supported.
  • Brand protection for trademark holders (via TMCH): Allows rights-holders to protect their brands by blocking registration of domains using their trademark. This is required by ICANN for all new gTLDs.
  • Registrar support console: A self-service web console that registrars can use to manage their accounts in the registry system.
  • Reporting: Support for required external reporting (such as ICANN monthly registry reports, CZDS, Billing and Registration Activity) as well as internal reporting using BigQuery.
  • Administrative tool: Performs the full range of administrative tasks needed to manage a running registry system, including creating and configuring new TLDs.
  • DNS interface: An interface for DNS operations is provided so you can write an implementation for your chosen provider, along with a sample implementation that uses Google Cloud DNS. If you are using Google Cloud DNS you may need to understand its capabilities and provide your own multi-AS solution.
  • GAE Proxy: App Engine Standard only serves HTTP/S traffic. A proxy to forward traffic on EPP and WHOIS ports to App Engine via HTTPS is provided. Instructions on setting up the proxy on Google Kubernetes Engine is available. Running the proxy on GKE supports IPv4 and IPv6 access, per ICANN's requirements for gTLDs. The proxy can also run as a single jar file, or on other Kubernetes providers, with modifications.

Additional components

Registry operators interested in deploying Nomulus will likely require some additional components that are need to be configured separately.

  • A way to invoice registrars for domain name registrations and accept payments. Nomulus records the information required to generate invoices in billing events.
  • Fully automated reporting to meet ICANN's requirements for gTLDs. Nomulus includes substantial reporting functionality but some additional work will be required by the operator in this area.
  • A secure method for storing cryptographic keys. A keyring interface is provided for plugging in your own implementation (see configuration doc for details).
  • System status and uptime monitoring.

Outside references

  • Donuts Registry has helped review the code and provided valuable feedback
  • CoCCa and FRED are other open-source registry platforms in use by many TLDs
  • We are not aware of any fully open source domain registrar projects, but open source EPP Toolkits (not yet tested with Nomulus; may require integration work) include:
  • Some Open Source DNS Projects that may be useful, but which we have not tested: