CentralNic Operations Manual

CentralNic Ltd Registrar’s Operations Manual

Last Updated: October 2012 1

CentralNicTM

G l o b a l R e g i s t r y S e r v i c e s

Registrar's Operations Manual

October 2012

CentralNic Ltd Registrar’s Operations Manual

Last Updated: October 2012 2

Contents

Contents .................................................................................................................................................................... 2

1. About CentralNic ................................................................................................................................................... 4

2. Introduction ........................................................................................................................................................... 4

3. Accreditation ......................................................................................................................................................... 4

4. Access .................................................................................................................................................................... 4 4.1 Registrar Console ..................................................................................................................................................... 4 4.2 Toolkit API ................................................................................................................................................................ 5 4.3 EPP Server ................................................................................................................................................................ 5

5. Registry Operations ............................................................................................................................................... 5 5.1 DNS .......................................................................................................................................................................... 5 5.2 WHOIS Service .......................................................................................................................................................... 6 5.3 Technical Support ..................................................................................................................................................... 6 5.4 Maintenance Downtime .......................................................................................................................................... 6 5.5 Billing Policies ........................................................................................................................................................... 7 5.5.1 Available Billing Models ........................................................................................................................................ 7 5.5.1.1 Debit Model ....................................................................................................................................................... 7 5.5.1.2 Credit Model ...................................................................................................................................................... 7

6. The Shared Registry System ................................................................................................................................... 8 6.1 Domain Objects ........................................................................................................................................................ 8 6.1.3.1 Restoring a Domain on "Pending Deletion" Status ............................................................................................ 9 6.2 Contact Objects ........................................................................................................................................................ 9 6.3 Host Objects ........................................................................................................................................................... 10 6.4 Expiry Dates ........................................................................................................................................................... 11 6.5 Grace Periods ......................................................................................................................................................... 11 6.6 Internationalised Domain Names (IDNs) ............................................................................................................... 11 6.7 Renewal ................................................................................................................................................................. 12

7. Extensible Provisioning Protocol .......................................................................................................................... 12 7.1. Operational Testing and Evaluation (OT&E) ......................................................................................................... 12 7.2. The Shared Registry System .................................................................................................................................. 13 7.2.1.1 Registration and IDNs ...................................................................................................................................... 13 7.2.1.2 Updates ............................................................................................................................................................ 13 7.2.1.3 Restoring Domains on pendingDelete status ................................................................................................... 13 7.3 The EPP Message Queue ........................................................................................................................................ 14

CentralNic Ltd Registrar’s Operations Manual Last Updated: September 2012

3

7.4. EPP Extensions ...................................................................................................................................................... 16

8. The Domain Name Life Cycle ................................................................................................................................ 17


4

1. About CentralNic One of the world's pioneering domain registries, CentralNic provides registry services and strategic consultancy for new TLDs, ccTLDs and its own portfolio of 27 global domain extensions.

Our domains – including .US.COM (USA), .UK.COM (UK), .COM.DE (Germany), .CN.COM (China), .JP.NET (Japan) and the world's first city TLD, .LA for Los Angeles – are sold via an integrated global network of 1,500 registrars and 100,000 resellers in over 100 countries.

2. Introduction This document has been written with the intention of providing new and existing registrars with all the information they will need to successfully integrate with the CentralNic Registry. This document covers technical, financial and policy considerations involved with integration. All registrars are strongly advised to read this document thoroughly. If you have any questions regarding this document, please get in touch and we will be very happy to assist you. Telephone: +44 (0)8700 170 900 between 08:30 and 17:30 (UK office hours) E-‐mail: [email protected]

3. Accreditation To be granted access to the CentralNic registry system, all registrars must sign the CentralNic Registrar Agreement. You are not required to deposit funds with CentralNic in advance, or complete an OT&E evaluation.

Certain domain extensions such as .PW require a separate accreditation agreement. You can sign the agreement and complete the accreditation for these extensions on the Registrar Console.

4. Access Registrars can interact with the CentralNic registry system using the following interfaces:

l Registrar Console l EPP Server l HTTP Toolkit

4.1 Registrar Console The Registrar Console provides a simple way to manage objects in the registry using a web interface. Access to the Registrar Console is via an SSL-‐encrypted website at https://registrar-‐console.centralnic.com/ This console allows registrars to remit payment, manage domain names and transfers, and change account settings.


5

4.2 EPP Server EPP documentation is available below this document in Section 7.

4.3 Toolkit API The Toolkit API uses a simple text-‐over-‐HTTP protocol. The Toolkit offers functions for information retrieval (domain availability, detailed domain lookup, detailed contact lookup), domain and contact registration and management (including transferring, renewing and deleting domains), and account management (getting lists of domains, pricing information, and upcoming renewals). We also maintain easy-‐to-‐use client libraries in Perl and PHP, and plan to offer libraries in other popular languages in the future.

Further information about the Toolkit can be found on the Registrar Console.

4.4 Access While access to the Registrar Console is not restricted, connections to the Toolkit and EPP server are restricted by IP address. Registrars must provide a list of IP addresses (or networks) from which they will make connections. This list can be managed online via the Registrar Console.

5. Registry Operations

5.1 DNS CentralNic operates a network of DNS servers at many locations around the world. We are proud to be able to claim 100% availability of DNS services since we began operating in 1995.

Our DNS zones are updated continually, and changes to domain names will become visible on our DNS servers after no more than 10-‐15 minutes.

5.1.1 Wild-‐Card Record CentralNic may place wild-‐card A records into certain DNS zones. Registrars will be notified of the value of this record so that they can configure any DNS-‐based availability tests to ignore records that have this value.

If a wild-‐card record is placed into the zone, catch-‐all SPF records will also be placed in the zone to prevent domain-‐spoof spamming. The format of these SPF records is:

*.uk.com. 3600 IN TXT "v=spf1 -‐all" *.uk.com. 3600 IN TXT "v=spf2.0/pra -‐all"

The SPF specification (see RFC 4408) explicitly states that SPF records do not propagate down to lower nodes in the DNS, so the use of the SPF record above will have no effect on domain names registered under .UK.COM.

Wildcard will not be used with TLDs such as .LA and .PW.


6

5.1.2 Zone File Access Access to zone file data is available upon request, please ask your account manager for the Zone Access Agreement which must be signed and returned to us before access can be granted.

There are two methods for retrieving zone data:

1. Registrar Console: once zone access is enabled for your account, you can download zone files from the Registrar Console. You can also download historical zone files.

2. HTTP REST: if you need a way to programmatically download zone data, then you can use an HTTP REST interface, by making an HTTP GET request to URLs of the form

https://registrar-‐console.centralnic.com/zones/ZONE_NAME

where ZONE_NAME is the zone you wish to download. For example, to download the .LA zone file, you should use the following URL:

https://registrar-‐console.centralnic.com/zones/la

The zone files available via this system are copied from the live DNS servers at 2345hrs UTC every day.

The HTTP REST interface is protected by basic HTTP authentication: you must use your registrar ID and Zone Password, which can be found on the “Passwords” page of the Registrar Console.

5.1.3 DNSSEC All our zones are signed using DNSSEC. For further information please see:

https://www.centralnic.com/support/dnssec

5.2 WHOIS Service CentralNic operates a standard WHOIS server that you can use to check the details of any domain name registered with us. You can use any standard WHOIS client (including the UNIX terminal client) to query our WHOIS server at whois.centralnic.com. Please note that use of the WHOIS service is subject to strict usage limits, to prevent unauthorised access to personal information about registrants. For more information, please see our WHOIS Access Policy at https://registrar-‐console.centralnic.com/pub/whois_guidance.

5.3 Technical Support A trouble tickets system is integrated into the Registrar Console, and registrars are encouraged to use this system for all support requests. This allows us to monitor and track support requests, and provides an escalation path for urgent issues with the Registry system.

Telephone-‐based technical support is currently available between 08:30 and 17:30, UK office hours. Otherwise, any e-‐mail request sent to [email protected] will be answered within one business day.

In the event that the Registrar Console is not available, registrars can contact the Operations team at [email protected].

5.4 Maintenance Downtime CentralNic may, on occasion, need to take down portions of its registry system for maintenance. This will


7

have no effect on the resolution of domains already registered. Registrars will receive notification via e-‐mail well in advance of any planned outage (registrars must specify an “operations” email address for their account in order to receive these notifications). Additionally, we will notify registrars at the beginning and end of any planned maintenance window, so that registrars are aware when planned maintenance has been completed.

Registrars will also be notified of any unscheduled outages.

5.5 Billing Policies CentralNic's billing system is designed to be highly flexible, allowing for multiple billing models in parallel. By default your account will be set to the Debit Model.

5.5.1 Available Billing Models 5.5.1.1 Debit Model This model is the same as that operated by most gTLD and ccTLD registries. Registrars maintain a balance of funds with the registry, from which registration and renewal fees are deducted. Payment may be remitted to the registry by wire transfer or credit card. Debit registrars enjoy fixed “grace periods” relating to domain registrations, renewals and transfers, during which domain names can be deleted in exchange for a full credit of the related fee.

Under this model, our system will automatically send an email to your specified billing address if your balance is running low. If your balance reaches zero, then our system will fall back to the “credit” model, as described below. 5.5.1.2 Credit Model Under the credit billing model, each registrar is assigned a credit limit, and may perform billable transactions until this limit is exhausted. Registrars must remit payment for each billable transaction within a certain amount of time after the transaction, or our system will delete the domain name. Please see “The CentralNic Domain Name Life Cycle” at the bottom of this document.

5.5.2 Renewals CentralNic operates two models for domain name renewals.

1. Auto-‐delete. All domains that are not explicitly renewed by the registrar are automatically placed on "Pending Deletion" when they expire. A domain on "Pending Deletion" can be restored via the Registrar Console, the Toolkit, or EPP within 30 days of its expiration. After 35 days on "Pending Deletion", the domain is deleted and made available for registration.

2. Auto-‐renew. All domain names are automatically renewed. For “debit model” registrars, payment is processed after the 45 day “auto-‐renew grace period”. For “credit model” registrars, our system issues a renewal invoice. If payment has not been received after 68 days, the domain goes "On Hold", and if no payment has been received after a further 35 days (103 days total), the domain is deleted.

By default, all new registrar accounts are set to the auto-‐delete model.


8

5.5.3 Invoicing Regardless of which billing model you choose, our system will generate a regular invoice for registrations and renewals. By default, we will generate a new invoice every week (on Monday) for all registrations and renewals that have taken place since the previous invoice. However, this billing interval can be changed to be daily or monthly (on the first day of each month) as required, via the Registrar Console.

5.5.4 Submitting Payment If using the Debit Model, you are requested to notify us of payment using the ‘Top Up’ facility on the registrar console. This will ensure your payment is allocated correctly when it reaches us.

If using the Credit Model, CentralNic uses a batch payment system. Domains can be batched using the ‘Unpaid Domains’ link on the registrar console. You can then select your preferred payment method, and details of where to submit payment are displayed. Once the batch payment is confirmed CentralNic are notified and your payment can easily be allocated when it arrives.

Payment can be made by credit card or direct bank transfer. We have US Dollar and Euro accounts to reduce costs to our registrars due to exchange commission. Details of our Sterling, US Dollar and Euro accounts are supplied when creating a payment batch on the registrar console.

You can submit payment for as many or as few domains as you like. Our Registrar Console interface allows you to "cherry pick" as many domains as you like from any of your outstanding invoices.

6. The Shared Registry System CentralNic provides an object-‐oriented registry system, in which registrars manage domain, contact and host objects. Each object is associated with a single registrar, who is said to be the “sponsor” of that object. Objects may be created, updated, deleted and transferred between registrars.

6.1 Domain Objects

6.1.1 Registration In order to be successfully registered in the system, a domain name:

l MUST have a prefix (the label to the left of the TLD) of between three and sixty-‐four characters l MAY ONLY contain characters from the set A-‐Z, 0-‐9 and “.” and “-‐” (case insensitive) l MUST have a Registrant Contact l MUST have an Administrative Contact l MUST have a Technical Contact

Domain names may also: l have an additional “billing” contact l have any number of authoritative DNS servers

DNS delegation information is not required for a successful registration. However, please note that domains that are registered without any DNS delegation may resolve to an advertising page due to the presence of a wild-‐card in the zone (see 5.1.1.). This will not apply to domains under ccTLDs such as .LA and .PW.


9

6.1.2 Transfers Domain names may be transferred between registrars. The procedure for domain name transfers is as follows:

1. The registrant acquires the authInfo code for the domain name from the losing registrar. 2. The registrant supplies the authInfo code to the gaining registrar. 3. The gaining registrar submits a transfer request to the registry, using the authInfo code received

from the registrant. 4. The registry notifies the losing registrar of the transfer request. The losing registrar has five

calendar days to explicitly approve or reject the transfer, after which the transfer is automatically approved.

5. Once the transfer is approved, the gaining registrar is notified by the registry, and the domain name is transferred within 60 seconds.

The gaining registrar may add renewal years when requesting a transfer, to specify the number of years to add to the domain's registration period upon successful transfer. This may be any integer between 0 (zero) and 10, or it may be omitted entirely.

Notifications are sent to both the gaining and losing registrar.

Registrars are required to provide the authInfo code for domain names to registrants upon request.

When a domain transfer is approved and processed by our system, any subordinate host objects will also be transferred to the gaining registrar.

Note on billing: if a domain name has any unpaid line-‐items against it (ie. for registration or renewal), we will automatically reject any transfer request until payment is received.

6.1.3 Deletion Registrars may delete domain names at any time.

l if the domain name is “newly registered”, that is, we have not received payment for initial registration, (for “debit model” registrars, this is the “add grace period”), then it is immediately deleted upon receipt of a deletion request, and may be immediately re-‐registered.

l if the domain name is not newly registered, it is marked as “pendingDelete” and, if not restored during the Redemption Grace Period, will be deleted after 35 days.

6.1.3.1 Restoring a Domain on "Pending Deletion" Status If a domain name has been placed on "Pending Deletion", either because your account is set to "auto-‐delete", or because you have requested its deletion, you may restore it at any time by using the ‘restore’ function on the Registrar Console, or the relevant Toolkit or EPP function. Restoring an expired domain automatically renews it for at least one year.

6.2 Contact Objects Every domain name must have a Registrant and Administrative and Technical Contacts. Registrars may also supply a Billing Contact.

A contact object may have the following attributes:


10

Name: The full name of the person the contact refers to, or an organisational name (ie "Hostmaster")

Company: The full name of the organisation, if appropriate Street Address: 1-‐3 text fields representing the postal address City The city or town State/Province The state, province or geographic region Postcode: The postal or ZIP code of the contact Country: The two letter ISO-‐3166 country code for the contact. "UK" is used in place of "GB" (our

systems will convert). Phone: The telephone number of the contact, ideally in e164a format. Fax: The fax number of the contact, ideally in e164a format. E-‐mail: The e-‐mail address of the contact. Of the above, the fields that are mandatory for all contact objects are: Name, Country, Email. All other fields are optional.

6.2.1 Transfers Contact objects may be transferred between registrars in the same way as domain names.

Registrars may find it easier to simply recreate new contacts objects for recently transferred domain names, since this avoids the delay associated with contact transfers.

6.2.2 Privacy CentralNic offers a WHOIS privacy mechanism on a per-‐contact basis. Registrars may enable or disable privacy for contact objects. When privacy is enabled, contact information is excluded from WHOIS records. We provide mechanisms to enable or disable WHOIS privacy on the Registrar Console, Toolkit and EPP systems.

6.3 Host Objects Registrars may freely create host objects that are “out-‐of-‐bailiwick” (i.e. not subordinate to any of the zones for which CentralNic is authoritative). IP address information supplied during a create or update request will be ignored for such hosts, and our DNS servers will not publish glue for them.

Registrars may only create “in-‐bailiwick” (ie subordinate to a zone for which CentralNic is authoritative) if they are the sponsor for the immediately superordinate domain name. That is to say, a registrar may only create a host object named NS0.EXAMPLE.UK.COM if that registrar is the sponsor for EXAMPLE.UK.COM. Registrars may not create host objects that are subordinate to domain names that are sponsored by other registrars, or that are subordinate to an unregistered domain name.

For in-‐bailiwick host objects, registrars must supply a single IPv4 address in dotted-‐quad format. Registrars may also supply an IPv6 address in standard colon-‐separated hexadecimal format. Support for multiple IP addresses of the same type is not currently supported.


11

6.3.1 Sponsorship and Transfers In-‐bailiwick host objects are automatically transferred when the superordinate domain name is transferred. Out-‐of-‐bailiwick host objects may not be transferred.

6.4 Expiry Dates When a domain name is newly registered, or renewed, its Expiry Date will increase by the appropriate number of years, in both the Registrar Console and the WHOIS record. Once a registration/renewal has been submitted an additional status of ‘Registration in Progress’ or 'Renewal in Progress' will be displayed on the Registrar Console, and the “RENEW GRACE PERIOD” status will appear in the whois record. Once payment has been received the status will simply show ‘Live’.

6.5 Grace Periods The grace periods described here apply only to registrars on the “debit” model (see 5.5.1.1 for details). Name Description Period Add Grace Period Time after a domain is registered that during which it may be

deleted in exchange for a full credit 5 days

Renew Grace Period Time after a domain is renewed that during which it may be deleted in exchange for a full credit

5 days

Auto-‐renew Grace Period Time after a domain is auto-‐renewed that during which it may be deleted in exchange for a full credit

45 days

Transfer Grace Period* Time after a domain is transferred that during which it may be deleted in exchange for a full credit

5 days

*Note: the Transfer Grace Period only applies to domain transfers which include a renewal as part of the transfer: this is mandatory in other registry systems, but is optional in ours.

6.6 Internationalised Domain Names (IDNs) CentralNic's registry system allows the registration of Punycode-‐encoded internationalised domain names (IDNs). CentralNic's IDN system operates in a similar manner to that of other registries, taking an inclusion-‐based approach with defined tables of permitted code points. These tables are published at the following URL:

https://www.centralnic.com/names/domains/idn/tables

IDNs are subject to the following rules:

• the "A-‐label" must be valid according to the IDNA2008 rules. We will test this by decoding the A-‐label to a UTF-‐8 string, and then re-‐encoding. If the re-‐encoded string matches the original string, this test is passed.

• the "U-‐label" must contain at least the minimum number of characters. The minimum number varies depending on the domain extension and the registrar, but is normally 3.


12

• the A-‐label must be a valid domain name in its own right (ie length and composition rules for ASCII domain names must also sucessfully be passed).

• the U-‐label must not contain more than the maximum number of characters. This is 63 characters but may vary depending on the domain extension and the registrar.

• the U-‐label must be wholly composed of characters from one of the IDN tables associated with the domain extension.

6.7 Renewal Registrars may renew domain names for any whole period of years between 1 and 10, up until the year 2037 (to avoid potential 32-‐bit integer overflows – support for 64-‐bit dates is under development).

CentralNic may withhold access to domain renewal functions if a registrar's current outstanding balance exceeds the credit limit specified for their account.

7. Extensible Provisioning Protocol The EPP Server has been designed to adhere to version 1.0 of the EPP specification, as defined in RFC 5730. In addition, we have developed our EPP implementation to operate in an identical manner to that operated by other registries, to minimise the amount of new software that must be written by registrars wishing to provision domain names in zones managed by CentralNic.

Access to the EPP server is via an SSL-‐encrypted TCP interface at epp.centralnic.com, port 700.

Access to the EPP system may not be enabled by default on your account, unless you specifically requested it during the signup process. If you do not have EPP enabled on your account, please contact your account manager.

For examples of EPP frames for creating and management registry objects such as domain names, host objects and contact objects, please consult the relevant RFCs.

7.1. Operational Testing and Evaluation (OT&E) CentralNic provides an Operational Testing and Evaluation (OT&E) environment to allow registrars to develop and test their client applications. This system identical to the production registry system, but uses a separate database. Registrars are invited to use this system to test their client implementations, without fear of affecting the production registry system. Registrars can create multiple account credentials for use in the OT&E system via the Registrar Console.

Access to the OT&E EPP server is via an SSL-‐encrypted TCP interface at epp-‐ote.centralnic.com, port 700, and is not restricted by IP address. There is also a version of the Registrar Console for the OT&E system at https://ote-‐console.centralnic.com/, and a WHOIS service at whois-‐ote.grs.centralnic.com.


13

7.2. The Shared Registry System

7.2.1 Domain Objects 7.2.1.1 Registration and IDNs For EPP Registrars, unless specified otherwise using the <domain:period> element, all registrations are for one year. The value for the <domain:period> element may be any integer between one and ten.

EPP does not yet support any mechanism for signalling the language and/or script associated with an IDN domain. CentralNic’s EPP server will identify and validate IDN domains on-‐the-‐fly.

Registrars using EPP may supply an authInfo code for future transfer requests, if not, our system will automatically generate one. 7.2.1.2 Updates EPP Registrars may add or remove the following EPP status codes to domain names:

l clientHold – NS records will not be entered into the zone for the domain name while this status code is applied.

l clientTransferProhibited – transfer requests for this domain name will be automatically rejected while this status code is applied.

l clientRenewProhibited – when this status code is applied, all requests by the sponsoring client to renew the domain are rejected.

l clientUpdateProhibited – when this status code is applied, all requests by the sponsoring client to update the domain name are rejected (except if the request includes removing this status from the domain name).

l clientDeleteProhibited – when this status code is applied, all requests by the sponsoring client to delete the domain name are rejected.

7.2.1.3 Restoring Domains on pendingDelete status Domain names on the “pendingDelete” status can be restored using the standard RGP restoration syntax from RFC 3915. You may specify the number of years to add to the domain's registration period upon restoration using the <domain:period> element.

7.2.2 Contact Objects Contact data may be supplied in either the ASCII or UTF-‐8 character encodings. When constructing an EPP <create> or <update> frame, registrars MUST supply an internationalized form for address data (see RFC 5733).

Please note that contact IDs, whether server or client assigned, are case-‐insensitive. That is, you cannot create an object with an identifier of abc-‐12345 if an object with an identifier of ABC-‐12345 already exists. If you perform an EPP request for object abc-‐12345, ABC-‐12345 will be used instead.

7.2.2.1 Privacy

To enable or disable WHOIS privacy on a contact object, registrars must submit an <update> command, with a <contact:chg> element containing a <contact:disclose> element. The “flag” attribute of this element should be 1 to disable WHOIS privacy (ie contact information will be disclosed in WHOIS records), and 0 to


14

enable it. Here is an example EPP command to enable WHOIS privacy:

<?xml version="1.0" encoding="utf-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> <command> <update> <contact:update xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> <contact:id>sh8013</contact:id> <contact:chg> <contact:disclose flag="0" />  </contact:chg> </contact:update> </update> </command> </epp>

7.2.3 Host Objects Registrars can change the IP addresses associated with a host object using the EPP <host:update> command. This command also permits changing the DNS name of a host object, but with the following conditions:

1. Registrars may not rename a host object that is not subordinate to a domain name under their sponsorship. This includes “out-‐of-‐bailiwick” host objects.

2. Registrars may not rename a host object so that it becomes subordinate to a domain name that is sponsored by another registrar;

3. Registrars may not rename a host object so that it becomes subordinate to a non-‐existent domain name;

4. Registrars may rename a host object so that it is no longer “in-‐bailiwick”, that is, not subordinate to any DNS zone for which CentralNic is the authority. Registrars should be aware that this means that IP address information will not be stored or published for this host object if this happens.

Changes to the DNS name of a given host are applied to the NS records of all domain names which are delegated to that host. This means that it is possible that domain names sponsored by other registrars could be affected by renaming a host object – as a result, registrars should exercise caution when using this feature, and consider using an alternative solution instead (such as creating a new host object and updating any domain names).

7.2.4 EPP Status Codes Most of the above grace periods are described using EPP status codes defined in RFC 3915. A full description of how these status codes are implemented in our registry system is available on the web at the following URL:

https://www.centralnic.com/company/labs/epp/status

7.3 The EPP Message Queue

EPP provides a message queue system to provide registrars with notifications for out-‐of-‐band events. Registrars can choose to enable or disable the use of the message queue for their account, this can be done via the Account Settings page of the Registrar Console.

CentralNic currently supports the following EPP messages:


15

• notification of approved inbound transfer

• notification of rejected inbound transfer

• notification of new outbound transfer

• notification of cancelled outbound transfer

These all have the same format for the contents of the <resData> element in the <poll> server response:

<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

<domain:name></domain:name>

<domain:trStatus></domain:trStatus>

<domain:reID></domain:reID>

<domain:reDate></domain:reDate>

<domain:acID></domain:acID>

<domain:acDate></domain:acDate>

</domain:trnData>

For example, the full server response for an approved transfer will look like this:

<?xml version="1.0" encoding="utf-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">

<response>

<result code="1301">

<msg>Command completed successfully; ack to dequeue.</msg>

</result>

<msgQ count="1" id="12345" />

<resData>

<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

<domain:name>example.uk.com</domain:name>

<domain:trStatus>clientApproved</domain:trStatus>

<domain:reID>H12345</domain:reID>

<domain:reDate>2011-01-27T23:50:00.0Z</domain:reDate>

<domain:acID>H54321</domain:acID>

<domain:acDate>2011-02-01T23:50:00.0Z</domain:acDate>

</domain:trnData>

</resData>

<trID>

<clTRID>abc123</clTRID>

<svTRID>321cba</svTRID>

</trID>

</response>

</epp>


16

7.4. EPP Extensions CentralNic’s EPP system supports a number of extensions. These are listed below:

7.4.1. Registry Grace Period Mapping CentralNic supports the Grace Period mapping described in RFC 3915. Please refer to the RFC document for further information. Please see Section 6.5 for further details

7.4.2. DNSSEC Extension Registrants who have signed their zones can submit Delegation Signer (DS) records using the DNSSEC extension, described in RFC 5910.

7.4.3. ConsoliDate

The ConsoliDate extension was developed by VeriSign for the .COM and .NET registries. It permits registrars to alter the expiry date of a domain by less than a year. This extension is only available to prepayment registrars.

For documentation, please see https://registrar-console.centralnic.com/doc/consolidate-mapping.txt.


17

8. The Domain Name Life Cycle

Please note: this document applies only to “credit model” registrars.

CentralNic's “credit model” billing system differs from those operated by other ccTLD and gTLD registries. In this model, each time a domain name is registered or renewed, we issue an invoice (or a line item on an invoice, to avoid administrative burdens). The registrar then has a fixed period in which to remit payment for the invoice – if payment is not received within the specified period, the domain is deleted. The advantage of this system is that it is “cash-‐flow positive” -‐ the registrar is not required to submit payment to the registry in advance of a sale. However, it is important that registrars understand that domain names may be placed “on hold” and later deleted if payment is not remitted promptly. The flowchart to the left provides a description of the “life cycle” of a domain name in the CentralNic registry. The table below provides key dates when certain events take place:


18

T+0: the domain is registered into the CentralNic database. T+1d (max): The system issues an invoice to the Registrar for the registration of the domain

name. T+37d: after 37 days of non-‐payment, we e-‐mail a reminder to the Registrar. T+44d: after 44 days of non-‐payment, another reminder is e-‐mailed to the Registrar. T+61d: after 61 days of non-‐payment, we notify the Registrant that the domain

remains unpaid, and advise them to contact the Registrar. T+68d: after 68 days of non-‐payment, we e-‐mail a final reminder to the Registrar. The

domain is placed "On Hold". DNS server records are removed from the parent zone.

T+103d: after 103 days of non-‐payment, the domain is deleted and made available for registration.

Renewals When a domain reaches its expiry date, it is re-‐inserted into the life cycle and so the policy for managing unpaid renewals is identical to that for unpaid registrations. Our system will issue an invoice line item to the registrar, who then must remit payment to prevent the domain name from being deleted. Special cases There are a few special cases which may alter the way the life cycle works:

As seen in the flowchart, if a registrar account is set to “auto-‐delete” domain names upon expiry, no renewal item is raised for the domain name and it is placed into the “Pending Delete” status. The domain may be redeemed (and subsequently renewed) at any time before it is deleted, subject to approval by an administrator. There is a five day grace period between expiry and being placed into “Pending Delete.”

Our system normally issues invoices every week. However, many registrars opt for a daily or monthly invoice instead.

If the domain is renewed in advance of its expiry date, the life cycle measures time from the original expiry date rather than the renewal date – our system will not delete domain names before the previous expiry date.

Our administrators can apply a discretionary “stall period” that can slow the life cycle for a certain number of days – this is so that registrars who are unable to immediately remit payment for overdue domains can have a few days to do so. Once the stall period is up, the life cycle will “catch up” if payment is not received.

If a registrar has a serious technical or administrative problem that prevents them from remitting payment, we can temporarily prevent overdue domain names from being placed “on hold” or deleted.

Date post:	18-Apr-2015
Category:	Documents
Upload:	gavinbrown
View:	45 times
Download:	6 times

CentralNic Operations Manual

Documents