mirror of
https://github.com/google/nomulus
synced 2026-01-04 20:24:22 +00:00
Autoformat all Markdown documentation
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=132885981
This commit is contained in:
mcilwain
130
README.md
130
README.md
@@ -15,10 +15,10 @@ the Markdown documents in the `docs` directory.
|
||||
|
||||
When it comes to internet land, ownership flows down the following hierarchy:
|
||||
|
||||
1. [ICANN][icann]
|
||||
2. [Registries][registry] (e.g. Google Registry)
|
||||
3. [Registrars][registrar] (e.g. Google Domains)
|
||||
4. Registrants (e.g. you)
|
||||
1. [ICANN][icann]
|
||||
2. [Registries][registry] (e.g. Google Registry)
|
||||
3. [Registrars][registrar] (e.g. Google Domains)
|
||||
4. Registrants (e.g. you)
|
||||
|
||||
A registry is any organization that operates an entire top-level domain. For
|
||||
example, Verisign controls all the .COM domains and Affilias controls all the
|
||||
@@ -50,9 +50,9 @@ are limited to four minutes and ten megabytes in size. Furthermore, queries and
|
||||
indexes that span entity groups are always eventually consistent, which means
|
||||
they could take seconds, and very rarely, days to update. While most online
|
||||
services find eventual consistency useful, it is not appropriate for a service
|
||||
conducting financial exchanges. Therefore Domain Registry has been engineered
|
||||
to employ performance and complexity tradeoffs that allow strong consistency to
|
||||
be applied throughout the codebase.
|
||||
conducting financial exchanges. Therefore Domain Registry has been engineered to
|
||||
employ performance and complexity tradeoffs that allow strong consistency to be
|
||||
applied throughout the codebase.
|
||||
|
||||
Domain Registry has a commit log system. Commit logs are retained in datastore
|
||||
for thirty days. They are also streamed to Cloud Storage for backup purposes.
|
||||
@@ -63,8 +63,8 @@ order to do restores. Each EPP resource entity also stores a map of its past
|
||||
mutations with 24-hour granularity. This makes it possible to have point-in-time
|
||||
projection queries with effectively no overhead.
|
||||
|
||||
The Registry Data Escrow (RDE) system is also built with reliability in mind.
|
||||
It executes on top of App Engine task queues, which can be double-executed and
|
||||
The Registry Data Escrow (RDE) system is also built with reliability in mind. It
|
||||
executes on top of App Engine task queues, which can be double-executed and
|
||||
therefore require operations to be idempotent. RDE isn't idempotent. To work
|
||||
around this, RDE uses datastore transactions to achieve mutual exclusion and
|
||||
serialization. We call this the "Locking Rolling Cursor Pattern." One benefit of
|
||||
@@ -94,14 +94,15 @@ proxy listening on port 700. Poll message support is also included.
|
||||
To supplement EPP, Domain Registry also provides a public API for performing
|
||||
domain availability checks. This service listens on the `/check` path.
|
||||
|
||||
* [RFC 5730: EPP](http://tools.ietf.org/html/rfc5730)
|
||||
* [RFC 5731: EPP Domain Mapping](http://tools.ietf.org/html/rfc5731)
|
||||
* [RFC 5732: EPP Host Mapping](http://tools.ietf.org/html/rfc5732)
|
||||
* [RFC 5733: EPP Contact Mapping](http://tools.ietf.org/html/rfc5733)
|
||||
* [RFC 3915: EPP Grace Period Mapping](http://tools.ietf.org/html/rfc3915)
|
||||
* [RFC 5734: EPP Transport over TCP](http://tools.ietf.org/html/rfc5734)
|
||||
* [RFC 5910: EPP DNSSEC Mapping](http://tools.ietf.org/html/rfc5910)
|
||||
* [Draft: EPP Launch Phase Mapping (Proposed)](http://tools.ietf.org/html/draft-tan-epp-launchphase-11)
|
||||
* [RFC 5730: EPP](http://tools.ietf.org/html/rfc5730)
|
||||
* [RFC 5731: EPP Domain Mapping](http://tools.ietf.org/html/rfc5731)
|
||||
* [RFC 5732: EPP Host Mapping](http://tools.ietf.org/html/rfc5732)
|
||||
* [RFC 5733: EPP Contact Mapping](http://tools.ietf.org/html/rfc5733)
|
||||
* [RFC 3915: EPP Grace Period Mapping](http://tools.ietf.org/html/rfc3915)
|
||||
* [RFC 5734: EPP Transport over TCP](http://tools.ietf.org/html/rfc5734)
|
||||
* [RFC 5910: EPP DNSSEC Mapping](http://tools.ietf.org/html/rfc5910)
|
||||
* [Draft: EPP Launch Phase Mapping (Proposed)]
|
||||
(http://tools.ietf.org/html/draft-tan-epp-launchphase-11)
|
||||
|
||||
### Registry Data Escrow (RDE)
|
||||
|
||||
@@ -114,17 +115,22 @@ This service exists for ICANN regulatory purposes. ICANN needs to know that,
|
||||
should a registry business ever implode, that they can quickly migrate their
|
||||
TLDs to a different company so that they'll continue to operate.
|
||||
|
||||
* [Draft: Registry Data Escrow Specification](http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow-06)
|
||||
* [Draft: Domain Name Registration Data (DNRD) Objects Mapping](http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05)
|
||||
* [Draft: ICANN Registry Interfaces](http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces-05)
|
||||
* [Draft: Registry Data Escrow Specification]
|
||||
(http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow-06)
|
||||
* [Draft: Domain Name Registration Data (DNRD) Objects Mapping]
|
||||
(http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05)
|
||||
* [Draft: ICANN Registry Interfaces]
|
||||
(http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces-05)
|
||||
|
||||
### Trademark Clearing House (TMCH)
|
||||
|
||||
Domain Registry integrates with ICANN and IBM's MarksDB in order to protect
|
||||
trademark holders, when new TLDs are being launched.
|
||||
|
||||
* [Draft: TMCH Functional Spec](http://tools.ietf.org/html/draft-lozano-tmch-func-spec-08)
|
||||
* [Draft: Mark and Signed Mark Objects Mapping](https://tools.ietf.org/html/draft-lozano-tmch-smd-02)
|
||||
* [Draft: TMCH Functional Spec]
|
||||
(http://tools.ietf.org/html/draft-lozano-tmch-func-spec-08)
|
||||
* [Draft: Mark and Signed Mark Objects Mapping]
|
||||
(https://tools.ietf.org/html/draft-lozano-tmch-smd-02)
|
||||
|
||||
### WHOIS
|
||||
|
||||
@@ -134,8 +140,10 @@ internal HTTP endpoint running on `/_dr/whois`. A separate proxy running on port
|
||||
43 forwards requests to that path. Domain Registry also implements a public HTTP
|
||||
endpoint that listens on the `/whois` path.
|
||||
|
||||
* [RFC 3912: WHOIS Protocol Specification](https://tools.ietf.org/html/rfc3912)
|
||||
* [RFC 7485: Inventory and Analysis of Registration Objects](http://tools.ietf.org/html/rfc7485)
|
||||
* [RFC 3912: WHOIS Protocol Specification]
|
||||
(https://tools.ietf.org/html/rfc3912)
|
||||
* [RFC 7485: Inventory and Analysis of Registration Objects]
|
||||
(http://tools.ietf.org/html/rfc7485)
|
||||
|
||||
### Registration Data Access Protocol (RDAP)
|
||||
|
||||
@@ -143,23 +151,24 @@ RDAP is the new standard for WHOIS. It provides much richer functionality, such
|
||||
as the ability to perform wildcard searches. Domain Registry makes this HTTP
|
||||
service available under the `/rdap/...` path.
|
||||
|
||||
* [RFC 7480: RDAP HTTP Usage](http://tools.ietf.org/html/rfc7480)
|
||||
* [RFC 7481: RDAP Security Services](http://tools.ietf.org/html/rfc7481)
|
||||
* [RFC 7482: RDAP Query Format](http://tools.ietf.org/html/rfc7482)
|
||||
* [RFC 7483: RDAP JSON Responses](http://tools.ietf.org/html/rfc7483)
|
||||
* [RFC 7484: RDAP Finding the Authoritative Registration Data](http://tools.ietf.org/html/rfc7484)
|
||||
* [RFC 7480: RDAP HTTP Usage](http://tools.ietf.org/html/rfc7480)
|
||||
* [RFC 7481: RDAP Security Services](http://tools.ietf.org/html/rfc7481)
|
||||
* [RFC 7482: RDAP Query Format](http://tools.ietf.org/html/rfc7482)
|
||||
* [RFC 7483: RDAP JSON Responses](http://tools.ietf.org/html/rfc7483)
|
||||
* [RFC 7484: RDAP Finding the Authoritative Registration Data]
|
||||
(http://tools.ietf.org/html/rfc7484)
|
||||
|
||||
### Backups
|
||||
|
||||
The registry provides a system for generating and restoring from backups with
|
||||
strong point-in-time consistency. Datastore backups are written out once daily
|
||||
strong point-in-time consistency. Datastore backups are written out once daily
|
||||
to Cloud Storage using the built-in Datastore snapshot export functionality.
|
||||
Separately, entities called commit logs are continuously exported to track
|
||||
changes that occur in between the regularly scheduled backups.
|
||||
|
||||
A restore involves wiping out all entities in Datastore, importing the most
|
||||
recent complete daily backup snapshot, then replaying all of the commit logs
|
||||
since that snapshot. This yields a system state that is guaranteed
|
||||
since that snapshot. This yields a system state that is guaranteed
|
||||
transactionally consistent.
|
||||
|
||||
### Billing
|
||||
@@ -173,24 +182,26 @@ monthly invoices per registrar.
|
||||
|
||||
Because the registry runs on the Google Cloud Platform stack, it benefits from
|
||||
high availability, automatic fail-over, and horizontal auto-scaling of compute
|
||||
and database resources. This makes it quite flexible for running TLDs of any
|
||||
and database resources. This makes it quite flexible for running TLDs of any
|
||||
size.
|
||||
|
||||
### Automated tests
|
||||
|
||||
The registry codebase includes ~400 test classes with ~4,000 total unit and
|
||||
integration tests. This limits regressions, ensures correct system
|
||||
integration tests. This limits regressions, ensures correct system
|
||||
functionality, and allows for easy continued future development and refactoring.
|
||||
|
||||
### DNS
|
||||
|
||||
An interface for DNS operations is provided, along with a sample implementation
|
||||
that uses the [Google Cloud DNS](https://cloud.google.com/dns/) API. A bulk
|
||||
that uses the [Google Cloud DNS](https://cloud.google.com/dns/) API. A bulk
|
||||
export tool is also provided to export a zone file for an entire TLD in BIND
|
||||
format.
|
||||
|
||||
* [RFC 1034: Domain Names - Concepts and Facilities](https://www.ietf.org/rfc/rfc1034.txt)
|
||||
* [RFC 1035: Domain Names - Implementation and Specification](https://www.ietf.org/rfc/rfc1034.txt)
|
||||
* [RFC 1034: Domain Names - Concepts and Facilities]
|
||||
(https://www.ietf.org/rfc/rfc1034.txt)
|
||||
* [RFC 1035: Domain Names - Implementation and Specification]
|
||||
(https://www.ietf.org/rfc/rfc1034.txt)
|
||||
|
||||
### Exports
|
||||
|
||||
@@ -202,21 +213,20 @@ ICANN-mandated reports, database snapshots, and reserved terms.
|
||||
### Metrics and reporting
|
||||
|
||||
The registry records metrics and regularly exports them to BigQuery so that
|
||||
analyses can be run on them using full SQL queries. Metrics include which EPP
|
||||
analyses can be run on them using full SQL queries. Metrics include which EPP
|
||||
commands were run and when and by whom, information on failed commands, activity
|
||||
per registrar, and length of each request.
|
||||
|
||||
[BigQuery][bigquery] reporting scripts are provided to generate the required
|
||||
per-TLD monthly
|
||||
[registry reports](https://www.icann.org/resources/pages/registry-reports) for
|
||||
ICANN.
|
||||
per-TLD monthly [registry reports]
|
||||
(https://www.icann.org/resources/pages/registry-reports) for ICANN.
|
||||
|
||||
### Registrar console
|
||||
|
||||
The registry includes a web-based registrar console that registrars can access
|
||||
in a browser. It provides the ability for registrars to view their billing
|
||||
in a browser. It provides the ability for registrars to view their billing
|
||||
invoices in Google Drive, contact the registry provider, and modify WHOIS,
|
||||
security (including SSL certificates), and registrar contact settings. Main
|
||||
security (including SSL certificates), and registrar contact settings. Main
|
||||
registry commands such as creating domains, hosts, and contacts must go through
|
||||
EPP and are not provided in the console.
|
||||
|
||||
@@ -231,7 +241,7 @@ system, and creating new TLDs.
|
||||
### Plug-and-play pricing engines
|
||||
|
||||
The registry has the ability to configure per-TLD pricing engines to
|
||||
programmatically determine the price of domain names on the fly. An
|
||||
programmatically determine the price of domain names on the fly. An
|
||||
implementation is provided that uses the contents of a static list of prices
|
||||
(this being by far the most common type of premium pricing used for TLDs).
|
||||
|
||||
@@ -240,23 +250,23 @@ implementation is provided that uses the contents of a static list of prices
|
||||
There are a few things that the registry cannot currently do, and a few things
|
||||
that are out of scope that it will never do.
|
||||
|
||||
* You will need a DNS system in order to run a fully-fledged registry. If you
|
||||
are planning on using anything other than Google Cloud DNS you will need to
|
||||
provide an implementation.
|
||||
* You will need an invoicing system to convert the internal registry billing
|
||||
events into registrar invoices using whatever accounts receivable setup you
|
||||
already have. A partial implementation is provided that generates generic CSV
|
||||
invoices (see `MakeBillingTablesCommand`), but you will need to integrate it
|
||||
with your payments system.
|
||||
* You will likely need monitoring to continuously monitor the status of the
|
||||
system. Any of a large variety of tools can be used for this, or you can
|
||||
write your own.
|
||||
* You will need a proxy to forward traffic on EPP and WHOIS ports to the HTTPS
|
||||
endpoint on App Engine, as App Engine only allows incoming traffic on
|
||||
HTTP/HTTPS ports. Similarly, App Engine does not yet support IPv6, so your
|
||||
proxy would have to support that as well if you need IPv6 support. Future
|
||||
versions of [App Engine Flexible][flex] should provide these out of the box,
|
||||
but they aren't ready yet.
|
||||
* You will need a DNS system in order to run a fully-fledged registry. If you
|
||||
are planning on using anything other than Google Cloud DNS you will need to
|
||||
provide an implementation.
|
||||
* You will need an invoicing system to convert the internal registry billing
|
||||
events into registrar invoices using whatever accounts receivable setup you
|
||||
already have. A partial implementation is provided that generates generic
|
||||
CSV invoices (see `MakeBillingTablesCommand`), but you will need to
|
||||
integrate it with your payments system.
|
||||
* You will likely need monitoring to continuously monitor the status of the
|
||||
system. Any of a large variety of tools can be used for this, or you can
|
||||
write your own.
|
||||
* You will need a proxy to forward traffic on EPP and WHOIS ports to the HTTPS
|
||||
endpoint on App Engine, as App Engine only allows incoming traffic on
|
||||
HTTP/HTTPS ports. Similarly, App Engine does not yet support IPv6, so your
|
||||
proxy would have to support that as well if you need IPv6 support. Future
|
||||
versions of [App Engine Flexible][flex] should provide these out of the box,
|
||||
but they aren't ready yet.
|
||||
|
||||
[bigquery]: https://cloud.google.com/bigquery/
|
||||
[datastore]: https://cloud.google.com/datastore/docs/concepts/overview
|
||||
|
||||
Reference in New Issue
Block a user