27 Registration Life Cycle

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.SAPOPT Comunicacoes S.A.gmail.comView

1. Overview

The registration life cycle for a private brand Domain Name Registry is a reduced version of the life cycle for an open brand TLD. Many of the requirements for open TLDs are less relevant for TLDs which have a limited number of names under management and which will use a very limited number of registrars (most likely just one).

It is also likely that the registered domain names will not be sold on the secondary market and transferred from one registrar to another. In addition, it is likely that the names will be “registered” for very long periods (max. 10 years), and that the domain name registry itself will automatically renew the domain names on expiry.

To summarize the operations:

1) All transactions via one registrar;
2) Create registrant, administrative, technical and billing contact;
3) Register domain name;
4) Add, remove or change name servers;
5) Add, remove or change DNSSEC keys;
6) Transfer not used (one registrar)‏;
7) Deletion and restoration from redemption provided.

The following sections give an overview of the different actions that the Registrar can perform to influence the state of a domain name. Some might just change the state of the domain name. Others might alter the domain nameʹs information such as name servers, contacts, DNSSEC keys and client flags.

Some actions also involve interaction from the Domain Name Registry.

There are two distinct phases in the TLDʹs lifespan which lead to different behavior. The first phase does not allow free registrations. It typically consists of a number of sunrise periods where different parties under different circumstances are allowed to register certain domain names. The second phase is what is referred to as general availability. It could start with a so called ʹland rushʹ period that allows the Domain Name Registry to identify popular names.


2. Registration Lifecycle

The time line of a domain name is schematically provided in Figure 1.

(View attachment for Figure 1: Domain Timeline)

In the following paragraphs, more details are provided on the different steps in the time line.

2.1. Registration (or Sunrise)

1) The Domain Name Registry Operator receives the domain create command
2) The domain name goes into state pendingCreate during sunrise
a) The clearing house does validation of the domain name for the registrant
b) The domain name is registered if properly validated, or canceled otherwise.
3) Domain is registered

2.2. Update

1) Add, remove or change of tech, admin, billing contacts possible
2) Add, remove or change of name servers possible
3) Add, remove or change of DNSSEC keys possible

2.3. Transfer

1) Transfer: changing Registrar, same Registrant
2) Transfer command secured by authentication code
3) Losing Registrar notified to accept or reject the transfer (after consulting registrant and⁄or admin contact)
4) A successful transfer extends the registration period with one year (up to a maximum of ten years)

2.4. Renew

Registrars use the Renew Domain command to extend the registration period of a domain object. A Registrar can only renew domain names for which it is the sponsoring registrar. The Renew Domain command must be specified with a registration period, from one to ten years. The resulting expiry date must not lay more than 10 years in the future.

1) Domain name is renewed automatically on expiry date
2) Explicit renewal of period possible (period can be extended up to 10 years)

2.5. Delete

1) Deletion puts domain name in redemption status
2) Deleted from zone file instantly (serverHold)

2.6. Redemption

1) Domain name is no longer available in zone file (serverHold)
2) Domain name can be restored before the end of the redemption grace period (RGP)
3) The domain name will be purged after the pendingDelete interval

2.7. Available

1) Domain comes back in the pool of available domain names


3. RFC5731-Compliant Domain Name Status Codes

The status information on a domain name object is in line with the flags described in RFC5731, section 2.3. It is a combination of the following Status Value Descriptions:

1) clientDeleteProhibited, serverDeleteProhibited: Requests to delete the domain name will be rejected.
2) clientHold, serverHold: DNS delegation information is not published for the domain name .
3) clientRenewProhibited, serverRenewProhibited: Requests to renew the domain name are rejected.
4) clientTransferProhibited, serverTransferProhibited: Requests to transfer the domain name are rejected.
5) clientUpdateProhibited, serverUpdateProhibited: Requests to update the domain name , other than to remove this status value, are rejected.
6) Inactive: Delegation information has not been associated with the domain name . This is the default status when a domain object is first created and there are no associated host objects or host attributes for the DNS delegation. This status can also be set by the server when all host-object associations are removed.
7) Ok: This is the normal status value for an domain name that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
8) PendingCreate: Request to create a new domain name has been received and is being processed or evaluated.
9) pendingDelete: Request to delete an existing domain name has been received and is being processed or evaluated.
10) pendingRenew: Request to renew an existing domain name has been received and is being processed or evaluated.
11) pendingTransfer: Request to transfer an existing domain name has been received and is being processed or evaluated.
12) pendingUpdate: Request to update an existing domain name has been received and is being processed or evaluated.

Following combinations are excluded :

1) ok cannot be combined with any other status
2) pendingDelete status cannot be combined with ʺclientDeleteProhibitedʺ or ʺserverDeleteProhibitedʺ status
3) ʺpendingRenewʺ cannot be combined with ʺclientRenewProhibitedʺ or ʺserverRenewProhibitedʺ status
4) ʺpendingTransferʺ status cannot be combined with ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status
5) ʺpendingUpdateʺ status cannot be combined with ʺclientUpdateProhibitedʺ or ʺserverUpdateProhibitedʺ status
6) pendingCreate, pendingDelete, pendingRenew, pendingTransfer and pendingUpdate cannot be combined

The status flags starting with the word ʹclientʹ can be changed and updated by the Registrar. The status flags starting with ʹserverʹ are handled by the Domain Name Registry Operator.

The Domain Name Registry will implement the above statuses in full.


4. RFC3915-Compliant Domain name status code

RFC3915 defines extra flags on the domain name that can be set or referenced by EPP. These flags are referred to as the RGP flags (Registry Grace Period). The following flags are defined and can be found in a separately available EPP extension called the RGP extension (RFC3915).

1) addPeriod: This “add grace period” is provided after the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the domain name registry provides a credit to the registrar for the cost of the registration.
2) autoRenewPeriod: This “auto-renew grace period” is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
3) renewPeriod: This “renew grace period” is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
4) transferPeriod: This “transfer grace period” is provided after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.
5) redemptionPeriod: This status value is used to describe a domain for which a 〈delete〉 command has been received, but the domain has not yet been purged because an opportunity exists to restore the domain and abort the deletion process. This status must be combined with the pendingDelete status in the EPP domain mapping.
6) pendingRestore: This status value is used to describe a domain that is in the process of being restored after being in the redemptionPeriod state. This status must be combined with the pendingDelete status in the EPP domain mapping.
7) pendingDelete: This status value is used to describe a domain that has entered the purge processing state after completing the redemptionPeriod state without succesful restoration. This status must be combined with the pendingDelete status in the EPP domain mapping.

The Domain Name Registry will partially implement the above RGP statuses: the statuses concerning the redemption of the domain name (redemptionPeriod, pendingRestore, pendingDelete) and autoRenewPeriod.

We will not implement the following statuses:

1) addPeriod: because no “domain name tasting” will be allowed
2) renewPeriod: because the registrar has explicitly and successfully issued the renew command, no refund is granted;
3) transferPeriod: because the registrar has explicitly and successfully issued the transfer command, no refund is granted.


5. Status code matrix

There are two types of status values. These may change as a result of the Client initiating a transform command referring to the commands referenced in the ʹClientʹ column or by the domain name Registry referring to the ʹServerʹ column. The last column referred to as ʹGeneralʹ contains flags that transitional status values.

(View attachment for Table 1: Status Code Matrix)

The Prohibited flags have no influence on the status of the domain object. They prevent the denoted command from being executed on the domain name object. As such when set, they prevent the transform command from being executed and hence block the specified domain name life cycle transition.


6. Status transitions

6.1. Global status transitions

The following domain name states can be determined

1) The domain name status is defined as ʹavailable for registrationʹ (in short ʹavailableʹ) if the domain name is conform to the registration policy and the domain name object does not exist.
2) The domain name is registered (no pending actions).
3) The domain name has a pending action. This can be one of the following
a) pendingCreate
b) pendingTransfer
c) pendingDelete
d) pendingUpdate
e) pendingRenew

(View attachment for Table 2: Exhaustive list of transitions)

Some transitions might be influenced by the registration policy. For instance

1) The create has to be verified by the domain name Registry to see if no conflicts or infringements are detected.
2) The name servers added to the domain name object have to comply with certain rules set forth in the policy.
3) Change of ownership has to be verified.
4) Domain name matches predefined rule set needing registry acceptance.

This is a non-exhaustive list which should reflect domain name registration policy regulations.

6.2. Registry grace period status transitions

The following domain name states are added to the domain name object when it has the EPP pendingDelete status:

1) redemptionPeriod
2) pendingRestore
3) pendingDelete

(View attachment for Table 3: Exhaustive list of 3c pendingDelete state transitions)

6.3. Registration State Diagram

The Registration state diagram shows all possible states and transactions between those states.

In a single-Registrar Registry model, this State Diagram can be simplified:

1) The transfer of domain names is not used. Therefore all flags linked to transfer can be ignored.

The domain name life cycle can be found in the attached flow chart.

(View attachment for Figure 2: Registration State Diagram)


7. Transition commands

The following domain object commands, requested by the registrar, can be used to trigger status transitions:

(View attachment for Table 4: Transition commands)


8. Registry transitions

The Domain Name Registry triggers also status transitions in case of expiration, time-outs or resolution of pending actions:

(View attachment for Table 5: Registry status transitions)


9. Resourcing Plan

9.1. Personnel

With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Registration Lifecycle in the Registry Platform is under the authority of the Software Developer, under control of the Operations Manager.

Similar gTLD applications: (15)

gTLDFull Legal NameE-mail suffixzDetail
.SFRSociete Francaise du Radiotelephone - SFRsfr.com-4.12Compare
.MEOPT Comunicacoes S.A.gmail.com-4.12Compare
.SCHWARZSchwarz Domains und Services GmbH & Co. KGsbg.de-4.12Compare
.SCHWARZGROUPSchwarz Domains und Services GmbH & Co. KGsbg.de-4.12Compare
.LIDLSchwarz Domains und Services GmbH & Co. KGsbg.de-4.12Compare
.ADACAllgemeiner Deutscher Automobil-Club e.V. (ADAC)zentrale.adac.de-4.11Compare
.DEUTSCHEPOSTDeutsche Post AGmarkmonitor.com-4.11Compare
.DHLDeutsche Post AGmarkmonitor.com-4.11Compare
.artEFLUX.ART, LLCe-flux.com-3.65Compare
.gentCOMBELL GROUP NV⁄SAcombellgroup.com-3.65Compare
.bostonThe Boston Globe Newspaper Company Inc.boston.com-3.64Compare
.LTDC.V. TLDcaretvision.nl-3.64Compare
.INCC.V. TLDcaretldcare.com-3.64Compare
.TRUSTDeutsche Post AGmarkmonitor.com-3.64Compare
.EPOSTDeutsche Post AGmarkmonitor.com-3.64Compare