This fixes longstanding bug b/19430703 in which domain transfers that were server-approved would only handle the autorenew grace period correctly if the autorenew grace period was going to start within the transfer window. If the autorenew grace period was already active (e.g. the domain had recently autorenewed, before the transfer was requested), the logic would miss it, even if it was going to be active throughout the transfer window (i.e. it would still be active at the server-approval time). When the autorenew grace period is active at the time a transfer is approved (whether by the server or explicitly via DomainTransferApproveFlow), the correct behavior is to essentially "cancel" the autorenew - the losing registrar receives a refund for the autorenew charge, and the gaining registrar's transfer extended registration years are applied to the expiration time as it was prior to that autorenew. The way we implement this is that we just have the transfer essentially "subsume" the autorenew - we deduct 1 year from the transfer's extended registration years before extending the registration period from what the expiration time is post-autorenew at the moment of transfer approval. See b/19430703#comment17 for details on the policy justification; the only real ICANN document about this is https://www.icann.org/news/advisory-2002-06-06-en, but registrars informally document in many places that transfers will trigger autorenew grace, e.g. see https://support.google.com/domains/answer/3251236 There are still a few parts of this bug that remain unfixed: 1) RdeDomainImportAction repeats a lot of logic when handling imported domains that are in pending transfer, so it will also need to address this case in some way, but the policy choices there are unclear so I'm waiting until we know more about RDE import goals to figure out how to fix that. 2) Behavior at the millisecond edge cases is inconsistent - specifically, for the case where a transfer is requested such that the automatic transfer time is exactly the domain's expiration time (down to the millisecond), the correct behavior is a little unclear and this CL for now ignores this issue in favor of getting a fix for 99.999% of the issue into prod. See newly created b/35881941 for the gory details. Also, there are parts of this bug that will be fixed as parts of either b/25084229 (transfer exDate computations) or b/35110537 (disallowing transfers with extended registration years other than 1), both of which are less pressing. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=149024269 |
||
---|---|---|
docs | ||
java | ||
javatests/google/registry | ||
python | ||
scripts | ||
third_party/java | ||
.gitignore | ||
AUTHORS | ||
CONTRIBUTING.md | ||
CONTRIBUTORS | ||
LICENSE | ||
README.md | ||
WORKSPACE |
Nomulus
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, .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:
- Install guide
- View the source code in java/google/registry/
- Other docs
- Javadoc
- Nomulus discussion group, for any other questions
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.
Known issues
Registry operators interested in deploying Nomulus will likely require some additional components that are not provided out of the box.
Core dependencies
- A DNS system. 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.
- A proxy to forward traffic on EPP and WHOIS ports to App Engine via HTTPS, since App Engine Standard only serves HTTP/S traffic. The proxy must support IPv4 and IPv6 access to comply with ICANN's requirements for gTLDs.
Additional functionality
- 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: